Get documents about "Bridge Management System Conceptual System Design Report
Shared by: wuyunqing
-
Stats
- views:
- 77
- posted:
- 9/4/2011
- language:
- English
- pages:
- 108
Document Sample
PUBLIC SERVICES
Bridge Management System
Conceptual System Design Report
Version 2
February 11, 2004
BMS Re-write Phase 2
TABLE OF CONTENTS
BMS Re-write Phase 2
TABLE OF CONTENTS
1. INTRODUCTION ................................................................................................................... 1
1.1 OBJECTIVE ....................................................................................................................... 1
1.2 REPORT SECTIONS........................................................................................................... 1
2. SYSTEM ARCHITECTURE................................................................................................... 3
2.1 SYSTEM ARCHITECTURE OVERVIEW.................................................................................. 3
2.1.1 Selected Alternative System Design ....................................................................... 3
2.1.2 Pontis and Custom Components............................................................................. 6
2.1.3 System Interfaces & Reporting Database ............................................................. 11
2.2 HUMAN INTERFACES ....................................................................................................... 15
2.2.1 Pontis Application Screen Components ................................................................ 15
2.2.2 Pontis Application Reports .................................................................................... 23
2.2.3 New and Customized Components ....................................................................... 27
2.2.4 New and Customized Reports............................................................................... 30
2.3 EXTERNAL SYSTEM INTERFACES ..................................................................................... 33
2.3.1 EDMS .................................................................................................................... 33
2.3.2 GIS ........................................................................................................................ 34
2.3.3 Video Log .............................................................................................................. 36
2.3.4 eForms .................................................................................................................. 36
2.3.5 Data Interfaces ...................................................................................................... 37
2.4 DATA MODEL ................................................................................................................. 40
2.4.1 Pontis Data Model ................................................................................................. 41
2.4.2 Data Model from BMS Requirements.................................................................... 54
2.4.3 Additional Field Requirements .............................................................................. 65
3. RISKS AND CONTROLS.................................................................................................... 80
3.1 OVERVIEW ..................................................................................................................... 80
3.2 SYSTEM SECURITY ......................................................................................................... 80
3.2.1 Access to the Pontis Client.................................................................................... 80
3.2.2 Access to the BMS Web Application ..................................................................... 82
3.2.3 Access to Structure Data....................................................................................... 83
3.3 RISKS AND CONTROLS .................................................................................................... 85
4. INFRASTRUCTURE REQUIREMENTS.............................................................................. 88
4.1 OVERVIEW ..................................................................................................................... 88
4.2 DATA VOLUMES .............................................................................................................. 89
4.3 NETWORK IMPACTS ........................................................................................................ 90
4.4 MAINFRAME RESOURCES................................................................................................ 92
4.5 SERVER RESOURCES ..................................................................................................... 93
4.5.1 BMS Production Servers ....................................................................................... 93
4.5.2 Development, Test and Training Environments .................................................... 95
4.6 WORKSTATION REQUIREMENTS ...................................................................................... 96
4.6.1 Office Workstations ............................................................................................... 96
4.6.2 Electronic Data Collectors ..................................................................................... 97
5. TRAINING PLAN................................................................................................................. 98
BMS Re-write Phase 2 Conceptual System Design Report i
TABLE OF CONTENTS
BMS Re-write Phase 2
TABLE OF CONTENTS
5.1 OVERVIEW ..................................................................................................................... 98
5.2 END USER TRAINING ...................................................................................................... 98
5.2.1 NHI Pontis Bridge Management Course ............................................................... 98
5.2.2 PENNDOT Pontis Customization Course ............................................................. 99
5.3 TECHNICAL TRAINING ................................................................................................... 100
6. HARDWARE AND SOFTWARE COST ESTIMATES....................................................... 101
6.1 OVERVIEW ................................................................................................................... 101
6.2 HARDWARE COST ESTIMATES....................................................................................... 101
6.3 SOFTWARE COST ESTIMATES ....................................................................................... 102
BMS Re-write Phase 2 Conceptual System Design Report ii
Document Version Control
BMS Re-write Phase 2
Document Version Control
Version Date Description
1 01/22/2004 Initial release of the draft document.
2 02/11/2003 Release of the final document.
BMS Re-write Phase 2 Conceptual System Design Report iii
Introduction
BMS Re-write Phase 2
1. Introduction
1.1 Objective
The objective of the Bridge Management System (BMS) Conceptual System Design Report is to
document the conceptual design of the new BMS required to meet the functional requirements
as originally specified in the Bridge Management System Requirements Definition Report
Volume 1 v2, dated August 22, 2003, and incorporated within the Pontis Level E alternative
architecture selected from the Bridge Management System Alternative System Design Report
v2, dated January 9, 2004. The conceptual design provides a roadmap for how the various
functional and technical pieces of the system will be joined together to form the new BMS,
without specifying the detailed design characteristics for each of those pieces. The conceptual
design report is the deliverable for Task 7 – Conceptual Design of the BMS Re-write Phase 2
project.
1.2 Report Sections
This report is presented in 6 sections. Described below are the remaining sections:
• System Architecture
This section defines the System Architecture for the new BMS including:
° A description of the implementation alternative selected by the BMS Steering
Committee for the new BMS
° A high-level description of the system logic to be implemented by the new system
° A functional description of each application screen, web page, and/or standard report
to be included in the user interface.
° Documentation of the interfaces with other external PENNDOT systems, including
data flow direction, data requirements, interface frequency, and any known
technology requirements (e.g., online transactions, batch file transfers).
° A logical data model, identifying the required BMS data entities and their
relationships to one another.
• Risk and Controls
This section identifies the data processing risks facing the new BMS. Risks are those
undesired events that if not controlled may cause the new BMS to not meet its objectives
(e.g., disruption of business, loss of information). The relevant risks the system faces
and the security and auditing controls to prevent, detect or recover from the risk are
described in this section. The overall security model of the new BMS is also described,
including logical user roles, application security requirements based on those roles,
physical user ID requirements and requirements for external security systems (e.g.
RACF, Windows domains), where applicable.
• Infrastructure Requirements
This section describes the impact of the new BMS on existing PENNDOT infrastructure
components, including network, database, mainframe, server and workstation impacts.
BMS Re-write Phase 2 Conceptual System Design Report 1
Introduction
BMS Re-write Phase 2
Network impact includes estimates of network bandwidth requirements based on
number of transactions/pages, data access requirements, etc. Database impact is
identified through data volume estimates created by the project team based upon the
new BMS data model. Mainframe impact includes a description of the mainframe
resources that will be required by the new BMS, including database stored procedures,
batch cycle processing, print output, and file transfer processing. Server impact includes
a description of each server required by the new BMS, the role that it plays in the
application architecture, estimated capacity requirements and any known special
hardware and/or software requirements. Workstation impact includes the requirements
for end-user workstations, including software deployment, software licensing, and
hardware capacity.
• Training Plan
This section documents the training plan for the new BMS, addressing the training
requirements for both end users and technical personnel.
• Hardware and Software Cost Estimates
This section includes detailed estimates of Hardware and Software costs created by the
project team based upon the information documented in the other report sections.
BMS Re-write Phase 2 Conceptual System Design Report 2
System Architecture
BMS Re-write Phase 2
2. System Architecture
2.1 System Architecture Overview
2.1.1 Selected Alternative System Design
As described in the Bridge Management System Alternative System Design Report v2, dated
January 9, 2004, the BMS selection team recommended the Pontis Level E solution for the
implementation of the new BMS. The BMS Steering Committee approved this selection on
December 18, 2003.
The Pontis Level E solution represents a complete replacement of the current mainframe BMS,
and includes a customized Pontis client for internal PENNDOT users, web-based screens for
use by non-PENNDOT users, and additional components to satisfy the PENNDOT BMS
requirements not met by Pontis. The Pontis Level E solution provides the critical planning,
programming, and maintenance management functionality defined within the BMS
requirements, integration with the PENNDOT EDMS and GIS applications, implements all
required interfaces between BMS and other systems such as MPMS, RMS and MORIS/Plant
Maintenance, and includes updated PENNDOT Bridge Modeling System to provide additional
(component-level) predictive modeling capability. All internal PENNDOT users will use the
customized Pontis fat client application to access and maintain structure data and perform most
other system functions. External users will use separate custom-developed web-based
screens, representing a subset of the screens available within the Pontis client, to maintain and
view data for their structures. External users are limited to accessing only those structures for
which they are specifically authorized. A central server-based Oracle database will be used to
store all the structure data, using the Pontis database structure.
The following is a conceptual component diagram for the Pontis Level E alternative, with the
"package" in the middle of the diagram representing the Pontis client application and database
and the blue areas representing the components that must be custom developed:
BMS Re-write Phase 2 Conceptual System Design Report 3
System Architecture
BMS Re-write Phase 2
Application Web Interface for Home and
Cost Analysis
Security External users Navigation (web)
EDMS Integration Maintenance
• Inventory Interface
Pontis
• Condition Summary
Client
• Maintenance
GIS Integration • Cost Estimating
• Predictive Modeling Oracle APRAS Interface
• Some Reporting Database
Higher levels of configuration
PENNDOT Bridge Other Interfaces
• Inspection Data Management
Modeling • RMS • Video Log
• Inspection Scheduling
(Component-level)
• Crane Scheduling • MPMS • MUSIC
• Structure Planning • ECMS
Common Functions
• Transaction Log EDC Upload/
• Archive EDC Modifications Reporting (Crystal)
Download
• Email
• Audit
Custom Development
Pontis Level E Component Diagram
The primary advantages of the Pontis Level E solution are as follows:
• Employs a Commercial Off-The-Shelf (COTS) package used by 40 agencies in the U.S.,
including 37 state departments of transportation. Use of a COTS package also reduces
the time and cost to deliver the solution.
• Changes PENNDOT business processes to be more in line with FHWA’s future vision
for bridge data collection and prediction of needs. It supports the documentation of
bridge inspections at the element-level, and keeps PENNDOT structure data consistent
with other Pontis agencies.
• AASHTO maintains new releases for improved functionality and application
maintenance. Since Pontis has been a production application for 10 years, most
releases are focused primarily on functional enhancements. The AASHTOWare Pontis
Task Force controls the implementation of fixes/enhancements agreed upon by
participating Pontis users.
The following is a summary of the BMS functions and how they are implemented within the
Pontis Level E solution:
Provided using Provided using
Function Customized Pontis Custom Components
Application Security X X
APRAS Interface X
Common System Functions X X
BMS Re-write Phase 2 Conceptual System Design Report 4
System Architecture
BMS Re-write Phase 2
Provided using Provided using
Function Customized Pontis Custom Components
Common Business Functions X X
Condition Summary X
ECMS Interface X
EDC Modifications X
Inspection Data Maintenance X
Inspection Scheduling X X
Inspection Workflow X X
Inventory Data Maintenance X
Maintenance Interface X
Maintenance Management X X
MPMS Interface X
Predictive Modeling X X
Reporting X X
RMS Interface X
Performance Scorecard and TIP Scorecard X
Structure Planning X
Structure Programming X
Web Interface - Condition Summary X
Web Interface - Inventory X
Web Interface - Inspection X
Web Interface - Structure Planning X
Cost Analysis X X
EDMS Integration X X
GIS Integration X
Inspection Enhancements for New Structures X
Inspector Alert X
Inventory Enhancements for New and Existing Structures X
Video Log Interface X
Data Conversion X
The Pontis Level E solution supports element-level inspection data collection and predictive
modeling while also allowing users to record and/or calculate component-level condition ratings
to satisfy NBI data requirements. Component-level predictive modeling and the prediction of
other PENNDOT performance measures such as load capacity and bridge postings and
closings is supported through the upgrade and continued use of the PENNDOT Bridge Modeling
System. Although the closest alternative to a "native" Pontis implementation, the Pontis Level E
solution requires the development of custom code to integrate the fat client application into the
PENNDOT environment, provide BMS access to external users, implement key functionality
requirements not met by Pontis and to integrate Pontis with other PENNDOT systems such as
RMS, MPMS, ECMS, APRAS, and MORIS / Plant Maintenance.
As with any COTS solution, customization is constrained to some degree in a Pontis-based
solution alternative. Specific user interface requirements may or may not be possible
depending upon what the requirement is and what it affects within the Pontis client application.
For example, Pontis does not support the ability to limit the display of fields that are applicable
to a particular structure type - new High Mast Light data fields may be displayed for bridges,
culverts and all other structure types as well. Therefore, additional changes may be required to
BMS Re-write Phase 2 Conceptual System Design Report 5
System Architecture
BMS Re-write Phase 2
reduce the impact on data integrity that may be caused by presenting the user with more fields
than what is required for a particular structure (e.g., displaying a deck width field for a high mast
light tower).
The Pontis Level E solution requires a server-based, multi-user Oracle database. Since
PENNDOT does not currently support a production Oracle database, the following actions must
be completed in preparation for Pontis implementation:
• Acquire the appropriate Oracle license(s).
• Acquire and configure multiple Oracle servers - a minimum of four servers would be
required to mirror the PENNDOT standard development, system test, training and
production DB2 database environments.
• Provide ongoing support of these servers, requiring additional training of existing
database staff.
• Configure and deploy the Oracle client software on all workstations requiring access to
the Pontis application or ad-hoc reporting against the database.
• Integrate the backup and recovery of the Oracle databases with existing database
backup and recovery schemes, including disaster recovery. Because of the complexity
of the database file structures, simple backups of the server file systems may not
provide adequate point-in-time recovery of the database in the event of an error.
2.1.2 Pontis and Custom Components
The first model shown below, developed as part of the BMS Phase 1 project and included within
the BMS Business Systems Plan v2, dated June 10, 2003, is the original depiction of the future
BMS conceptual design. It shows the Structure Inventory and Condition Data serving as the
foundation of the new BMS, with eleven application subsystems providing the screens and
batch programs for users to maintain structure data and plan and coordinate activities to support
the various business processes associated with BMS and the maintenance of structure assets.
The corresponding legend identifies the five application subsystem categories.
BMS Re-write Phase 2 Conceptual System Design Report 6
System Architecture
BMS Re-write Phase 2
INTERFACE
USER
User Access - External
User Access - Internal
Condition Summary
Predictive Modeling
Structure Planning
Automated Bridge
Analysis Support
Analysis System
Inspection Data
APPLICATIONS
Management
Management
Management
Maintenance
Scheduling
Estimating
Inspection
Reporting
Inventory
Cost
DATA
Structure Inventory & Condition Data
Legend: Inventory Management Asset Management
Inspection Management Reporting
Engineering Analysis
BMS Conceptual Design Model (Original)
With the selection of the Pontis Level E solution for implementation of the new BMS, a modified
conceptual design model is required. While the eleven application subsystems and the overall
functionality depicted in the model remain the same, the new conceptual design model better
depicts how the functionality will be delivered using the Pontis Level E solution:
INTERFACE
USER
User Access - Internal
User Access - External
Pontis
Additional Components
Automated Bridge
Analysis System
Inventory Management Inventory Management
Inspection Scheduling Inspection Scheduling
APPLICATIONS
Reporting
Inspection Data Management Inspection Data Management
Condition Rating Condition Rating
Maintenance Management Maintenance Management
Cost Estimating Cost Estimating
Structure Planning Structure Planning
Pontis PENNDOT
Predictive Modeling Predictive Modeling
DATA
Pontis Database
BMS Conceptual Design Model (Updated)
BMS Re-write Phase 2 Conceptual System Design Report 7
System Architecture
BMS Re-write Phase 2
The updated conceptual design model depicts the Pontis Database serving as the foundation of
the new BMS, supporting the same type of inventory and condition data included in the original
concept. Nine of the eleven application subsystems are supported through the use of base
Pontis functionality and through Pontis customization and/or custom components. The
Automated Bridge Analysis System (ABAS) subsystem, while not included within the Pontis-
based BMS subsystems, will have to be modified to use structure-related data stored within the
Pontis database structure (excluding the Engineering Datasets, which will remain within their
current DB2 database structure). The Reporting application, utilizing a reporting copy of the
Pontis database, will be primarily implemented using the Crystal Reports tool. The user
interface for internal PENNDOT users will be provided through the Pontis client application and
through some use of web-based screens; the user interface for non-PENNDOT external users
will be through web-based screens outside of the Pontis application. The following sections
describe each of the application subsystems in more detail, including descriptions of how each
will be implemented.
2.1.2.1 User Access
As noted in section 2.1.1 above, there are two basic components for the new BMS user
interface. For PENNDOT users, most interaction with the new BMS will occur through the use
of the Pontis client application. Some exceptions will exist for functions such as EDMS and GIS
integration, and for the PENNDOT Bridge Modeling System. For external users and, for some
functions, PENNDOT users, a BMS web application will be implemented that accesses and
maintains data within the same Pontis Oracle database as the Pontis client application.
2.1.2.2 Inventory Management
The Inventory Management subsystem includes applications to add and delete structures to and
from the inventory and to maintain information describing the specific characteristics of a
structure. For PENNDOT users, Inventory Management functionality will be implemented
primarily using the base Pontis client application, although customization is required to support
all of the inventory data items required by PENNDOT as well as customized applets for
functions such as the maintenance of design exceptions and the linkage to structure drawings.
For external users, more limited Inventory Management functionality will be implemented using
the customized BMS web application.
2.1.2.3 Inspection Scheduling
The Inspection Scheduling subsystem supports on-line scheduling of inspections, including
required equipment. Automatic inspection reminder e-mails and alerts for non-routine
inspections are also included. For PENNDOT users, Inspection Scheduling functionality will be
implemented primarily using the base Pontis client application. For external users, Inspection
Scheduling information will be provided using the customized BMS web application
2.1.2.4 Inspection Data Management
The Inspection Data Management subsystem supports the actual structure inspection process,
including inspection review workflow and the maintenance of inspection data. This subsystem
includes support for electronic inspection data collection using eForms, a standalone inspection
data management application that utilizes structure inventory and inspection data downloaded
into Electronic Data Collectors (EDC) for field inspections. While being used in the field,
eForms temporarily stores the downloaded data and updated inspection data in a local
database on the EDC. Once the inspection is complete, inspection data from the EDC is
BMS Re-write Phase 2 Conceptual System Design Report 8
System Architecture
BMS Re-write Phase 2
uploaded into the BMS database for review and reporting purposes. The new BMS will also
support the manual entry of inspection data, although it is anticipated that most inspections will
be performed using EDCs. For PENNDOT users, Inspection Data Management functionality
will be implemented primarily using the base Pontis client application, although customization is
required to support all of the inspection data items required by PENNDOT, as well as
customized applets for functions such as inspector alerts and load rating analysis data. For
external users, Inspection Data Management will be provided using the customized BMS web
application. The current Microsoft Access-based eForms application will be completely
rewritten as part of the new BMS implementation, serving both PENNDOT and external
business partner inspectors.
2.1.2.5 Condition Rating
The Condition Rating subsystem calculates summary information such as sufficiency and
deficiency ratings, and includes calculations for additional performance measures that may be
adopted based on PENNDOT objectives and goals, such as Weak Link and On Deck bridges.
For PENNDOT users, Condition Summary functionality will be implemented primarily using the
base Pontis client application, although customization is required to support all of the data items
required by PENNDOT as well as customized applets for functions such as Total Deficiency
Rating (TDR) and Maintenance Deficiency Rating (MDR) calculations. For external users,
Condition Summary information will be provided using the customized BMS web application.
2.1.2.6 Maintenance Management
The Maintenance Management subsystem supports the ability for District Maintenance
Coordinators to identify candidate structure projects, proposed and completed maintenance
work, and whether PENNDOT or contractor forces will perform the work. In addition, the
subsystem includes an interface with the MORIS/Plant Maintenance system and the ability to
create and maintain proposed work orders, as well as identify recurring work for automatic
scheduling (e.g., annual cleaning). For PENNDOT users, the online Maintenance Management
functionality will be implemented primarily using the base Pontis client application, although
customization is required to support all of the maintenance data items required by PENNDOT as
well as customized applets for functions such as work order maintenance. Custom programs
are required to support the maintenance integration requirements with MORIS/Plant
Maintenance. For external users, Maintenance Management functionality will be provided using
the customized BMS web application.
2.1.2.7 Cost Estimating
The Cost Estimating subsystem supports the creation of cost estimates for structure project
planning and other decision-making needs. It also includes the extract and analysis of cost
information from other PENNDOT systems such as ECMS, MPMS and MORIS/Plant
Maintenance to support the creation of estimating cost factors and unit costs for project cost
estimates. For PENNDOT users, online Cost Estimating functionality will be implemented
primarily using the base Pontis client application, although customized applets are required for
functions such as estimates for non-bridge-related project costs. Custom programs are required
to support the analysis of cost data from other PENNDOT systems. For external users, Cost
Estimating functionality will be provided using the customized BMS web application.
BMS Re-write Phase 2 Conceptual System Design Report 9
System Architecture
BMS Re-write Phase 2
2.1.2.8 Structure Planning
The Structure Planning subsystem directly supports the structure planning process, including
allowing Planning Partners and local bridge owners to generate lists of candidate projects and
integration with ECMS and MPMS to automatically update project numbers and milestones and
allow viewing the work history for a structure. For PENNDOT users, online Structure Planning
functionality will be implemented primarily using the base Pontis client application, although
customization is required to support all of the planning data items required by PENNDOT. For
external users, Structure Planning functionality will be provided using the customized BMS web
application.
2.1.2.9 Pontis Predictive Modeling
The Pontis client application includes an element-level predictive modeling capability. It
provides the ability to forecast bridge conditions and maintenance and improvement costs to
better determine what projects should be planned and programmed. In combination with the
PENNDOT Predictive Modeling capability described below, Pontis Predictive Modeling will
provide the basis for decision making around how and where to use resources for the best
results and to yield PENNDOT performance goals. The Pontis Predictive Modeling functionality
will be implemented completely using the base Pontis client application. This modeling
capability will not be available to external users, although modeling results can be made
available through the Reporting subsystem.
2.1.2.10 PENNDOT Predictive Modeling
The PENNDOT Predictive Modeling subsystem represents the necessary customization and
data extract capabilities for implementing a component-level predictive modeling capability
using the Pontis database. It includes the complete rewrite of the PENNDOT Bridge Modeling
System, including the incorporation of improvements for the modeling system suggested during
Task 2 of the BMS Re-write Phase 2 project. Implementation of the PENNDOT component-
level predictive modeling capability provides an enhanced planning capability by offering
another viewpoint of the future bridge network condition, as well as the impact of proposed
projects. The PENNDOT Predictive Modeling functionality will be implemented using a custom
client application, and will not be available to external users.
2.1.2.11 Automated Bridge Analysis System
The Automated Bridge Analysis System (ABAS) is a standalone workstation application that
allows users to manually check APRAS routes and loads using BMS data. The Engineering
Dataset Manager is used to create datasets for use by ABAS and other engineering programs.
As depicted in the diagram, functionality within the Automated Bridge Analysis System will
utilize data from the Pontis BMS database, but will not have an integrated user interface with the
other Pontis and customized BMS web application components, and will not be available to
external users.
2.1.2.12 Reporting
Standard (scheduled and as needed) and ad hoc reporting requirements will be met using the
standard reports defined within the Pontis client application and new reports created using the
Crystal Reports tool. Reports created in Crystal Reports will be deployed using the Crystal
Enterprise web server, which allows users to access reports via a web browser without having
the Crystal Reports tool installed on their local workstation. As depicted in the diagram, reports
BMS Re-write Phase 2 Conceptual System Design Report 10
System Architecture
BMS Re-write Phase 2
will access data from the Pontis BMS database - either the Oracle production database or a
DB2 copy. Some reports may also be available to external users through a specific Crystal
Enterprise server implemented for external use, although the reports will only include data
specific to the user's organization (e.g., bridge inspection consultant).
2.1.3 System Interfaces & Reporting Database
The implementation of the Pontis client application as part of the new Pontis-based BMS will
require the use of an Oracle database on a Windows-based server. This represents a
departure from the existing data architecture for other PENNDOT “line of business” systems in
which existing data resides in mainframe-based databases (DB2 and IMS). To simplify the
integration of BMS data with this existing mainframe architecture, the Pontis BMS Oracle
database will be “mirrored” in DB2 on the mainframe, as depicted in the following figure:
Eng Other PENNDOT Systems
BMS
Pontis ABAS Dataset (APRAS, RMS, MPMS,
Web
Mgr ECMS, etc.)
Nightly Database Replication Process
Extract FTP Load
Oracle DB2
Database Database
Load FTP Extract
(Prod) (Query)
Standard Ad-hoc
Reports Reports
Crystal Enterprise Server
The Pontis client application and the custom BMS web-based application will access the Oracle
database directly. On a nightly basis, the Oracle database will be exported to flat-files that will
then be transferred to the mainframe. The DB2 version of the database will be reloaded with
this fresh copy of the Oracle data. Note that two BMS components, ABAS and the Engineering
Database Manager, currently access bridge data from DB2 - these components will be modified
and continue to use revised tables in DB2. To keep the Oracle and DB2 data in sync, the DB2
tables being updated by the ABAS and Engineering Database Manager components will be
extracted, transferred and loaded into the Oracle database. Only those tables that are
specifically controlled by these components will be transferred; all other BMS data is assumed
to be sourced and maintained within the Oracle database.
The DB2 version of the BMS database will be used to support data requests from other
PENNDOT systems that currently execute on the mainframe (e.g., RMS) or access DB2 data in
a client-server environment (e.g. APRAS, ECMS, MUSIC, MPMS).
Because the Oracle database provides the production BMS data supporting the needs of the
production BMS applications and users, ad-hoc query access to this database will be restricted.
BMS Re-write Phase 2 Conceptual System Design Report 11
System Architecture
BMS Re-write Phase 2
Crystal Enterprise Server will be used to provide standard reports from Oracle when it is
determined that those reports must show time-sensitive data and the data access will not
adversely impact the production system. Longer-running standard reports and ad-hoc reports
will be provided via the DB2 version of the database.
In addition to the data integration provided by the shared data architecture on the mainframe,
the new Pontis-based BMS application will provide data extracts to other applications (e.g. GIS,
Plant Maintenance, RMS). Because of the more robust operational environment on the
mainframe, these extracts will be provided by nightly batch jobs running against the DB2
database.
The model shown below depicts each of the systems and services with which the new Pontis-
based BMS will interface. As referenced in the diagram, a “system” is an information system
that processes data for a business purpose; a “service” is a technology that other systems can
use to store and/or deliver related information to users. The arrows show the direction of the
interfaces.
MORIS/
RMS MPMS ECMS APRAS
mySAP
Pontis BMS Database (Oracle or DB2)
GIS Video Log EDMS
Legend:
System Service
The following is a brief description for each of the interfaces depicted in the diagram. Section
2.3 includes more detailed descriptions of how each interface will function.
2.1.3.1 RMS
The Roadway Management System (RMS) defines segment offsets used by PENNDOT legacy
systems in addition to storing roadway conditions, highway performance, inventory, inspection,
and appraisal data to compute needs estimates for all roadways in Pennsylvania. This interface
keeps location referencing data synchronized in both systems and provides the new BMS with
roadway-related data such as average annual daily traffic and average annual daily truck traffic
information.
BMS Re-write Phase 2 Conceptual System Design Report 12
System Architecture
BMS Re-write Phase 2
2.1.3.2 MPMS
The Multi-Modal Project Management System (MPMS) is used by PENNDOT district and
central office users to develop and manage the Twelve Year Program (TYP), the State
Transportation Improvement Program (STIP), and the Transportation Improvement Program
(TIP). A portion of the information is displayed in a web-based system used to share
PENNDOT project and program information with various groups of users. This interface will
allow MPMS data, such as program/project costs, milestone dates and information that supports
the TIP and TYP, to be shared with BMS, and vice versa.
2.1.3.3 ECMS
The Engineering and Construction Management System (ECMS) currently has a one-way
interface used to obtain select structure descriptive information. A two-way interface is
envisioned for the new BMS to provide cost data as well as other project information for cost
estimating purposes.
2.1.3.4 MUSIC
The Municipal Services Information Center (MUSIC) maintains information on all public non-
State roads. The information is used for disbursement of local fuels tax money. An annual BMS
extract is performed to calculate funds that should be withheld from municipalities to pay for
bridge inspections conducted on their behalf by PENNDOT. MUSIC also has a location
referencing system that could be referenced in BMS for local bridges. . Note that municipality-
owned structures currently stored within the MUSIC system may be stored within the new
Pontis-based BMS in the future.
2.1.3.5 APRAS
The Automated Permit Routing / Analysis System (APRAS) uses BMS data to perform bridge
analyses in support of the generation and approval of oversize and overweight hauling permits.
Information about permits that have been granted for loads to pass over specific structures can
be used to support load rating analysis within BMS.
2.1.3.6 MORIS/mySAP
The Maintenance Operations Reporting Information System (MORIS) does not currently
interface directly with BMS. However, there are many advantages offered by a new two-way
interface between BMS and MORIS or the SAP Plant Maintenance module that will eventually
replace MORIS, such as the reduction/elimination of duplicate data entry. Synchronization of
activity codes is required to support automatically transferring hour and cost data as well as
logging the completion of activities.
2.1.3.7 GIS
The Geographic Information System (GIS) is a service used by many PENNDOT bureaus and
district offices for automated data mapping and planning purposes. GIS uses BMS information
to display bridge locations in a map format and provide bridge data. The new BMS will provide
the means to directly navigate to GIS for the display of BMS information on a variety of maps.
2.1.3.8 Video Log
Video Log provides a series of still-shot digital photographs presented in a "movie" format, so
that the user's view replicates driving down a highway. The Video Log is a quick and easy
BMS Re-write Phase 2 Conceptual System Design Report 13
System Architecture
BMS Re-write Phase 2
source to view general roadway conditions, bridge vertical clearance, structure or sign
placement, etc., providing a great deal of insight to planners and engineers in researching
bridge projects. The interface between Video Log and the new BMS will provide links to display
the Video Logs associated with a particular structure.
2.1.3.9 EDMS
The Electronic Document Management System (EDMS) is PENNDOT’s enterprise-wide
document imaging and management service. EDMS does not interface with the current BMS,
but a two-way interface between the new BMS and EDMS will provide the means to store, link,
and retrieve structure related images and documents.
In addition to the interfaces described above, two other interfaces were discussed as part of the
BMS requirements but were not included within the new BMS conceptual design because
corresponding PENNDOT systems do not yet exist.
• Enterprise Data Warehouse - An Enterprise Data Warehouse is a service that provides
users with an improved capability for querying and generating reports and statistics from
the data copied into the warehouse from the source production system. The data
warehouse can also facilitate queries involving data from multiple source systems that
exists in the warehouse. Such data can be reformatted to optimize it for querying and
stored in data marts created for the target user population. A data warehouse and data
mart have been created for the CRASH system as a pilot of the overall concept.
However, expansion of the data warehouse to include data from other systems is on
hold at this point in time as PENNDOT reviews the data warehouse capabilities that will
be provided by the ImaginePA (Commonwealth SAP) project.
• Asset Management - An Asset Management System does not yet exist today at
PENNDOT. Conceptually, an asset management system could be an overall system
that ties together asset management functions for all asset categories such as bridges,
roadways and signs.
BMS Re-write Phase 2 Conceptual System Design Report 14
System Architecture
BMS Re-write Phase 2
2.2 Human Interfaces
The following is a list of all the "human interfaces" to be provided by the new Pontis-based BMS.
Human interfaces are online screens and reports with which users will interact directly when
performing BMS-related functions. Note that access to these human interfaces is controlled
based upon a user's role and permissions within the new Pontis-based BMS; reference section
3.2 System Security for details about the security logic for these screens and reports. Human
interfaces do not include batch programs or other non-visual application interfaces that exist but
do not require user interaction.
The descriptive information within this section for the Pontis application components was
derived from Appendix C and Appendix D of the Pontis Release 4.3 User's Manual, prepared for
AASHTO by Cambridge Systematics and dated September 5, 2003.
2.2.1 Pontis Application Screen Components
The following is a summary of the application screens included within the base Pontis client
application. Some of these screens may be impacted by customization required to meet
PENNDOT requirements.
Name Purpose U/I Type BMS Function
About Pontis Displays the Pontis logo, copyright information, serial Screen Common System
number and build date for the Pontis software Function
installation.
Add Parameter Allows the user to add a parameter for a database field. Screen Common Business
Examples of a parameter are 0 - Do nothing, 1 - Function
Replacement, 2 - Improvement, 3 - Rehab., etc.
Add/Edit Element Detail Allows the user to add a new condition unit to a Screen Inventory Data
structure or view and edit detailed information about a Maintenance
selected condition unit.
Add/Modify Funding Allows the user to create a new funding source or view Screen Structure Planning
Source details on an existing funding source.
Add/Modify Program Allows the user to create a new program or view details Screen Structure
on an existing program including Program ID, Type, Programming
Name, Objective and Start Year, End Year, Status and
Notes.
Adjust MR&R Model Allows the user to conduct sensitivity analysis to Screen Structure Planning
Costs determine the impacts of increases or decreases in
agency and user cost assumptions for Maintenance,
Rehabilitation and Replacement (MR&R) models.
Advanced Parameters Used to update various advanced parameters for the Screen Predictive Modeling
currently selected scenario. Example of advanced
parameters are H1 - Health Index Break 1, MW -
Minimum Width Deficiency, etc.
Annual Funding Levels Allows the user to set or modify the funding levels for Screen Structure
each program year of the current Budget Set. The Programming
bottom portion of the screen shows the budget by year
for the set selected at the top of the screen.
BMS Re-write Phase 2 Conceptual System Design Report 15
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Bridge Analysis Allows the user to simulate the future conditions of a Screen Predictive Modeling
structure based on the effects of a user-selected set of
work candidates and work items. After an analysis is
complete several result tabs appear containing the
tables and graphs that summarize performance
measures, projected costs, projected health index and
the sufficiency rating values, etc.
Bridge Selection A pop-up dialog screen that allows the user to select the Screen Common Business
structures to be included in a report or simulation. Function
Program Simulation and Reports listing specific bridges
typically utilize this screen.
Build A New Structure Allows the user to add a new structure to the inventory Screen Inventory Data
Record by entering the required information and clicking OK. Maintenance
Calculator This pop-up is opened with the option Calculator on the Screen Common System
right mouse menu available within numeric fields. The Function
original value is copied into the number display of the
calculator, where it may be modified.
Calendar This pop-up is opened with the option Calendar on the Screen Common System
right mouse menu available within date fields. Function
Check In Data Allows the user to check data into Pontis. After Screen Inspection Data
specifying an input file, the file is checked in by clicking Maintenance
the Check-in button. If exceptions are found in the
check-in process (e.g., structures for which information
changed in the master database following the check-out
operation), the user can select which exceptions to
accept.
Check Out Data Allows the user to check data out of Pontis, i.e., export Screen Inspection Data
Pontis Data Interchange Files (PDIs) out of Pontis. Maintenance
Check-In Exceptions Shows all PDI exceptions and provides the user with the Screen Inspection Data
option of accepting or rejecting each exception. Maintenance
Exceptions occur when Pontis attempts to check in data
for a structure, but finds that the data for the structure
changed in the master database following the check out
operations. By accepting an exception, the user allows
the structure to be checked back into Pontis potentially
overriding recent changes in the master database.
Combine Projects Allows the user to combine multiple projects into one Screen Structure Planning /
master project. Maintenance
Management
Configuration - Actions Maintains the codes and associated meanings of the Screen Common Business
Card different action types within Pontis. If changes are Function
made to action types, the user will be prompted to save
them before they can switch to another card or when
the Configuration module is closed.
Configuration-Cost Index Maintains the Pontis construction cost index table. This Screen Common Business
Card table is used to inflate unit costs to the current year for Function
use in the preservation models.
Configuration-Definitions Maintains the codes and associated meanings for Screen Common Business
Card element environments, element materials, element Function
categories and element types.
BMS Re-write Phase 2 Conceptual System Design Report 16
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Configuration-Element Allows the user to modify element definitions, create or Screen Common Business
Specifications Card delete elements and modify their condition state Function
language and feasible actions.
Configuration-Formulas Used to create and edit formulas for performing global Screen Common Business
Card data changes or for correcting missing or erroneous Function
data. A typical formula consists of a set of logical steps
that will set new database values for bridges or other
types of data meeting certain conditions. Typically,
these formulas are used for very simple data
operations. More complex manipulations may require
the use of Structured Query Language (SQL) or agency
custom programs outside of the Pontis application.
Configuration-Maintain Allows the user to modify, add and delete flexible (flex) Screen Common Business
Flexible Actions Card actions. This dialog screen is accessed from the Function
Maintain Flexible Actions button on the Configuration
Actions card.
Configuration-Options Allows the user to modify a variety of customizable Screen Common Business
Card options that affect screen displays and system Function
operations.
Configuration-Parameters Many fields in the Pontis database are restricted to a Screen Common System
Card limited number of allowable coded values. The Function
parameters card allows the user to view and modify the
PARAMTRS table, which keeps track of what each of
the codes mean.
Configuration-User Allows the user to set up new Pontis users, and modify Screen Common System
Administration Card user information and Pontis access privileges. Function
Create New Element Allows the user to create a new element in the system. Screen Inventory Data
Specification New elements must be created using this dialog before Maintenance
condition information may be entered for them in the
Inspection module.
Create/Split Project - Shows a list of the new projects that will be created if Screen Structure Planning /
Project IDs the user splits an existing project or creates a new Maintenance
project with existing work candidates according to the Management
settings on the left half of the screen.
Create/Split Project(s) – Allows the user to either split the work items in an Screen Structure Planning /
Work Items/Candidates existing project into multiple projects or to create a Maintenance
project or multiple project from existing work candidates. Management
Edit Parameter Long Allows the user to edit the long description of a Screen Common System
Description parameter value. Function
Edit Pontis Database List Allows the user to establish and modify Pontis database Screen Common System
profiles. The user must first set up an ODBC data Function
source for each database and then use this dialog
screen to associate a Pontis database profile name with
the ODBC data source.
Edit SQL WHERE Clause Allows the user to review and directly edit the SQL Screen Common Business
WHERE clause that will be applied for each user. This Function
customized WHERE clause is initially created from the
Set Bridge Access Privileges screen. All syntax and
settings are the responsibility of the user.
Edit State Definition Allows the user to edit the state definition for the Screen Common Business
element. Function
BMS Re-write Phase 2 Conceptual System Design Report 17
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Existing Agency Policy Used to modify information about existing Agency Policy Screen Predictive Modeling
Sets Sets, select an Agency Policy Set for editing, or create
new Agency Policy Sets. Agency Policy Sets are sets
of alternative standards that can be established to
conduct what-if analyses.
Existing Cost Sets Used to modify information about existing cost sets in Screen Predictive Modeling
the Cost Matrix, select a Cost Set for editing, or create
new Cost Sets. Costs Sets are sets of alternative
improvement costs (which can be varied according to
traffic volume class, functional class, funding
responsibility and NHS-status) that can be established
to conduct what-if analyses.
Existing Improvement Used to modify information about existing Improvement Screen Predictive Modeling
Sets Sets, select an Improvement Set for editing, or create
new Improvement Sets. Improvement Sets are sets of
alternative modeling assumptions used by Pontis to
estimate the benefits of improvements that can be
established to conduct what-if analyses.
Existing Look Ahead Sets Used to modify information about existing Look Ahead Screen Predictive Modeling
Rule Sets, select a Look Ahead Set for editing, or create
new Look Ahead Sets.
Existing Policy Sets Used to modify information about existing policy sets, Screen Predictive Modeling
select a set for editing, or create new sets.
Existing Rehab Sets Used to modify information about existing Rehab Rule Screen Predictive Modeling
Sets, select a Rehab Set for editing, or create new
Rehab Sets.
Existing Scoping Sets Used to modify information about existing Scoping Sets Screen Predictive Modeling
in the Rules Matrix, select a Scoping Set for editing, or
create new Scoping Sets.
Expert Condition Unit Allows the user to record expert judgments regarding Screen Structure Planning
Cost Elicitation unit costs of different preservation actions.
Expert Transition Allows the user to record expert judgments regarding Screen Predictive Modeling
Probability Model how different structure elements deteriorate.
Elicitation
Export Data Allows the user to export data from Pontis in a number Screen Common System
of different formats, including Pontis Data Interchange Function
File (PDI), Pontis Data Interchange Custom Export File
(PDI), Metric NBI File, and English NBI File.
Field Definition Shows a short description of the field in which the user Screen Common System
has right-clicked. Function
Field Options This pop-up window is opened by clicking the right Screen Common System
mouse button in a field. It displays several field-level Function
options, including Calculator and Calendar.
Filter Allows the user to select the filter criteria for a column, Screen Common System
launched by selecting Filter from the Field Options pop- Function
up window.
Filter Values Allows the user to select valid filter criteria for the Screen Common System
selected column, launched from the Filter screen. Function
BMS Re-write Phase 2 Conceptual System Design Report 18
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Find Project Allows the user to find a particular project, launched Screen Common Business
when the Find button is clicked on the Project Planning Function
desktop if the project list is currently being displayed.
Find Structure Allows the user to find a particular structure. It appears Screen Common Business
when the Find button is clicked on the Inspection, Function
Project Planning or Gateway desktops and next to fields
requiring a Bridge Id.
Fixup Configuration Allows the user to restore the default values to the Screen Common System
Options options in the COPTIONS table of the database. Function
Formula Maintenance Used to edit Pontis formulas selected on the Screen Common Business
Configuration Module Formulas Card. Function
Funding Source Setup Allows the user to view and edit the funding sources Screen Structure Planning
defined in the database.
Gateway Desktop Allows the user to browse through the different Screen Common Business
structures in the inventory, define a subset of the Function
database to work with or find a particular structure.
Import Data Allows the user to import data into Pontis from a number Screen Common System
of different formats, including Pontis Data Interchange Function
File (PDI), NBI File, Parameters, and various types of
Pontis 2.0 files.
Improvement Parameter Used to enter improvement benefit model parameters. Screen Predictive Modeling
Settings
Inspection Agency Card Allows the user to configure custom information about Screen Inventory Data
bridges. This card has up to four virtual pages for Maintenance
bridges, inspections, structure units, and roadways.
These screens will not exist if there are no user tables.
Inspection Appraisal Card Shows information about the load ratings and posting Screen Inspection Data
– Load Ratings status of the structure. Maintenance
Inspection Appraisal Card Shows information related to the appraisal of the Screen Inspection Data
– Other Ratings structure, as well as to clearances and navigation data. Maintenance
Inspection Condition Card Shows NBI and element-level condition information for Screen Inspection Data
the structure. From this card, the user can edit Maintenance
condition data, add and remove elements from the
structure, and calculate the sufficiency rating or the NBI
rating.
Inspection Desktop Allows the user to navigate through the structure list and Screen Inspection Data
access all the other features of the inspection module, Maintenance
including creating a new inspection, viewing past
inspections, calculating NBI condition and sufficiency
ratings, etc.
Inspection Inventory – Shows classification information about the bridge Screen Inventory Data
Classification structure. Maintenance
Inspection Inventory - Shows design-related information about the selected Screen Inventory Data
Design structure. Maintenance
Inspection Inventory - Provides identification and administrative structure Screen Inventory Data
ID/Admin information for the selected structure. Maintenance
Inspection Inventory - Shows roadway information for the selected structure. Screen Inventory Data
Roads Maintenance
BMS Re-write Phase 2 Conceptual System Design Report 19
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Inspection Inventory - Describes the structure units of the selected structure. Screen Inventory Data
Structure Units Maintenance
Inspection Multimedia Shows multimedia information for the selected structure. Screen Inventory Data
Card This screen is used to link multimedia documents such Maintenance
as pictures, drawings, media files, and other documents
to either the current inspection or bridge.
Inspection Notes Card Allows the user to enter notes or comments about the Screen Inspection Data
structure, or about the current inspection. Maintenance
Inspection Schedule Card Displays information about the most recent inspection of Screen Inspection
the structure, including the dates of the next scheduled Scheduling
inspections, and information on established policies for
the structure regarding the frequency of regular and
special inspections and estimated resource
requirements.
Inspection Work Card Allows the user to recommend work candidates for the Screen Inspection Data
bridge, and to edit or remove work candidates. Maintenance
Login To Pontis Allows the user to log onto Pontis and select the active Screen Common System
database for the session. Function
Message History List Displays a history of the system messages, with the Screen Common System
most recent activity at the top. This screen is used Function
mainly for Pontis Support troubleshooting, but users can
see if changes were successful and other information by
reviewing the message history.
Model Update Settings Allows the user to set various options for updating the Screen Predictive Modeling
preservation models and update the models.
MR&R Model Information Allows the user to adjust the preservation costs used in Screen Predictive Modeling
the optimization model for inflation, and conduct
sensitivity analysis to determine the impacts of
increases or decreases in agency and user cost
assumptions.
NBI Project Data Allows the user to view and update the NBI fields Screen Structure Planning
related to planned projects for a structure.
Network-Level Results The Results modules allow the user to view information Screen Predictive Modeling
Desktop about needs, programmed work, and performance
measures for any program scenario or work program.
Before viewing Results reports on a scenario, the
scenario must be run in the Programming module.
New Inspection Setup Used to add a new inspection record for a structure, Screen Inspection Data
launched when the New button is clicked on the Management
Inspection Desktop.
New/Open Project - Contains information about a project's contracting and Screen Structure Planning /
Contract & Funding its funding sources. Maintenance
Management
New/Open Project - Allows the user to create a new project or edit the Screen Structure Planning /
Overview information for an existing project. The Overview tab Maintenance
contains general project-level information. Management
New/Open Project - Work Contains a list of the work items assigned to the project Screen Structure Planning /
Items and detailed information about a selected work item. Maintenance
Management
BMS Re-write Phase 2 Conceptual System Design Report 20
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Notes Allows the user to view and, where applicable, edit the Screen Common System
notes related to the selected screen item. This screen Function
extends normal editing within a form field to provide full-
screen display, print, help and Windows clipboard
support. This screen is launched by pushing the notes
icon wherever it appears in Pontis.
Policy Variable Settings Used to establish service and design standards that Screen Predictive Modeling
Pontis models compare with actual roadway and
structure characteristics, and determine what
improvements would be required to bring all structures
up to the standards.
Pontis Report Manager Allows the user to select a report from a list of available Screen Reporting
reports, preview it on the screen, and send it to the
printer. Data can also be saved to an output file.
Preservation Desktop Displays the preservation policy and details about cost Screen Structure Planning
and deterioration models for a selected element and
environment. From here the user can select different
elements and/or environments, edit expert elicitations,
update the models based on elicitation or historical
results, or build the preservation optimization model.
Program Setup Allows the user to view and edit the programs defined in Screen Structure
the database. Programming
Programming Desktop Used to define and run program scenarios. It provides Screen Structure
access to screens used for entering functional Programming
improvement standards, cost and benefit assumptions,
annual budgets, improvement models, and simulation
rules.
Project Planning Desktop Allows the user to navigate through a structures list or a Screen Structure Planning /
list of projects and access all the other features of the Maintenance
Project Planning module. This screen may optionally Management
display three different panes: a structure/project list, a
tree navigator and a work candidate description window.
Rank Projects Allows the user to rank projects in a particular work Screen Structure
program for one or all program years. Programming
Recalculate Failure Cost Allows the user to recalculate failure costs for the cost Screen Structure Planning
elicitations of one or more users. Using this screen,
failure costs are calculated as the element weight
multiplied by the cost of the most expensive action for
the element (typically replacement).
Rules - Agency Policy Allows the user to view and modify Agency Preservation Screen Predictive Modeling
Policy Sets. Agency preservation policies help control
the behavior of the program simulation. The policy
consists of a set of detailed decisions rules for
specifying what actions to take on selected elements
based on element conditions.
Rules - Look Ahead Allows the user to view and modify Look Ahead Rule Screen Predictive Modeling
Sets. Look ahead rules help control the behavior of the
program simulation. The rules cause work to be
deferred if a major project has already been scheduled
in the future for the structure.
BMS Re-write Phase 2 Conceptual System Design Report 21
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Rules - Major Rehab Allows the user to view and modify Major Rehabilitation Screen Predictive Modeling
Rule Sets. Major rehabilitation rules help control the
behavior of the program simulation. The rules force the
simulation to schedule a major rehabilitation or
replacement project based on the condition of the
structure, or based on the cost of recommended work.
Rules - Scoping Allows the user to view and modify Scoping Rule Sets. Screen Predictive Modeling
Scoping rules help control the behavior of the program
simulation. The rules cause Pontis to recommend
specified work on specified elements when other work is
generated.
Rules Overview Allows the user to view and modify program simulation Screen Predictive Modeling
rules, and the agency preservation policy, which help
control the behavior of the program simulation. The
user can view and modify Scoping Rule Sets, Look
Ahead Rule Sets, Major Rehab Rule Sets and Agency
Policy Rule Sets.
Save Structure/Project Allows the user to save the current structure or project Screen Common System
List list layout, after modifying column widths and locations. Function
Select a Project Lists all the projects in the database, allowing the user Screen Structure Planning /
to select a project to use to populate another screen. Maintenance
Management
Select Directories Allows the user to select a directory where data is Screen Common System
stored. Function
Select Formula Fields Displays all the tables and fields which can be used in Screen Common Business
Pontis formulas, and allows the user to paste a field into Function
the formula text in the Formula Maintenance window.
Select Projects Allows the user to select which projects will appear on Screen Structure Planning /
the project list using a fixed set of project criteria - Maintenance
Program, Action Type, Project Status, Review Status, Management
Treatment, Route, KM Post, Program Year, End Date,
Project Id, and Create Date. All criteria that are applied
on this screen will be retained between Pontis sessions.
Select Structures Allows the user to select which structures will appear on Screen Common Business
the structure list using a fixed set of structure criteria - Function
District, Ownership, Counties, Roadway Functional
Class, NHS Status, Administrative Areas, Inspectors,
Inspection Due Dates, and Bridge Id. All criteria applied
on this screen are retained between Pontis sessions.
Select Work Candidates Allows the user to select which work candidates will Screen Structure Planning /
appear in the work candidate window using a fixed set Maintenance
of criteria - Sources, Scenarios, Inspection Priorities, Management
Inspection Status, Flex Actions, Action Types, Element
Types, Elements, Dates, Cost, Bridges, and Status.
Set Bridge Access Allows the user to automatically restrict, for each Pontis Screen Application Security
Privileges user, the structures that will appear on the structure list
in the Inspection and Gateway modules. A fixed set of
structure criteria is available: Districts, Counties, Admin
Areas, Owner, Custodian, Bridge Group, or a
customized SQL query. The restrictions set here are
applied for each user individually and are stored in the
database.
BMS Re-write Phase 2 Conceptual System Design Report 22
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Shift Projects Allows the user to change certain attributes of several Screen Structure Planning /
projects at once. For example, one or more projects Maintenance
can be shifted from one program to another or from one Management
year to another.
Show Projects Lists all the projects to which the selected work Screen Structure Planning /
candidate is assigned. Work candidates are assigned Maintenance
in the Project Planning module. Management
Simulation Elements Used to select which structure elements are to be Screen Predictive Modeling
included in the simulation for the currently selected
scenario.
Sort Allows the user to select the sort order and direction for Screen Common System
each column on a screen, launched by selecting Sort Function
from the Field Options pop-up window.
Sufficiency Rating Results Displays calculated sufficiency ratings and allows the Screen Condition Summary
user to accept the new ratings (individually or all at
once) and save them to the database.
Translator Results Displays calculated NBI condition ratings for deck, Screen Condition Summary
superstructure, substructure and culvert and allows the
user to accept the new ratings (individually or all at
once) and save them to the database.
User and Agency Cost Used to enter cost and benefit assumptions for Screen Structure Planning
Variable Settings functional improvement actions.
Validation Results Appears when the user selects the Validate button on Screen Inspection Data
the Inspection Desktop or on the Inspection Condition Management
card. Data validation checks, such as the FHWA
Edit/Update checks are performed for the selected
bridges.
2.2.2 Pontis Application Reports
The following is a summary of the standard reports included within the base Pontis client
application.
Name Purpose U/I Type BMS Function
CONFIG001: Elements, Provides a summary definition of each element in the Report Common Business
States, and Actions database. Function
CONFIG002: User Provides an alphabetical listing of all user configurable Report Common Business
Configurable Options List options defined in the database. These options may be Function
edited through the Options card of the Configuration
Module.
CONFIG003: Parameter Details the parameterized database fields stored in the Report Common Business
Report database. Function
CONFIG004: Data Details the contents of the Pontis data dictionary. Report Common System
Dictionary Function
CONFIG005: INI File Displays an INI file selected by the user. This report is Report Common System
Report available through the Pontis interface only and cannot Function
be previewed in InfoMaker.
CONFIG006: User List Details the users defined in the database. Report Application Security
BMS Re-write Phase 2 Conceptual System Design Report 23
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
CONFIG007: Provides details on system parameters not included in Report Common Business
Miscellaneous System other configuration reports, including information on Function
Parameters environments, element materials, element categories,
and action types.
CONFIG008: Flexible Details the flexible actions defined in the database. Report Maintenance
Actions Management
INSP001: Inspection Shows the Structure Inventory and Appraisal report in Report Inspection Data
SI&A (Metric) metric units, similar to the INSP002 report except that it Management
does not include structure or inspection notes. The
report details inventory and inspection data for the most
recent inspection performed for the selected structures.
INSP002: Bridge Shows bridge inspection data in metric units. This Report Inspection Data
Inspection Report (Metric) report is similar to the INSP001 report, except that Management
unlike the INSP001 report, this report includes structure
and inspection notes.
INSP003: Inspection Useful for inspection scheduling and planning, this Report Inspection
Scheduling Information report lists the date and inspector for the most recently Scheduling
completed regular and special inspections for the
selected structures.
INSP004: Inspection Displays the dates of the previous and next inspections Report Inspection
Resource Requirements and required inspection resources. Only structures with Scheduling
special resource requirements are shown in the report.
INSP005: Bridge Health Calculates the health index for the selected structures Report Condition Summary
Index Detail as of most recent element inspection. The health index
is calculated as the sum of the current value of all
condition units divided by the sum of total value of all
condition units - an index of 100% indicates that all of
the condition units are in the best possible condition
state; an index of 0% indicates that all of the condition
units are in the worst possible condition state.
INSP006: Network Provides a network element summary in metric units. Report Inventory Data
Element Summary The report shows a list of the elements in the network, Management
Distribution (Metric) the units in which the element is measured, and the
details of the quantities of that element by environment.
INSP007: Inspection Same as INSP001, in English units. Report Inspection Data
SI&A (English) Management
INSP008: Bridge Same as INSP002, in English units. Report Inspection Data
Inspection Report Management
(English)
INSP009: Network Same as INSP006, in English units. Report Inventory Data
Element Summary Management
Distribution (English)
INSP010: Bridge Displays a condition summary for the selected Report Condition Summary
Condition Summary structures as of the most recent inspection for each
structure.
MODELS001: Total Shows unconstrained preservation needs, and the Report Predictive Modeling
Unconstrained Needs potential benefit of meeting the needs by element
category, material type and year for the current
scenario.
BMS Re-write Phase 2 Conceptual System Design Report 24
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
MODELS002: Details the preservation models for each condition unit, Report Predictive Modeling
Preservation Model including the recommended actions for each
Details element/environment combination.
PLAN001: Pontis- Lists the preservation needs for the current scenario by Report Predictive Modeling
Generated Preservation structure and program year.
Needs
PLAN002: Projects and Shows all projects and work candidates for selected Report Structure Planning
Work Candidates by structures. The report includes separate sections for
Bridge projects, inspector candidates, and Pontis candidates.
PLAN003: Project Priority Displays a list of projects, sorted by program, program Report Structure Planning
List year and benefit/cost ratio.
PLAN004: Project Details Displays project details, including contract data, costs Report Structure Planning
Sheet and benefits, funding sources and work items.
PLAN005: Actual versus Shows the actual versus budgeted work by program. Report Structure
Budgeted Work For each program the report lists the program Programming
identification, name, and actual and budgeted work by
program year.
PLAN006: Program Shows funding for each program by program year and Report Structure
Funding funding source. Information is displayed in a crosstab Programming
format.
PLAN007: Pontis Priority Displays a list of projects recommended by Pontis for Report Predictive Modeling
List the current scenario, sorted in decreasing order by
benefit/cost ratio. This report differs from PLAN003 in
that it reports on Pontis work candidates generated by
running a program simulation, rather than on actual
projects.
PLAN008: Pontis Work Displays a list of all work candidates generated by Report Predictive Modeling
Candidate List Pontis during the simulation of the current scenario. It
differs from PLAN007 in that it shows all candidates,
regardless of whether or not Pontis models them as
being programmed, and shows the details for each
candidate, rather than grouping the candidates together
by bridge.
PROG001: Bridge Provides an overview of the state of the bridge network, Report Structure
Management Network including Age Distribution, Element Distribution and Programming
Summary Condition, HBRR Eligibility Information, Material Types
and Deck Area, Recent Inspection Activity, Future
Needs and Level of Service, Current Needs and
Network Health Index by Year.
PROG002: Backlog Shows the budget and backlog for preservation, Report Structure
Summary Report replacements, and other improvements besides Programming
replacements, as well as the total amount budgeted and
the cumulative backlog for each simulation year for the
current Pontis scenario.
PROG003: Total Needs Summarizes the needs and programmed work over time Report Predictive Modeling
vs. Programmed Work for the current Pontis scenario. Performance measures
Over Time are reported by district, functional class, on/off National
Highway System (NHS) status, and on/off State System
status.
BMS Re-write Phase 2 Conceptual System Design Report 25
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
PROG004: Annual Summarizes needs and programmed work for the Report Predictive Modeling
Allocation of Needs and current Pontis scenario for each program year,
Work providing separate summaries and graphs for each
program year by district, functional class, on/off National
Highway System (NHS) status, and on/off State System
status.
PROG005: Bridge Summarizes bridge-by-bridge performance measures Report Predictive Modeling
Performance Measure for the current Pontis scenario for each program year.
Summary Note that the user must specify that the system store
bridge-level metrics to use this report. The following
performance measures are displayed for each structure:
Health Index, Sufficiency Rating, Structural
Deficiency/Functional Obsolescence Status and NBI
Ratings.
PROG006: Network Summarizes performance measures for the entire Report Predictive Modeling
Performance Measure network. Performance measures are broken down by
Summary district, functional class, on/off National Highway
System (NHS) status, and on/off State System status.
PROG007: Element Summarizes the needs and programmed work over time Report Predictive Modeling
Condition Over Time by element for the current Pontis scenario.
PROG008: Annual Needs Summarizes the needs and programmed work over time Report Predictive Modeling
and Programmed Work by element category and element for the current Pontis
by Element and Category scenario.
PROG009: Total Needs Summarizes the needs and programmed work over time Report Predictive Modeling
by Element Category and by element category and material for the current Pontis
Material scenario.
PROG010: Preservation Shows programmed preservation work (work modeled Report Structure
Work Programmed by by Pontis as being programmed given the budget Programming
District constraint), and the benefits of preservation work
programmed by district and year for each scenario.
Note that the report shows preservation work only - not
included is work involving structure replacement,
widening, raising or strengthening.
PROG011: Total Summarizes total preservation needs and programmed Report Predictive Modeling
Preservation Needs and work for each simulation year of the current Pontis
Programmed Work Over scenario.
Time
PROG012: Scenario Documents key parameters for the current Pontis Report Predictive Modeling
Specification Report scenario.
BMS Re-write Phase 2 Conceptual System Design Report 26
System Architecture
BMS Re-write Phase 2
2.2.3 New and Customized Components
The following is a summary of the new and customized components required to meet the
defined PENNDOT functionality requirements for the new Pontis-based BMS. Some of these
components provide functions within the BMS web application while others extend the
functionality of the Pontis client application itself.
Name Purpose U/I Type BMS Function
Application Security Custom web-based applet that allows PENNDOT and Screen Application Security
external users to maintain security information, including
the ability to link users or groups of users to specified
structures.
Batch Calculations Provide ability to recalculate performance measures Program Condition Summary
such as Total Deficiency Rating (TDR) and
Maintenance Deficiency Rating (MDR) when
corresponding data changes within BMS. The system
will indicate to the user whether a performance measure
has been estimated and/or cannot be calculated due to
missing dependent data.
Channel Depth/Scour Custom applet to provide all of the required scour Screen Inspection Data
Assessment assessment and waterway channel information, Management
including algorithms for Observed Scour Assessment.
Crane Scheduling Custom applet to provide all of the required crane Screen Inspection
scheduling functionality. Scheduling
Design Exceptions Custom applet to record and maintain information about Screen Inventory Data
design exceptions granted by FHWA for a structure, and Management
to alert users that a design exception exists.
Drawing Maintenance Custom applet to create and maintain the links between Screen Inventory Data
structures and associated drawings, including design Management
and shop drawings. The base Pontis application does
not provide the necessary data structures to support the
PENNDOT requirements.
EDC Download Custom web-based applet to request and access an Screen Inspection Data
inspection data file for download from BMS into an Management
EDC.
EDC Upload Custom web-based applet to initiate and review the Screen Inspection Data
results of an inspection data upload into BMS from an Management
EDC.
eForms Custom client application for structure inspectors to Screen EDC Modifications
record inspection information electronically, most likely
on a notebook or tablet-based computer. This
component represents a complete replacement of the
current PENNDOT eForms application.
Email Notification Custom applet to provide a common interface for all Program Common System
email notifications that must be issued by BMS to both Function
PENNDOT and external users.
GIS Interface Custom web-based screen for PENNDOT and external Screen GIS Integration
users to view GIS-based maps associated with one or
more structures (e.g., location of structure, location of
related roadway work).
BMS Re-write Phase 2 Conceptual System Design Report 27
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Home and Navigation Custom applet to control access and security to the Screen Application Security
Pontis application and to the BMS website for external
users.
Inspection - Problem Custom web-based screen for external users to view or Screen Web Interface -
Description maintain information concerning an event that requires Inspection
a structure to have an emergency inspection (e.g.,
flood, bridge strike, etc.)
Inspection - Custom web-based screen for external users to view or Screen Web Interface -
Bridge/Culvert Routine maintain routine (NBI) inspection information for their Inspection
Inspection structures.
Inspection - General Custom web-based screen for external users to view or Screen Web Interface -
maintain general inspection information (e.g., frequency, Inspection
required equipment) for their structures.
Inspection - Inspection Custom web-based screen for external users to view or Screen Web Interface -
Schedule maintain inspection scheduling information for their Inspection
structures.
Inspection - Inspector Custom web-based screen for PENNDOT and external Screen Inspector Alert
Alert users to be notified about information pertaining to an
emergency inspection.
Inspection Agency Card Customize the Pontis Inspection Agency Card screen to Screen Inventory Data
Updates include additional PENNDOT fields on the bridge, Management
roadway, structure unit, inspection and project forms.
Inventory - Abutments Custom web-based screen for external users to view or Screen Web Interface -
maintain inventory-related abutment information for their Inventory
structures.
Inventory - Drawing/Doc Custom web-based screen for PENNDOT and external Screen EDMS Integration
Links users to maintain electronic document links for a
structure. All structure-related electronic documents will
be stored within EDMS.
Inventory Features Custom web-based screen for external users to view or Screen Web Interface -
Intersected maintain features intersected inventory information for Inventory
their structures.
Inventory - Load Custom web-based screen for external users to view or Screen Web Interface -
maintain load capacity information for their structures. Inventory
Inventory - Location Custom web-based screen for external users to view or Screen Web Interface -
maintain location-related inventory information for their Inventory
structures.
Inventory - Narrative Custom web-based screen for external users to view or Screen Web Interface -
maintain free-form descriptive notes for their structures. Inventory
Inventory - Search Custom web-based screen for external users to search Screen Common Business
for one or more of their structures based upon enterable Function
criteria.
Inventory - Size Custom web-based screen for external users to view or Screen Web Interface -
maintain structure dimension inventory information for Inventory
their structures.
Link EDMS Document to Custom web-based selection screen for PENNDOT and Screen EDMS Integration
Structures external users to view and select one or more electronic
documents to link to a structure.
BMS Re-write Phase 2 Conceptual System Design Report 28
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Load Rating Custom applet to maintain load rating information for Screen Inventory Data
bridges. The base Pontis application does not provide Maintenance
the necessary data structures to support the PENNDOT
requirements.
Overdue Posting Custom applet to notify the appropriate district bridge Screen Inspection Data
engineer when a structure has not been posted as Maintenance
required based upon the most recent inspection.
PENNDOT Bridge Custom client application for component-level predictive Screen Predictive Modeling
Modeling System modeling. This component represents a complete
replacement of the current PENNDOT Bridge Modeling
System, implementing improvements suggested during
Task 2 of the BMS Re-write Phase 2 project.
Planning - Bridge Costs Custom web-based screen for external users to review Screen Web Interface -
for Non-Bridge Project project cost information for non-structure-related work Structure Planning
performed on projects associated with their structures.
This screen supports the ability for users to determine
an appropriate adder factor for non-bridge project costs.
Planning - Project Custom web-based screen for external users to view or Screen Web Interface -
Summary Across maintain planning information for one or more of their Structure Planning
Structures structures.
Planning - Proposed Custom web-based screen for external users to view or Screen Web Interface -
Project maintain proposed project information for their Structure Planning
structures.
Planning - Proposed Custom web-based screen for external users to view or Screen Web Interface -
Work maintain proposed maintenance or improvement work Structure Planning
tasks for their structures.
Planning - Search for Like Custom web-based screen for external users to search Screen Web Interface -
Projects for one or more projects based upon enterable criteria. Structure Planning
This screen supports the ability for users to find similar
projects for cost estimating purposes.
Programming - Project Custom web-based screen for external users to view or Screen Web Interface -
Information maintain project information for their structures. Structure Planning
Recurring Work Orders Custom applet that allows a user to define recurring Screen Maintenance
work orders for a structure or group of structures, Management
meaning that BMS will automatically create and identify
structure work for programming each year.
Structure Condition Custom web-based screen for external users to review Screen Web Interface -
Summary - Detail condition information for their structures. Condition Summary
Task List Custom web-based screen for external users to view Screen Common Business
pending inspection or structure maintenance work items Function
for their structures.
Work Order Requisition Custom web-based screen for PENNDOT or external Screen Maintenance
users to group maintenance activities into proposed Interface
work orders for programming through the MORIS or
Plant Maintenance system.
BMS Re-write Phase 2 Conceptual System Design Report 29
System Architecture
BMS Re-write Phase 2
2.2.4 New and Customized Reports
The following is a summary of the new and customized reports required to meet the defined
PENNDOT reporting requirements for the new Pontis-based BMS. Most of these reports will be
provided using Crystal Reports and the Crystal Enterprise server.
Name Purpose U/I Type BMS Function
APRAS Loading Provides an overview of oversize/overweight loads that Report Structure Planning
Summary have passed over a structure or group of structures.
Bridge Bill Summary Summary of structure projects associated with a Report Structure Planning
particular bridge bill.
Bridge Clearance Summary of bridge vertical clearance information for a Report Inventory Data
Summary specified structure or group of structures, based upon a Management
user-specified minimum clearance.
Bridge Clearances LTE Summary of bridge vertical clearance information for a Report Inventory Data
Standard structure or group of structures in comparison to a user- Management
specified minimum clearance.
Bridge Inspection Summary of the structures due to be inspected within a Report Inspection
Schedule Due by Month user-specified time period. Scheduling
Bridge Inspection Provides a categorized numerical summary of the Report Inspection Data
Summary number of inspections completed by an organization Management
within a user-specified time period.
Bridge Posting Summary of structures that have a load capacity Report Condition Summary
Deficiencies appraisal less than or equal to 4 that have not been
posted.
Bridge Safety Features Summary of structures that have safety feature Report Inspection Data
Deficiencies deficiencies based upon the most recent inspection. Management
Bridges by Year Built Summary of structures grouped by year built. Report Inventory Data
Management
Bridges Eligible for Summary of structures that are eligible for replacement Report Structure Planning
Rehab/Replacement or rehabilitation based upon their corresponding SD/FO
value.
Bridges Not Inspected A list of structures that were not inspected within their Report Inspection
Within Time Interval corresponding mandated inspection interval. Scheduling
Bridges On or Over a A list of structures that carry or pass over a user- Report Inventory Data
County or State Route specified route. Management
Business Plan A summary report of structure performance statistics Report Structure Planning
that is created in support of the annual PENNDOT
business plan.
CCV Daily Map Number Summary of structures whose authorization for use by Report Inventory Data
Monitoring CCV vehicles has changed based upon the most recent Management
inspection.
Closed or Posted Bridges A list of closed and posted structures based upon user- Report Inventory Data
specified location criteria. Management
Closed Structures by Summary of closed structures, broken into categories Report Inventory Data
Structure Length based upon structure length. Management
Containerized Cargo Summary of structures that provide adequate load Report Inventory Data
Vehicle (CCV) Summary capacity for use by permitted CCV vehicles. Management
BMS Re-write Phase 2 Conceptual System Design Report 30
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
FHWA Bridge Scour A list of structures with corresponding FHWA scour Report Inspection Data
Evaluation Program calculations based upon the most recent underwater Management
inspection for a user-specified group of structures.
GASB34 Analysis Provides structure-related statistics in support of the Report Structure Planning
GASB34 reporting requirements.
Highway Bridges and Summary of maintenance activity for highway and Report Maintenance
Railroad Bridges railroad bridges meeting user-specified location criteria. Management
Maintenance
Inspection Forms for Printed inspection forms for bridge inspections that are Report Inspection Data
Manual Inspection not recorded using an EDC. Management
Late Inspection Summary Summary of structures that were not inspected within Report Inspection
the mandated time interval, grouped by organization Scheduling
and period of lateness.
Maintenance Activity Summary of maintenance activity actual costs in Report Maintenance
Actual to Budgeted Cost comparison to the corresponding budgeted Management
Summary maintenance cost.
Maintenance Needs by Summary of structures requiring maintenance, ranked Report Maintenance
Deficiency Points by the corresponding structure MDR. Management
Maintenance Needs by Summary of structures requiring maintenance Report Maintenance
Structure Length categorized by structure length. Management
Major Improvement Summary of structures requiring major improvements, Report Structure Planning
Deficiency Results ranked by the change in TDR resulting from the
completion of the improvement activity.
Monthly Scour Summary of scour analysis results corresponding to Report Inspection Data
underwater inspections completed within the user- Management
specified time period.
Oversize and Overweight Statistical summary of oversize/overweight vehicle Report Structure Planning
Vehicle Travel Over Time loads for a user-specified group of structures.
Posted Highway Bridges Summary of posted structures, categorized by structure Report Inventory Data
by Length length. Management
Posting Changes by Time Summary of structures that have corresponding posting Report Condition Summary
Period status changes within the user-specified time period.
Quarterly FHWA Scour Summary of FHWA scour analysis results for a user- Report Inspection Data
specified time period. Management
Reconstructed Bridges by Summary of structures that have been Report Structure Planning
Structure Type reconstructed/replaced within the user-specified time
period.
Recurring Activities Past A list of recurring maintenance activities that have not Report Maintenance
Due be completed within a user-specified time period. Management
Rehab and Replacement Summary of rehabilitation and replacement costs that Report Structure Planning
Needs Minimum Design result in the corresponding bridges being restored to a
Scenario minimum design level.
SD/FO Bridges Summary of Structurally Deficient/Functionally Obsolete Report Condition Summary
structures.
Square Foot Bridge Summary of square foot bridge construction costs for Report Structure Planning
Construction Cost the user-specified time period, based upon actual
Summary construction costs linked to structures within BMS.
BMS Re-write Phase 2 Conceptual System Design Report 31
System Architecture
BMS Re-write Phase 2
Name Purpose U/I Type BMS Function
Structure Count by Statistical summary of structures categorized by Report Inventory Data
Structural Material structural material. Management
Target vs. Actual Summary of actual maintenance activity costs in Report Maintenance
Spending by Work comparison to the original estimates for the activities. Management
Category
USGS Scour Evaluation A list of structures and corresponding USGS scour Report Inspection Data
analysis results based upon the most recent underwater Management
inspection for a user-specified group of structures.
BMS Re-write Phase 2 Conceptual System Design Report 32
System Architecture
BMS Re-write Phase 2
2.3 External System Interfaces
2.3.1 EDMS
The new Pontis-based BMS will provide an automated on-demand interface with the PENNDOT
Electronic Document Management System (EDMS), which is supported by the Bureau of
Information Systems. The EDMS interface is required for internal PENNDOT users, using the
Pontis client application, and external users accessing BMS through the web interface.
Therefore, the primary interface between BMS and EDMS has been designed as a web
application, with the Pontis application interacting with the BMS website as illustrated in the
following diagram.
Pontis BMS Web BMS Web EDMS
Application Application Bridge Application
Detail
Screen
Pontis BMS URL
Document for
Mgmt Document
“Applet” List
EDMS API
to Retrieve
Doc List
Doc List
Add New
EDMS API
to Retrieve
Taxonomy
BMS URL to
Pontis Define
Bridge BMS URL to
Document EDMS
View Database
Document
Document
Links
EDMS API
to Retrieve
Select Document
and Define
BMS Document
EDMS
EDMS API
Document to Store
Document
BMS URL to
Add
Document
BMS/EDMS Interface Conceptual Design
The Pontis client application provides “document links” on various forms, which allow the user to
store URL links to associated documents. For the PENNDOT BMS, these URL links will provide
access to the BMS web application, which will in turn access and display specific structure-
related documents stored within EDMS. However, Pontis does not provide a form to display all
the documents for a specified bridge. A customized web-based applet will be created to display
the complete document index for a specified bridge.
These same functions will be available to authorized external users of the BMS web application.
BMS Re-write Phase 2 Conceptual System Design Report 33
System Architecture
BMS Re-write Phase 2
The key points to govern the detailed design are the specific API requirements for the
BMS/EDMS interface:
• An Application Programming Interface (API) must exist to provide the BMS web
application with a list of documents for a specified bridge id. This API must provide the
data as a stream of data (either in a Java object format or XML format), not as a
formatted HTML web page. The display of the document list will be done via the BMS
web application.
• An API interface must exist to provide the BMS web application with a document from
the EDMS repository. This document must be returned as a data stream or other Java
object. The display of the document will be done via the BMS web application, using
viewer support already within the client browser (e.g., images, Word documents) or via
applications installed on the user’s workstations (e.g., CAD software).
• An API interface must exist to allow the BMS web application to retrieve a document
from a user via a browser interface (using the standard multi-part form interface used for
uploading files) and to pass this document as a data stream or other Java object to
EDMS for storage.
• An API must exist to retrieve the various taxonomy information required when a new
document is being created, to allow the BMS application to present to the user the
required drop-down lists to identify the characteristics of the new document. As noted in
the previous item, this taxonomy information would then be passed along with the
document itself for storage within EDMS.
These API capabilities are necessary due to the requirements to support non-PENNDOT
external users (e.g., consultant engineers) via the BMS web application. It is infeasible to
require these external users to install PENNDOT’s standard EDMS client to store documents
into EDMS and to download the large EDMS document viewer, and/or to travel to a district
office to deposit routine documents into EDMS (e.g., inspection photographs, schematics, etc.)
2.3.2 GIS
The new Pontis-based BMS will provide an automated on-demand interface with the existing
Geographic Information System (GIS) that is delivered via the Bureau of Planning and Research
(BPR) intranet site. The Pontis application does not provide support for integration with GIS,
and the GIS interface is required for external users of BMS; therefore, the integration will be
provided through the use of a customized BMS web application, as illustrated in the following
diagram.
BMS Re-write Phase 2 Conceptual System Design Report 34
System Architecture
BMS Re-write Phase 2
BMS Web GIS Web
Application Application
BMS GIS
Search Search
Screen Screen
BMS URL GIS URL
for GIS for Map
Interface Display
BMS GIS
GIS
GIS DB
Pontis Frame
w/ BMS
Database GIS Map
Key data
only Display
BMS URL GIS URL
for Bridge for Bridge
Detail Detail
BMS
Bridge
Detail
BMS/GIS Interface Conceptual Design
For both internal PENNDOT and external BMS users, the BMS web application will incorporate
a GIS component nested on a BMS web page. The details of how this component will be
invoked (e.g., a frame within a frameset, or an ActiveX component or Java applet) must be
designed in conjunction with the BPR GIS programmers. The parameters for the initial GIS
display within this component will be passed from within the BMS web application. The
component will continue to interact with the GIS application to respond to the user’s request to
zoom, pan, etc. The GIS database will contain only the structure identifier and location data
necessary to integrate the BMS data with the location referencing keys in the GIS database. If
the user selects a structure from the GIS display to see the detailed information for the
structure, the GIS application will redirect the request back to the BMS web application so that
the detail information will be the current operational data from the Pontis BMS database.
For non-BMS users, access to GIS will continue to be provided using existing GIS intranet
screens. However, the display of detailed structure information will be provided by the BMS
web application access through GIS. If the BPR staff prefers that the GIS application continue
to format and display the structure data on GIS-specific screens, the BMS web application will
make the data available to the GIS application via an XML-based web service.
The key design points to govern development of detailed design specifications are
• The integration should minimize data redundancy; all detailed structure data should be
retrieved from the Pontis BMS database by BMS programmed logic. If the GIS
BMS Re-write Phase 2 Conceptual System Design Report 35
System Architecture
BMS Re-write Phase 2
application requires access to the raw data, it should be provided to GIS by BMS via a
web service interface.
• The only structure data to be stored in the GIS database should be the structure
identifier and critical location data that allows the structure to be located and integrated
within the location referencing keys maintained by GIS.
2.3.3 Video Log
The Video Log web application supported by the Bureau of Planning and Research (BPR)
provides a series of still-shot photographs presented in “movie” format as though the user is
driving down a highway. BPR already provides an interface to the Video Log application that
allows another system to invoke the Video Log for a specific roadway location. The BMS web
application will include direct links from structure-specific web pages to invoke the Video Log
application for the highway references associated the specified bridge (e.g., roadway carried by
the structure, roadway passing under a structure). The Video Log application will open in a new
browser window, allowing the user to see both the BMS web page and the Video Log page
showing the structure as requested.
2.3.4 eForms
Although included within the scope of the new Pontis-based BMS, the eForms standalone
inspection data management application requires an interface to facilitate the download of
structure inventory and prior inspection data and the upload of new inspection data. The
following diagram illustrates the upload and download processes for eForms:
Extract Process
Search
Search
Results Pontis XML
Screen
Download Database File
EDC
Submit Process
Synch
Pontis Edit XML
Screen
Database Program File
Upload
Confirmation
& Summary
Screen
EDC Download/Upload Process
The eForms application is installed and executed on a standalone EDC computer that can also
be connected to a network to gain access to the internet. Authorized PENNDOT and external
users request EDC inspection data via the BMS web application. When requesting a download
file, the user must specify which structures are to be included. The new BMS will create an
XML extract file which can then be downloaded to the EDC. Once downloaded, the EDC can
be disconnected from the network and used as a standalone field inspection computer. The
BMS Re-write Phase 2 Conceptual System Design Report 36
System Architecture
BMS Re-write Phase 2
eForms application temporarily stores downloaded data and updated inspection data in a local
database while being used in the field. Once the inspection is complete, the updated inspection
data is extracted from the local eForms database and into the new BMS for review and, once
approved, for inclusion in the production inspection data. As part of the upload process, the
updated inspection data is edited to ensure that it meets data integrity and other accuracy rules.
Inspections that fail the edit process can either be rejected completely, with no associated data
saved within the BMS database, or can be saved within the BMS database with a status that
indicates the data is incorrect.
2.3.5 Data Interfaces
The following table describes the data interfaces required for the new Pontis-based BMS. As
described in section 2.1.3 above, these interfaces will be supported by the DB2 version of the
Pontis database, which will be updated nightly to ensure it is kept in sync with the Oracle
production database.
System Description Frequency
Roadway Management This is a bi-directional data exchange. Data from RMS is provided to Nightly batch
System (RMS) BMS on a nightly basis and includes:
• State roadway location, on or under indicator, traffic route
• Current average annual daily traffic (AADT), year of base AADT
• Current average annual daily truck traffic (ADTT), year of base
ADTT, percentage of base ADTT that is truck traffic
• Government level of control, Federal aid, functional class code,
urban/rural designation, State network
Bridge Straight Line Diagrams (SLDs) are updated in RMS through a
nightly batch process.
Examples of new requirements for the BMS/RMS interface include the
transfer of shoulder width info into BMS from RMS, the automatic update
of all information in BMS that is affected by a realignment in RMS and the
flagging of discrepancies in lane width between BMS and RMS data.
Because RMS uses IMS as its database management system, it is not
feasible for either Pontis or the BMS web application to access the RMS
data directly. Therefore, the nightly batch process must continue to
provide the required RMS data to BMS. Extracts from RMS must be
downloaded to the BMS application server for loading into the Pontis
BMS Oracle database.
The DB2 version of the Pontis database will provide a flexible means for
RMS to access BMS data. Initially, BMS data will continue to be
extracted from DB2 in a nightly batch job, but if the RMS support team
wants to display BMS data directly within RMS, the data will be made
available from the DB2 database.
Multi-Modal Project Today, limited MPMS data is currently available within BMS for individual Nightly batch
Management System bridge improvement projects. The MPMS data is passed to BMS through
(MPMS) a nightly batch run and includes: On-demand data
• Program and budget status application
• Project milestone dates (e.g., date of construction contract letting, integration
date of construction contract award, date of notice to proceed, date
of project completion, date the improved structure was opened to
traffic, date of construction acceptance certificate)
• Project costs (design, Right of Way, construction, and total)
• Contract management system construction project number, State
project number, Federal aid project number
BMS Re-write Phase 2 Conceptual System Design Report 37
System Architecture
BMS Re-write Phase 2
System Description Frequency
• Twelve Year Program indicator; Bridge Bill indicator; District's priority
(for Capital Improvement project)
The preferred approach is for the BMS web application to access the
MPMS database directly to display current operational data from MPMS.
BMS would not perform any changes to the MPMS data; it would be for
display purposes only. Alternatively, the BMS web application can
continue to display point-in-time data provided nightly from MPMS.
Because MPMS uses mainframe DB2 as its database management
system, it will likely not be feasible for Pontis or the BMS web application
to access the MPMS data directly. Therefore, the nightly batch process
must continue to provide the required MPMS data to BMS. Extracts from
MPMS must be downloaded to the BMS application server for loading
into the Pontis BMS Oracle database.
The DB2 version of the Pontis database will provide a flexible means for
MPMS to access BMS data. BMS data can continue to be extracted from
DB2 in a nightly batch job, but MPMS could be modified to retrieve
required BMS data directly from the DB2 database.
Data from the BMS DB2 database will be accessible to MPMS (both the
PowerBuilder and web applications) for display of pertinent structure-
related data.
Automated Permit Currently, nightly APRAS batch jobs extract data from the relational copy On-demand data
Routing Analysis of the BMS IMS database and load the data into APRAS tables. The integration
System (APRAS) new BMS DB2 database will provide all the required data for APRAS,
and APRAS should be changed to access the BMS DB2 data directly.
This will require coordination of the changes to APRAS with the BMS
rewrite project implementation schedule.
Engineering and ECMS currently has a one-way interface that obtains select BMS On-demand data
Construction information for BMS structures and retrieves structure information (e.g., integration
Management System description and waterway indicators) from the RDIDB copy of the BMS
(ECMS) database. This information is then copied to the ECMS database and
related to a particular ECMS project number. This access to the RDIDB
must be changed by ECMS to a real-time access to the new BMS DB2
database.
Because ECMS uses mainframe DB2 as its database management
system, it will likely not be feasible for Pontis or the BMS web application
to access the ECMS data directly. Therefore, the nightly batch process
must continue to provide the required ECMS data to BMS. Extracts from
ECMS must be downloaded to the BMS application server for loading
into the Pontis BMS Oracle database.
Municipal Services The interface between MUSIC and BMS affects the disbursement of local Annual batch
Information Center fuels tax money. An annual extract from BMS is performed to calculate
(MUSIC) funds that must be withheld from municipalities in order to pay for bridge
inspections that were conducted on their behalf by PENNDOT. This
extract file will be created from the DB2 version of the new BMS
database.
BMS Re-write Phase 2 Conceptual System Design Report 38
System Architecture
BMS Re-write Phase 2
System Description Frequency
Future Plant MORIS does not actively interface with BMS today, but PENNDOT plans To Be
Maintenance System to replace the current MORIS with maintenance management Determined
(MORIS replacement) functionality within mySAP using the SAP Plant Maintenance module.
BMS may be more integrated with Plant Maintenance for the following:
• Electronically generate work orders using SAP plant maintenance
functionality. Further work is required to define the specific data to
be passed from BMS to Plant Maintenance. The assumption is that
some level of planning for work orders will still need to be done in
BMS. Work orders should be preloaded with information provided by
BMS to minimize data entry for Plant Maintenance users
• Use the scheduling feature of Plant Maintenance to automatically
initiate recurring (repeating) preventive maintenance work orders
(such as cleaning) on a defined schedule
• Provide the ability to attach (or provide a link to) CADD drawings,
digital pictures, and product information to a work order.
• Establish different workflows for structural and non-structural work
orders (non-structural work orders do not require approval by the
Bridge Engineer).
• Automatically update BMS when maintenance activities are recorded
as complete in Plant Maintenance, including material, labor, and
equipment costs to complete the maintenance activities.
• Share material, labor, and equipment cost information to develop
cost estimates for maintenance needs.
The details of this integration cannot be finalized until the Plant
Maintenance project is started. If necessary, an initial generic interface
to the existing MORIS system can be designed and implemented if the
Plant Maintenance system is not available in time for the production
implementation of the new BMS.
In order for all of the above data interfaces to maintain the most concurrent data between all
systems, the following is the proposed sequence of interface execution. As noted in section
2.1.3, the source of the data for the interfaces from BMS to the other mainframe-based
PENNDOT systems will be the DB2 copy of the production BMS Oracle database.
Sequence Interface Description
1 RMS data extract for BMS
2 MPMS data extract for BMS
3 ECMS data extract for BMS
4 MORIS / Plant Maintenance extract for BMS
5 RMS, MPMS, ECMS and MORIS / PM extract files loaded into the
production BMS Oracle database
6 Production BMS Oracle database unload and load of the BMS DB2 copy
7 BMS data extract for RMS
8 BMS data extract for MPMS (if required)
9 BMS data extract for ECMS (if required)
10 BMS Engineering data extract from BMS DB2 copy for loading into the
production BMS Oracle database
BMS Re-write Phase 2 Conceptual System Design Report 39
System Architecture
BMS Re-write Phase 2
2.4 Data Model
This section presents two data models that collectively represent the database necessary to
support the BMS Re-write Phase 2 functional requirements. The first data model corresponds
to the Pontis version 4.3 Oracle database. The second data model is derived from the BMS
conceptual data model included within the Bridge Management System Requirements Definition
Report Volume 1 v2, dated August 22, 2003, and represents the logical data entities and
relationships necessary to meet the requirements as defined for the selected Pontis BMS
implementation alternative. The Pontis Level E alternative requires the implementation of the
Pontis database, with additional customization to address requirements that are not met by the
base Pontis application.
During the detailed design phase for the development of the new BMS the Pontis and BMS data
models will be integrated so that the final implemented database provides a repository for all
required data and supports the relationships required by and defined within the BMS data
model. To meet the defined PENNDOT user requirements, over 200 additional data fields must
be added to the Pontis database. As recommended by Cambridge Systematics, the core Pontis
tables will not be changed unless absolutely necessary to minimize the impact of the PENNDOT
customizations on future Pontis upgrades. In many cases, the new fields will be included in the
five tables defined within Pontis for the addition of agency-specific data - USERBRDG,
USERINSP, USERRWAY, USERSTRUNIT and USERPROJ. However, in those cases where
the primary key structures for these tables do not support the required relationships, additional
PENNDOT-specific tables will be created. The additional fields required to meet all applicable
PENNDOT BMS requirements are listed in section 2.4.3 below.
The data models included within this section represent fundamental database structures
independent of any technical environment. Entity-Relationship Diagrams (ERD) are used to
visually represent the models, which include all of the data used by the BMS business
processes and the logical relationships between the data components. An entity is a person,
place, thing or concept that a business needs to manage and for which it may choose to store
facts or properties. It is visually represented in an ERD diagram as a rectangle enclosing the
entity name. A relationship is an association between two entities. Relationships are visually
represented in an ERD as a line drawn from one entity to another.
In addition to displaying the entities and relationships between them, an ERD also identifies the
"cardinality" of the relationships. Cardinality expresses the number of instances of one entity
that may be linked with one instance of another entity (by virtue of the associated relationship).
Cardinality is normally expressed with both minimum and maximum limits, with the minimum
expressed as either a zero (0) or one (1) and the maximum expressed as either one (1) or many
(M). A relationship with a minimum of 0 occurrences is defined as an "optional" relationship,
meaning it does not have to exist; a relationship with a minimum of 1 occurrence is defined as a
"required" relationship, meaning it has to exist in order for instances of the two entities to exist.
In addition to cardinality, the graphic representation of a relationship can also identify whether
the relationship is dependent. A dependent relationship means that one entity is dependent
upon another entity (expressed by the relationship) for its unique identification. In other words,
in order for an instance of the dependent entity to exist, an instance of the "parent" entity must
also exist. Cardinality and dependency are visually represented at both ends of a relationship
line using the following graphical constructs:
BMS Re-write Phase 2 Conceptual System Design Report 40
System Architecture
BMS Re-write Phase 2
Cardinality must be expressed for both "directions" of a relationship. The cardinality graphic
closest to the entity rectangle (on the "outside" of the relationship) represents the maximum,
and the graphic farthest from the entity rectangle (the "inside" of the relationship) represents the
minimum. The cardinality that applies to a particular relationship direction is always at the far
end of the relationship line, opposite the "from" entity.
Using the above diagram, the cardinality for the relationship from Maintenance to Work Order
appears on the right side of the relationship line - 0 to 1, meaning a maintenance activity can
exist in the Maintenance entity without a corresponding work order (although a business rule
may be implemented to require a maintenance activity to be linked to a work order prior to being
executed). The cardinality for the relationship from Work Order to Maintenance appears on the
left side of the relationship line - 1 to Many, meaning that at least one maintenance activity and
possibly many maintenance activities must exist before a work order can be created.
The following pages include ERDs for portions of the Pontis version 4.3 and BMS data models.
Due to their size, neither of the complete data models could be adequately displayed in a single
diagram so they were broken into logical subsets for inclusion in this report. Each section below
includes a diagram for one of the subsets along with the summary description paragraphs for
each of the entities included in that subset. The entity paragraphs below each diagram are
listed in alphabetical order.
2.4.1 Pontis Data Model
Pontis is designed around a relational database of 106 tables/entities. These entities store data
about an agency’s physical bridge inventory, as well as its projects, data related to performing
program simulations, various data definitions, and system parameters. The data model has
been broken into the following six logical subsets:
• Physical Inventory
• Program Simulation
• Project Planning
• System Definition
BMS Re-write Phase 2 Conceptual System Design Report 41
System Architecture
BMS Re-write Phase 2
• Application System
The descriptive information within this section was obtained from the Pontis Release 4.3
Technical Manual, prepared for AASHTO by Cambridge Systematics and dated September 5,
2003. The subset ERDs were derived from the Pontis v4.3 physical data model for Oracle.
Note that entities displayed in gray in the ERDs are entities defined within other subsets that are
displayed for completeness.
2.4.1.1 Physical Inventory
The Pontis database includes entities related to an agency’s physical bridge inventory. These
are the tables most frequently accessed by inspectors when using the Inspection module, and
contain all the information originally specified for the NBI.
USERINSP ROADWAY USERRWAY
INSP_WCAND
INSPEVNT
PRJ_WITEMS
STRUCTURE_UNIT BRIDGE PONT_WORK
USERSTRUNIT USERBRDG
ELEMINSP ENVTDEFS CICOCNTL CICOXCPT
ELEMDEFS USERS MULTIMEDIA
2.4.1.1.1 BRIDGE
Contains NBI and other information related to structures, including physical, administrative and
operational characteristics. This entity contains one record for each structure, and serves as
the primary source for NBI data reporting.
2.4.1.1.2 CICOCNTL
Contains a list of checked-out structures, and is used to support application operations requiring
temporary storage of lists of structures, such as running reports for a group of structures
selected on the desktop. The entity contains one record for each structure and type of event.
2.4.1.1.3 CICOXCPT
Contains a list of structures processed as exceptions during the check in process.
BMS Re-write Phase 2 Conceptual System Design Report 42
System Architecture
BMS Re-write Phase 2
2.4.1.1.4 ELEMINSP
Contains the results of Pontis element-level condition inspections, including the quantity of
condition units in the different condition states. This entity contains one record for each
condition unit of each element inspection.
2.4.1.1.5 INSP_WCAND
Contains work candidates for each structure, including scope, cost, and description information.
2.4.1.1.6 INSPEVNT
Contains one record for each structure inspection, including the type of inspection, inspector
identification, and structure-level inspection results. Element-level results are stored in the
ELEMINSP entity.
2.4.1.1.7 MULTIMEDIA
Contains a list of multimedia documents associated with bridges and bridge inspection. This
entity contains one record for each document link. The documents are not stored in the entity
itself, but at the location identified in each entity record.
2.4.1.1.8 ROADWAY
Contains inventory data about the roadways on and under a structure, including information
corresponding to the road dimension and service levels for the structure, such as traffic, truck
volumes, speeds, detours. This entity is a major source of data for NBI reporting.
2.4.1.1.9 STRUCTURE_UNIT
Contains data about the structure units on each structure. Structure units are used to group
elements together for performing inspections.
2.4.1.1.10 USERBRDG
Contains agency-defined bridge-level data. Users may customize this entity by adding fields to
hold additional data about structures. It contains one record for each structure defined in the
BRIDGE entity. Note that an agency may give this entity a different name - the default name is
shown here.
2.4.1.1.11 USERINSP
Contains agency-defined inspection-level data. Users may customize this entity by adding
fields to hold additional data about inspections. It contains one record for each inspection
defined in the INSPEVNT entity. Note that an agency may give this entity a different name - the
default name is shown here.
2.4.1.1.12 USERRWAY
Contains agency-defined roadway-level data. Users may customize this entity by adding fields
to hold additional data about roadways. It contains one record for each roadway defined in the
ROADWAY entity. Note that an agency may give this entity a different name - the default name
is shown here.
2.4.1.1.13 USERSTRUNIT
Contains agency-defined structure unit-level data. Users may customize this entity by adding
fields to hold additional data about structure units. It contains one record for each unit defined
BMS Re-write Phase 2 Conceptual System Design Report 43
System Architecture
BMS Re-write Phase 2
in the STRUCTURE_UNIT entity. Note that an agency may give this entity a different name -
the default name is shown here.
2.4.1.2 Program Simulation
The Pontis database includes entities to store data related to the program simulation process.
DEFAULT_SCENPARAM BRIDGE PONT_WORK PROGELEM AGENCYPOLRULE
USERS
NETMETRIC AGENCYPOLSETS
EXPCNDUC ENVTDEFS EXPCONDU FUTMETRIC SCENPARAM REHABSETS REHABRULE
LKAHDSETS LKAHDRULE
STATEDFS
MRRMODLS SCENARIO SCOPERULE
CONDUMDL EXPACTN SCOPESETS
SCENELEM FLEXSETS
IMPRSETS IMPRMTRX
STATMDLS
COSTSETS COSTMTRX
MRRACTDF ACTMODLS FLEXACTIONS
EXPACTC
POLSETS POLMATRX
FLEXRULES BUDGSETS BUDGMTRX
ELEMDEFS
DM_DET_MATRIX_A DM_ACT_PROB_EXPERTS DM_DET_PROB_NEW_MODEL DM_DET_PROB_EXPERTS DM_ELEMINSP DM_DET_PROB_1_BIN
DM_DET_MATRIX_B DM_COND_STATE_PAIRS DM_DET_PROB_OLD_MODEL DM_DET_PROB_HISTORY DM_CONTROL DM_ELEM_OBS_PAIRS
2.4.1.2.1 ACTMODLS
Contains preservation model data at the action level for each preservation model, including
information on cost and transition probabilities of each action. It contains one row for each
combination of model, element, environment, condition state and action. The contents of this
entity are generated during the preservation model updating and optimization processes.
2.4.1.2.2 AGENCYPOLRULE
Contains definitions of each defined agency preservation policy rules applied during program
simulation.
2.4.1.2.3 AGENCYPOLSETS
Contains identification data for each defined agency preservation policy set.
2.4.1.2.4 BUDGMTRX
Contains the budget by year for each defined budget set.
BMS Re-write Phase 2 Conceptual System Design Report 44
System Architecture
BMS Re-write Phase 2
2.4.1.2.5 BUDGSETS
Contains identification data for each defined budget set.
2.4.1.2.6 CONDUMDL
Contains preservation model data at the condition unit level for each preservation model,
including element failure costs. It contains one row for each combination of model, element and
environment. The contents of this entity are generated during the preservation model updating
and optimization processes.
2.4.1.2.7 COSTMTRX
Contains data for each defined cost set, including user and improvement unit costs for each
combination of dimensional values.
2.4.1.2.8 COSTSETS
Contains identification data for each defined cost set.
2.4.1.2.9 DEFAULT_SCENPARAM
Contains default scenario parameter data. Its structure is the same as that of the SCENPARAM
entity.
2.4.1.2.10 DM_ACT_PROB_EXPERTS
Stores transition probability data from the expert elicitations for each element. It contains one
record for each combination of element, environment, state and action. The contents of this
entity are generated during the deterioration model updating process.
2.4.1.2.11 DM_COND_STATE_PAIRS
Stores data on pairs of element observations compiled during the deterioration model updating
process. This entity stores data on the same observations as those in the entity
DM_ELEM_OBS_PAIRS, but in a normalized form more suitable for performing matrix
calculations. It contains one record for each pair of observations found for each combination of
bridge, structure unit, element and environment. The contents of this entity are generated
during the deterioration model updating process.
2.4.1.2.12 DM_CONTROL
Control entity used to support performing matrix calculations as part of the deterioration model
updating process. It contains one record for each combination of element, environment, and
element observation interval. The contents of this entity are generated during the deterioration
model updating process.
2.4.1.2.13 DM_DET_MATRIX_A
Stores data for use in performing matrix calculations as part of the deterioration model updating
process. It contains a matrix of values for each combination of element, environment, and
element observation interval. Data from this entity is combined with data from
DM_DET_MATRIX_B during the deterioration model updating process.
2.4.1.2.14 DM_DET_MATRIX_B
Stores data for use in performing matrix calculations as part of the deterioration model updating
process. It contains a matrix of values for each combination of element, environment, and
BMS Re-write Phase 2 Conceptual System Design Report 45
System Architecture
BMS Re-write Phase 2
element observation interval. Data from this entity is combined with data from
DM_DET_MATRIX_A during the deterioration model updating process.
2.4.1.2.15 DM_DET_PROB_1_BIN
Stores the results of the matrix calculations performed using data from the entities
DM_DET_MATRIX_A, DM_DET_MATRIX_B and DM_CONTROL. It contains one record for
each combination of element, environment, element observation interval and state. The
contents of this entity are generated during the deterioration model updating process.
2.4.1.2.16 DM_DET_PROB_EXPERTS
Stores transition probability data for do-nothing actions determined based on the expert
elicitations. It contains one record for each combination of element, environment and state.
The contents of this entity are generated during the deterioration model updating process.
2.4.1.2.17 DM_DET_PROB_HISTORY
Stores transition probability data for do-nothing actions determined based on historical data. It
contains one record for each combination of element, environment and state. The contents of
this entity are generated during the deterioration model updating process.
2.4.1.2.18 DM_DET_PROB_NEW_MODEL
Stores transition probability data for do-nothing actions for the model developed through the
most recent updating process. It contains one record for each combination of element,
environment and state. The contents of this entity are generated during the deterioration model
updating process.
2.4.1.2.19 DM_DET_PROB_OLD_MODEL
Stores transition probability data for do-nothing actions from the previous model developed prior
to the most recent updating process. It contains one record for each combination of element,
environment and state. The contents of this entity are generated during the deterioration model
updating process.
2.4.1.2.20 DM_ELEM_OBS_PAIRS
Stores data on pairs of element observations compiled during the deterioration model updating
process. It contains one record for each pair of observations found for each combination of
bridge, structure unit, element and environment. The contents of this entity are generated
during the deterioration model updating process.
2.4.1.2.21 DM_ELEMINSP
Stores the Pontis element-level condition inspections, including the quantity of condition units in
the different condition states. This entity contains one record for each condition unit of each
element inspection. The contents of this entity are generated during the deterioration model
updating process.
2.4.1.2.22 EXPACTC
Stores action cost data collected through the expert deterioration elicitation procedure. It
contains one record for each combination of expert, element, environment, state and action.
BMS Re-write Phase 2 Conceptual System Design Report 46
System Architecture
BMS Re-write Phase 2
2.4.1.2.23 EXPACTN
Stores transition probability data collected through the expert deterioration elicitation procedure.
It contains one record for each combination of expert, element, environment, state and action.
2.4.1.2.24 EXPCNDUC
Stores data related to the expert cost elicitation procedure, including the weight of each expert’s
judgment and failure cost for each condition unit. It contains one record for each combination of
expert, element, and environment.
2.4.1.2.25 EXPCONDU
Stores data related to the expert deterioration elicitation procedure, including the weight of each
expert’s judgment for each condition unit. It contains one record for each combination of expert,
element, and environment.
2.4.1.2.26 FLEXACTIONS
Specifies the definitions of flexible actions, including the impact of taking the action and the
element condition states to which the action applies. It contains one record for each flexible
action.
2.4.1.2.27 FLEXRULES
Specifies how flexible actions map to specific elements and action types. It contains one record
for each combination of flexible action, element and action type.
2.4.1.2.28 FLEXSETS
Contains identification data for each defined flexible action set. By default, the application
supports the definition of one set only, though users may create additional sets outside the
application.
2.4.1.2.29 FUTMETRIC
Contains bridge-level results for performance measures calculated during program simulation.
It contains one record for each combination of scenario, program year, and bridge.
2.4.1.2.30 IMPRMTRX
Contains data for each defined improvement model set.
2.4.1.2.31 IMPRSETS
Contains identification data for each defined improvement model set.
2.4.1.2.32 LKAHDRULE
Contains definitions of each defined look-ahead rule applied during program simulation.
2.4.1.2.33 LKAHDSETS
Contains identification data for each defined look-ahead rule set.
2.4.1.2.34 MRRMODLS
Contains information on each preservation model. By default, the application supports the
definition of one model only, though users may create additional models outside the application.
BMS Re-write Phase 2 Conceptual System Design Report 47
System Architecture
BMS Re-write Phase 2
2.4.1.2.35 NETMETRIC
Contains aggregated results for performance measures calculated during program simulation. It
contains one record for each combination of scenario, program year, and dimensional values.
2.4.1.2.36 POLMATRX
Contains data for each defined improvement policy set, including legal and design standards for
lane widths, clearances, and operating rating for each combination of dimensional values.
2.4.1.2.37 POLSETS
Contains identification data for each defined improvement policy set.
2.4.1.2.38 PONT_WORK
Contains details on work candidates recommended by or simulated by Pontis through a Pontis
program simulation. It contains one record for each candidate.
2.4.1.2.39 PROGELEM
Contains projected element conditions by bridge calculated during program simulation. It
contains one record for each combination of scenario, program year, bridge and element.
2.4.1.2.40 REHABRULE
Contains definitions of each defined rehabilitation rule applied during program simulation.
2.4.1.2.41 REHABSETS
Contains identification data for each defined rehabilitation rule set.
2.4.1.2.42 SCENARIO
Contains data on each program simulation scenario defined in Pontis, including notes on the
scenario and the policy, cost, improvement model, budget and rule sets used for the scenario.
2.4.1.2.43 SCENELEM
Specifies the elements to be included in each program simulation scenario. It contains one
record for each combination of scenario and element.
2.4.1.2.44 SCENPARAM
Contains scenario parameter values for each Pontis program simulation scenario. It contains
one record for each combination of scenario and element.
2.4.1.2.45 SCOPERULE
Contains definitions of each defined scoping rule applied during program simulation.
2.4.1.2.46 SCOPESETS
Contains identification data for each defined scoping rule set.
2.4.1.2.47 STATMDLS
Contains preservation model data at the condition state level for each preservation model,
including information on the recommended action for each condition state. It contains one row
for each combination of model, element, environment and condition state. The contents of this
entity are generated during the preservation model updating and optimization processes.
BMS Re-write Phase 2 Conceptual System Design Report 48
System Architecture
BMS Re-write Phase 2
2.4.1.3 Project Planning
The project planning entities describe programs and funding sources, projects and their work
items, agency-defined project data, and temporarily stored work items used to support the
bridge analysis functionality.
PRJ_PROGFUND
PRJ_FUNDSRC PRJ_PRJFUND PRJ_PROGRAMS
PROJECTS
PRJ_WITEMS USERPROJ
BRIDGE TMP_WITEMS
2.4.1.3.1 PRJ_FUNDSRC
Contains definitions of funding sources used in tracking costs for programs, projects, and work
items.
2.4.1.3.2 PRJ_PRJFUND
Specifies the funding sources contributing to project funding, and the budget from each source.
It contains one record for each valid combination of project and funding source.
2.4.1.3.3 PRJ_PROGFUND
Specifies the funding sources contributing to program funding and the budget from each source
and year. It contains one record for each valid combination of program, program year and
funding source.
2.4.1.3.4 PRJ_PROGRAMS
Contains details on programs that are used to organize projects. Each project defined in Pontis
must be assigned to a program.
2.4.1.3.5 PRJ_WITEMS
Contains details on each work item of each project. A work item consists of a specific action on
a specific structure or element of a structure.
2.4.1.3.6 PROJECTS
Contains data on past, current, and proposed future projects. Additional details on the work
items for each project are contained in the PRJ_WITEMS entity.
BMS Re-write Phase 2 Conceptual System Design Report 49
System Architecture
BMS Re-write Phase 2
2.4.1.3.7 TMP_WITEMS
Contains details on work candidates simulated by Pontis as part of a single bridge analysis.
2.4.1.3.8 USERPROJ
Contains agency-defined project-level data. Users may customize this entity by adding fields to
hold additional data about projects. It contains one record for each project defined in the
PROJECTS entity. Note that an agency may give this entity a different name - the default name
is shown here.
2.4.1.4 System Definition
Pontis system definition entities are used to store definitions for business function-related items,
such as bridge elements and metric-to-English conversion values.
ELEMINSP ENVTDEFS
SCENELEM
EXPCNDUC CONDUMDL
FLEXRULES
EXPCONDU
MATDEFS ELEMDEFS
STATEDFS STATMDLS
ELTYPDFS
ACTYPDFS
ACTMODLS
ELCATDFS
COSTINDX MRRACTDF EXPACTC
DATADICT METRIC_ENGLISH EXPACTN
2.4.1.4.1 ACTYPDFS
Defines the taxonomy of action types, which are used extensively throughout the system to
group bridge activities into a small number of programmatic categories. Every element and
functional improvement action belongs to exactly one action type.
2.4.1.4.2 COSTINDX
Contains the cost index by year used in inflating past costs to current dollars.
2.4.1.4.3 DATADICT
Stores the Pontis data dictionary, which specifies information on each field in the database, and
is used for functions such as importing and exporting data. It contains one record for each
column of each entity in the database.
BMS Re-write Phase 2 Conceptual System Design Report 50
System Architecture
BMS Re-write Phase 2
2.4.1.4.4 ELCATDFS
Contains element category definitions.
2.4.1.4.5 ELEMDEFS
Contains element definitions, including Commonly Recognized (CoRe) elements, smart flags,
and additional agency-defined elements.
2.4.1.4.6 ELTYPDFS
Contains element type definitions.
2.4.1.4.7 ENVTDEFS
Contains the definitions of the four environments used for inspections and preservation models.
2.4.1.4.8 MATDEFS
Contains material type definitions.
2.4.1.4.9 METRIC_ENGLISH
Contains metric/English conversion factors.
2.4.1.4.10 MRRACTDF
Contains element action definitions. It contains one record for each combination of element,
state and action.
2.4.1.4.11 STATEDFS
Contains condition state definitions, including state language. It contains one record for each
state of each element.
BMS Re-write Phase 2 Conceptual System Design Report 51
System Architecture
BMS Re-write Phase 2
2.4.1.5 Application System
Application system entities are used to store configuration data required for running the Pontis
application itself, including the data dictionary, parameter, configurable options, data on users
and their roles, formulas, and other system data.
FORMULAS FORMERRS
COPTIONS EDITCHECK_NBI_LAYOUT
DEFAULT_COPTIONS USEROLES CICOCNTL EDITCHECK_DEFINITIONS
PFUSER_PREF USERACC EDITCHECK_CONSTANTS
OBJECT_HELP USERS EDITCHECK_VALUE_SETS
BUBBLEHELP USERPREFS EXPCNDUC EDITCHECK_SESSION
KEYSTASH EXPCONDU EDITCHECK_SESSION_LOG
USERPREFSREG
PONTLOG PFERRORMSG
KIND_CODE_LABELS DBDESCRP PARAMTRS PROGFILE PDIFILESETS PFERRORLOG
2.4.1.5.1 BUBBLEHELP
Contains bubble help text. Not implemented in Pontis Release 4. Reserved for system use.
2.4.1.5.2 COPTIONS
Contains agency-configurable parameters for modifying the appearance and behavior of the
Pontis application.
2.4.1.5.3 DBDESCRP
Contains one row, which uniquely identifies this database.
2.4.1.5.4 DEFAULT_COPTIONS
Contains default configurable parameters. Its structure is the same as that of the COPTIONS
entity.
2.4.1.5.5 EDITCHECK_CONSTANTS
Contains constant names and values used in performing data validation such as the Federal
Highway Administration (FHWA) Edit/Update check.
2.4.1.5.6 EDITCHECK_DEFINITIONS
Contains formulas and exceptions used in performing data validation such as the FHWA
Edit/Update check.
BMS Re-write Phase 2 Conceptual System Design Report 52
System Architecture
BMS Re-write Phase 2
2.4.1.5.7 EDITCHECK_NBI_LAYOUT
Contains NBI items used in performing data validation such as the FHWA Edit/Update check.
2.4.1.5.8 EDITCHECK_SESSION
Contains session information used in performing data validation such as the FHWA Edit/Update
check.
2.4.1.5.9 EDITCHECK_SESSION_LOG
Contains session information used in performing data validation such as the FHWA Edit/Update
check.
2.4.1.5.10 EDITCHECK_VALUE_SETS
Contains set names and values used in performing data validation such as the FHWA
Edit/Update check.
2.4.1.5.11 FORMERRS
Contains compiler reports about syntax errors in formulas, including text of formula and error
messages.
2.4.1.5.12 FORMULAS
Contains agency customizable mathematical formulas to replace missing values.
2.4.1.5.13 KEYSTASH
System entity used to temporarily store lists of keys for selected system operations. Reserved
for system use.
2.4.1.5.14 KIND_CODE_LABELS
Contains labels for combinations of the fields ACTKIND, ACTCODE, OBJKIND, and OBJCODE
used in specifying flexible actions, program simulation rules, work candidates and work items.
2.4.1.5.15 OBJECT_HELP
Contains help identification numbers for various Pontis objects. Reserved for system use.
2.4.1.5.16 PARAMTRS
Stores valid codes and labels for coded fields in Pontis.
2.4.1.5.17 PDIFILESETS
Contains a list of files used to populate the Includes dropdown field when a PDI file is exported
from the Gateway module. Note that for Pontis Release 4, this entity is not used - instead, the
list of files shown is populated using the file PDISETS.TXT.
2.4.1.5.18 PFERRORLOG
Contains the system error log. Reserved for system use.
2.4.1.5.19 PFERRORMSG
Contains system error messages. Reserved for system use.
2.4.1.5.20 PFUSER_PREF
Contains system user preferences. Reserved for system use.
BMS Re-write Phase 2 Conceptual System Design Report 53
System Architecture
BMS Re-write Phase 2
2.4.1.5.21 PONTLOG
Contains a log of key system events. Reserved for system use.
2.4.1.5.22 PROGFILE
Contains listing of required files. Reserved for system use.
2.4.1.5.23 USERS
Contains identification information for each Pontis user.
2.4.1.5.24 USERACC
Contains bridge-level access privileges for each Pontis user.
2.4.1.5.25 USERPREFSREG
Contains a listing of user objects that can be customized for each Pontis user.
2.4.1.5.26 USERPREFS
Contains information on customized settings for each customizable control for each Pontis user.
It contains one record for each combination of object (listed in USERPREFREG), control and
user.
2.4.1.5.27 USEROLES
Contains information on application-level privileges for each user. It contains one record for
each combination of user and privilege.
2.4.2 Data Model from BMS Requirements
The BMS data model was created in conjunction with the requirements sessions conducted as
part of Task 5 for the BMS Re-write Phase 2 project. The data model consists of 80
tables/entities. As its baseline structure, the model used the current Relational Bridge Inventory
Database (RBIDB), a relational copy of the production BMS database that currently exists in
DB2 to support ad hoc queries and reporting. The structure of the RBIDB was modified as
required to support new requirements identified by requirements session participants. The data
model has been broken into the following three logical subsets:
• Structure Detail
• Inspection
• Bridge Detail
2.4.2.1 Structure Detail
This section represents all of the detailed information that is common across all of the structure
types to be supported by the new BMS. A structure entity was defined to represent any physical
structure about which information is to be stored. A structure can be a bridge, culvert, sign,
noise wall, tunnel, retaining wall or high mast light. All information within the system that is
common to all of these structures, such as the structure identifier, location description,
congressional district, etc., is defined within the Structure entity or any entities related to the
Structure.
BMS Re-write Phase 2 Conceptual System Design Report 54
System Architecture
BMS Re-write Phase 2
2.4.2.1.1 Structure
Generic information common to all structures (bridges, culverts, retaining walls, signs, etc.)
stored within the BMS database. This generic information includes the structure identifier,
location data, legislative and congressional districts, description, etc. This entity establishes the
primary identifier for each structure, and is therefore the parent entity for all other entities in the
database. Information that is specific to a particular structure type is contained within one of the
following detail entities:
• Bridge - Information specific to Bridges and Culverts.
• High Mast Light - Information specific to High Mast Lighting.
• Noise Wall - Information specific to Noise Walls.
• Retaining Wall - Information specific to Retaining Walls.
• Sign - Information specific to Sign Structures.
• Tunnel - Information specific to Tunnels.
BMS Re-write Phase 2 Conceptual System Design Report 55
System Architecture
BMS Re-write Phase 2
2.4.2.1.2 Drawing
The design and shop drawings linked to a structure. This entity is used to store specific
identifiers for the drawings, along with any information about the drawings including linkages to
digital images in EDMS. An unlimited number of drawings can be stored for a structure.
2.4.2.1.3 Electronic Document
Electronic documents or images associated with one or more structures that are stored in the
Electronic Document Management System (EDMS) or some other location. Electronic
documents and images can be linked to a number of different detail entities for one or more
structures (e.g., for inspections, general structure information, project activities, etc.)
2.4.2.1.4 Feature Intersected
Roadway, railroad or other significant feature that intersects the structure. For bridges and
culverts, features include roadways that are carried by the bridge/culvert and roadways that
pass under the bridge. For retaining walls and other standalone structure types, features can
include a roadway or other significant feature that passes closest to the structure.
2.4.2.1.5 Inspection Consultant
Consultant assigned to perform one or more structure inspections. Consultants are allowed to
view detailed information for those structures they are assigned to inspect.
2.4.2.1.6 Inspection Instruction
Information about a structure that may be useful to an inspector, such as the location of an
access door or the presence of power lines that may impede an inspection. This data may also
include the identification of Maintenance and Protection of Traffic (MPT) requirements for a
crane inspection. Multiple entries can be made for each structure, representing the compilation
of information over the life of the structure.
2.4.2.1.7 Latitude Longitude
The latitude/longitude points that identify the location of the structure. Unlimited lat/long points
can be recorded, such as the beginning and ending points for a bridge (length greater than 8 ft).
2.4.2.1.8 Maintenance
Maintenance activities proposed and/or completed for a structure. This entity allows all of the
maintenance activities to be retained for a structure, including historical (completed) activities
from prior years.
2.4.2.1.9 Maintenance Code
Code representing the organization(s) responsible for the maintenance of the structure.
2.4.2.1.10 Median
Information about the median for a particular feature, including the type and dimensions.
Entries in this entity only apply to roadway features.
2.4.2.1.11 MPT Requirement
Special Maintenance and Protection of Traffic (MPT) requirements that may significantly impact
maintenance and/or improvement activities. These can either be permanent issues, such as
BMS Re-write Phase 2 Conceptual System Design Report 56
System Architecture
BMS Re-write Phase 2
structures located near stadiums, or point-in-time issues such as temporary obstructions or
structure conditions.
2.4.2.1.12 Narrative
Descriptive information about a structure, including location, historical significance, unique facts,
etc. An unlimited number of narrative lines can be created for a structure. If required, a
narrative type attribute can be defined for this entity to allow narrative descriptions to be
categorized for different purposes.
2.4.2.1.13 Network
The business plan network or corridor to which a structure can be linked for system analysis
and planning. It is assumed that a structure can exist in multiple networks simultaneously.
2.4.2.1.14 Paint
Descriptive information about the painting history for the structure, including the date, type of
paint used, number of coats, etc.
2.4.2.1.15 Planning Partner
The planning partner area within which the structure exists. Planning partners include Municipal
Planning Organizations (MPO), Rural Planning Organizations (RPO) and Independent Counties
(IC).
2.4.2.1.16 Project
An MPMS project associated with one or more structures. Projects are associated with major
maintenance, improvement, rehabilitation or replacement activities. This entity may be replaced
by a real-time interface between BMS and MPMS.
2.4.2.1.17 Project Estimate
Cost estimate for a project. Estimates can include preliminary estimates for project planning,
design estimates for programming, and detailed estimates for letting. This entity allows multiple
estimates to be retained for a project, highlighting the progression of an estimate over the life
cycle of a project.
2.4.2.1.18 Project Narrative
A narrative description of a structure project. Linking this entity to the Structure Project entity
allows structure-specific descriptions to be entered for a project.
2.4.2.1.19 Proposed Improvement
A major rehabilitation, improvement or replacement project planned or required for a structure.
2.4.2.1.20 Proposed Improvement Narrative
The narrative description of a project planned or required for a structure.
2.4.2.1.21 Proposed Span Improvement
Span-level detail information for a major rehabilitation, improvement or replacement project
planned or required for a structure.
BMS Re-write Phase 2 Conceptual System Design Report 57
System Architecture
BMS Re-write Phase 2
2.4.2.1.22 PUC Number
The PSC-PUC Docket Number(s) assigned to structures that are in the jurisdiction of the PUC.
This entity allows multiple numbers to be stored for a structure.
2.4.2.1.23 Related Structure
This entity is used to create a link between a structure and one or more other structures, such
as sign structures or retaining walls associated with a bridge.
2.4.2.1.24 Roadway
Detailed information about a state-owned roadway intersecting feature for a structure, obtained
via an interface with RMS. This data represents the RMS view of the on and under roadways
associated with a structure, and will be consolidated with the Feature Intersected entity.
2.4.2.1.25 Structure Electronic Document
This entity defines the relationship between a structure and an electronic document or image,
since a particular document/image can be related to multiple structures (e.g., a sign attached to
a bridge).
2.4.2.1.26 Structure Project
This entity defines the relationship between a structure and a corresponding project, since a
project can be associated with multiple structures and a structure can be associated with
multiple projects (in various statuses). Candidate projects can also be created in this entity prior
to the existence of a corresponding project in MPMS.
2.4.2.1.27 Time and Materials
The time and materials breakdown for contractor work on a project. This entity may not be
required if the information can be pulled on demand from ECMS or some other PENNDOT
system. Information within this entity can be used as the basis for current or future construction
cost estimates.
2.4.2.1.28 Traffic
Average daily traffic and truck traffic counts for a roadway intersecting feature, identified by date
compiled. This entity allows multiple traffic counts to be retained for a feature, including
historical traffic counts from prior years.
2.4.2.1.29 Utility
Description information about utilities attached to a structure. An unlimited number of utility
entries can be created for a structure.
2.4.2.1.30 Work Order
A grouping of one or more maintenance activities for a structure. For proposed maintenance,
work orders represent activities for a structure that a maintenance manager intends to be
completed at the same time. Activities are grouped into work orders in support of the
MORIS/MySAP interface.
2.4.2.2 Inspection
A generic Inspection entity exists to define the common information for the various inspection
types that the new BMS must support. These detailed inspection types include routine
BMS Re-write Phase 2 Conceptual System Design Report 58
System Architecture
BMS Re-write Phase 2
bridge/culvert inspections, retaining wall inspections, underwater inspections, probing
underwater inspections, sign inspections, tunnel inspections, fracture critical inspections, and
high mast lighting inspections. Information within the system that is common to all of these
structures, such as the inspection identifier, the date of the inspection, the structure being
inspected, etc., is defined within the Inspection entity or any entities related to the Inspection
entity (e.g., Inspection Status). Information that is specific to a particular type of inspection is
contained within the corresponding detail entity.
2.4.2.2.1 Inspection
Generic information common to inspections for all structure types (bridges, culverts, retaining
walls, signs, etc.) This generic information includes the structure identifier, inspection identifier,
date of inspection and inspection type. This entity establishes the primary identifier for each
inspection record.
2.4.2.2.2 Bridge Inspection
Inspection data recorded for a routine bridge inspection.
2.4.2.2.3 Crane
The inventory of bridge cranes available for bridge inspections. This entity identifies information
about the crane, such as its reach, weight capacity and home district, and provides a unique
identifier so that specific cranes can be assigned to specific inspections.
2.4.2.2.4 Crane Schedule
The current schedule for bridge cranes required for bridge inspections. Included within the
schedule are assignments of specific cranes to inspections, based upon the length of reach and
availability of a crane. This entity can be set up to maintain a history of scheduling, if required
for trend, scheduling and/or future needs analysis.
BMS Re-write Phase 2 Conceptual System Design Report 59
System Architecture
BMS Re-write Phase 2
2.4.2.2.5 Dept Inspection Team
PENNDOT inspection team assigned to perform one or more structure inspections. Either a
PENNDOT team or a consultant team must be assigned to every inspection. Each inspection
team is identified with a team leader.
2.4.2.2.6 Fracture Critical Inspection
Inspection data recorded for a fracture critical structure inspection.
2.4.2.2.7 Fracture Critical Span Inspection
Span-level inspection data recorded for a fracture critical structure inspection.
2.4.2.2.8 High Mast Light Inspection
Inspection data recorded for a high mast light or other light tower inspection.
2.4.2.2.9 Inspection Status
The current status and status history for an inspection. Status entries in this entity include the
user and timestamp associated with the status change. Statuses for an inspection include the
upload of data from an Electronic Data Collector (EDC), approval of the inspection by an
authorized PENNDOT user, and data revisions.
2.4.2.2.10 Probing Inspection
Inspection data recorded for a probing underwater bridge inspection that does not require
divers.
2.4.2.2.11 Retaining Wall Inspection
Inspection data recorded for a retaining wall inspection.
2.4.2.2.12 Safety Feature
The types of safety features (precast, cast in place, barriers, etc.) and their location as recorded
during an inspection. This entity is essentially an expansion of the E28A Safety Feature Code
field in the current BMS.
2.4.2.2.13 Sign Inspection
Inspection data recorded for a sign inspection.
2.4.2.2.14 Span Inspection
Span-level inspection data recorded for a routine bridge inspection.
2.4.2.2.15 Substructure Underwater Inspection
Detailed substructure inspection data recorded for an underwater bridge inspection.
2.4.2.2.16 Tunnel Inspection
Inspection data recorded for a tunnel inspection.
2.4.2.2.17 Underwater Inspection
Inspection data recorded for underwater bridge inspections that require the use of divers.
BMS Re-write Phase 2 Conceptual System Design Report 60
System Architecture
BMS Re-write Phase 2
2.4.2.3 Bridge Detail
This section represents all of the detailed information that is specific to bridges and culverts.
2.4.2.3.1 Bridge
Structure-level general information specific to Bridges and Culverts. This is the parent entity for
all bridge/culvert specific entities in the database.
BMS Re-write Phase 2 Conceptual System Design Report 61
System Architecture
BMS Re-write Phase 2
2.4.2.3.2 Abutment
Descriptive information about the abutments and abutment foundations associated with a bridge
or culvert. Abutments can be linked to their location at the near or far end of the structure
(referencing the direction of increasing segments).
2.4.2.3.3 APRAS Clearance Data
Establishes the key value used to identify a related set of clearance values for a roadway
reference.
2.4.2.3.4 APRAS Horizontal Vertical Clearance
A set of related horizontal and vertical clearance values for a roadway reference, used to
support APRAS oversize bridge analysis. The clearance values are specified at measured
distances from a standard, fixed reference point (e.g., the left lane boundary).
2.4.2.3.5 APRAS Inventory Load
The inventory load capacity values for a structure used to analyze the structure load capacity for
an APRAS permit. Multiple inventory load values can exist for a particular bridge span.
2.4.2.3.6 APRAS Operating Load
The operating load capacity values for a structure used to analyze the structure load capacity
for an APRAS permit. Multiple operating load values can exist for a particular bridge span.
2.4.2.3.7 APRAS Permit Restriction
A permit restriction to be applied to oversize/overweight vehicles passing over the roadway
associated with the structure.
2.4.2.3.8 APRAS Rating
Detailed span-level information required for APRAS permit analysis. This entity corresponds to
the APRAS Rating Permit (APRAS_RATING_PERMT) table in the current RBIDB, combined
with the APRAS Permit Data (APRAS_PERMIT_DATA) and APRAS BMS Rating
(APRAS_BMS_RATING) tables. This entity includes all of the associated attributes from all
three tables. A relationship with the Span entity was created to support the concept of a
common span identifier for all span-related entities.
2.4.2.3.9 APRAS Rating Narrative
Narrative information describing the detailed data used for APRAS permit analysis. This entity
corresponds to the APRAS Rating Narrative (APRAS_RATING_NARR) table in the current
RBIDB, combined with the APRAS Narrative (APRAS_NARRATIVE) table. These tables were
combined because they contained the same attributes and served the same basic purpose.
2.4.2.3.10 APRAS RMS Reference
Establishes an on or under roadway reference for which detailed clearance measurements can
be created to support APRAS oversize bridge analysis.
2.4.2.3.11 APRAS Span Permit
General span information established in conjunction with the detailed span-level information
required for APRAS permit analysis.
BMS Re-write Phase 2 Conceptual System Design Report 62
System Architecture
BMS Re-write Phase 2
2.4.2.3.12 Bearing
The number and types of bearing for a bridge. Multiple bearing entries can be created for a
bridge.
2.4.2.3.13 Bridge Bill
A legislative bill that authorizes the spending of funds for a particular bridge or bridge project. A
bridge/culvert can only be linked to a single bridge bill at any one time.
2.4.2.3.14 Expansion Joint
The number and types of expansion joints for a bridge. Information in this entity will include the
type of joint, movement, and manufacturer. Multiple joint entries can be created for a bridge.
2.4.2.3.15 Fracture Critical Member
Information about the fracture critical members and other fatigue-prone structural elements for a
bridge or culvert.
2.4.2.3.16 Inlet Outlet
Descriptive information about the inlets and outlets associated with a bridge or culvert.
2.4.2.3.17 Inventory Load
The inventory load ratings for a bridge or culvert, identified by date analyzed. This entity allows
multiple load ratings to be retained for a structure, including historical ratings from prior years.
2.4.2.3.18 Maintenance Deficiency
The Maintenance Deficiency Rating for a structure. This entity allows multiple maintenance
deficiency values to be retained for a structure, including historical ratings from prior years.
2.4.2.3.19 Navigation Protection
Descriptive information about waterway navigation protection features for a bridge passing over
water, such as fenders, dolphins, etc.
2.4.2.3.20 Observed Scour Assessment
Parameters and other data associated with the Observed Scour Assessment database, which is
to be incorporated into the new BMS database. It is used to record scour observations for a
structure that are not necessarily associated with a formal inspection.
2.4.2.3.21 Operating Load
The operating load ratings for a bridge or culvert, identified by date analyzed. This entity allows
multiple load ratings to be retained for a structure, including historical ratings from prior years.
2.4.2.3.22 Pier
Descriptive information about the piers and pier foundations associated with a bridge or culvert,
including the type of material and configuration.
2.4.2.3.23 Posting
The history of all postings for a bridge, including the current posted status.
BMS Re-write Phase 2 Conceptual System Design Report 63
System Architecture
BMS Re-write Phase 2
2.4.2.3.24 Repair
Repair history for a bridge. Most of this information originated in the SIRS system that preceded
BMS, and is not actively maintained within the current BMS. An evaluation of the
appropriateness of converting this information to the new BMS must be performed.
2.4.2.3.25 Span
Detailed information associated with the spans for a bridge, including a unique identifier for each
span. This entity includes the ability to identify identical spans for analysis purposes.
2.4.2.3.26 Span Inventory Load
The inventory load ratings for a specific bridge span, identified by date analyzed. This entity
allows multiple load ratings to be retained for a span, including historical ratings from prior
years.
2.4.2.3.27 Span Operating Load
The operating load ratings for a specific bridge span, identified by date analyzed. This entity
allows multiple load ratings to be retained for a span, including historical ratings from prior
years.
2.4.2.3.28 Steel Type
The type of steel used for the fabrication of main steel bridge members, such as beams, girders
and trusses. Each entry in this entity must identify the specific bridge member for which the
steel type is defined.
2.4.2.3.29 Strand
Strands associated with bridges using prestressed girders. Multiple strand entries can be
created for a bridge.
2.4.2.3.30 Sufficiency
The Sufficiency Rating for a structure, along with all component values used to calculate the
rating. This entity allows multiple Sufficiency Rating values to be retained for a structure,
including historical ratings from prior years.
2.4.2.3.31 TDR
The Total Deficiency Rating (TDR) for a structure, along with all component values (e.g., bridge
condition deficiency, deck width deficiency, vertical clearance deficiency, etc.) This entity allows
multiple TDR values to be retained for a structure, including historical ratings from prior years.
2.4.2.3.32 Void
Voids associated with the prestressed girders for a bridge, including their type and location.
Multiple void entries can be created for a bridge.
2.4.2.3.33 Wingwall
Descriptive information about the wingwalls and wingwall foundations associated with a bridge
or culvert.
BMS Re-write Phase 2 Conceptual System Design Report 64
System Architecture
BMS Re-write Phase 2
2.4.3 Additional Field Requirements
To meet the defined PENNDOT user requirements, data fields must be added to the Pontis
database. The list of new fields was derived from the BMS requirements and from the Pontis
software analysis effort, during which it was determined whether a required field was provided
by Pontis. As a standard, the core Pontis tables will not be modified to include PENNDOT-
specific fields unless absolutely necessary - this will help to minimize the impact of the
PENNDOT customizations on future Pontis upgrades. In many cases, the new fields will be
included in the existing Pontis tables provided for the addition of agency-specific data.
However, in those cases where the primary key structures for these tables do not support the
required relationships, additional PENNDOT-specific tables will be created.
The following list is sorted by New or Existing, Pontis Data Category and Field Name, with New
fields listed first followed by existing BMS fields identified by BMS code. In many cases, a
single field reference actually defines a requirement for several related fields and/or a multi-
occurrence field (e.g., current and prior values for a particular field).
New or Pontis Data
Field Name Field Description Exist Category
Condition Rating Comment Add a comment field to the AM - Condition Rating Data New Inspection
screen.
Condition Ratings for Provide new condition rating data fields to support new New Inspection
Performance Measures performance measures as they are adopted, such as:
Mobility and Access, Closed, posted, or weak link
bridges, Sufficiency Rating, Structurally Deficient and
Functionally Obsolete, Accomplishments vs. Needs
(track by rehabilitation, replacement, or preservation),
Maintenance First, Bridge Preservation, Bridge
Inspection and Bridge Permits.
Fracture Critical Members Record unlimited information about fracture critical New Inspection
members and fatigue-prone details. The AJ - Fracture
Critical Screen is currently limited to seven lines.
Gauge Point Underclearance Document the gauge point underclearance to the New Inspection
streambed at multiple points for piers and abutments
for in, out, and depth (not to the top of the water level
as done by USGS), including abutment in and out
(Upstream and Downstream) and pier in and out, both
sides (Upstream and Downstream). This helps provide
a value for scour rather than a narrative description.
High Mast Light Location Capture high mast light tower locations (latitude- New Inspection
longitude and County/SR/Segment/Offset).
High Mast Light Overall Record one overall condition rating for High Mast New Inspection
Condition Lighting. This is a subjective rating.
Hiring Agency Indicate the agency that hired the consultant for the New Inspection
inspection.
Inspection Agreement Record local bridge inspection agreement contract New Inspection
Contract Number number to BMS.
Inspection Equipment and Associate requirements for equipment and permits for New Inspection
Permits any type of inspection for a structure. Allow
association of multiple types of equipment, railroad
permits, coast guard permits, and so forth, with the
same inspection.
BMS Re-write Phase 2 Conceptual System Design Report 65
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Inspection Schedule Add and maintain schedules for other inspection types, New Inspection
damage and interim. Currently, this schedule
information is captured and maintained outside BMS.
Inspection Weather Record weather conditions during an inspection. This New Inspection
Conditions data is currently captured in eForms
Load Rating Analysis Indicate that a load rating analysis is required, including New Inspection
Required an explanatory statement, if identified during an
inspection. This is a flag from the inspection to the
rating engineer. Currently, the BMS Coordinator
receives a report and then sends it to the rating
engineer for prioritization. There is an indicator in the
EDC to say a reanalysis is required but it is currently
not uploaded to BMS. Another trigger for turning on
this indicator could be a significant event in the bridge
problem reporting. District Bridge unit would need the
ability to override the trigger or indicator
Minimum and Maximum Capture minimum and maximum diameter of high mast New Inspection
Light Tower Diameter light tower.
Obstruction Narrative Provide a narrative field to record obstructions that may New Inspection
increase the duration of the crane inspection.
Obstructions can include light poles, sign structures,
fences, and so forth.
PUC Number Capture multiple occurrences of the PUC number New Inspection
(currently the A13 field in BMS).
Remaining Steel Section Develop and provide a consistent statewide template New Inspection
for remaining steel section for completing analysis for
use on the EDC and attach this form to the inspection
report. Some Districts already use a standard form.
Structure Comment Enter comments indicating issues with state-owned New Inspection
structures for consideration during planning.
Tunnel Overall Condition Record one overall condition rating for tunnels. New Inspection
Utility Repair Required Indicate in inspection that a utility needs repair and that New Inspection
the utility company must be contacted.
Water Depth, Velocity and Capture the water depth, velocity, and number of units New Inspection
Number of Units of the waterway to assist in calculating the cost of the
waterway inspection.
Water Flow Indicator When displaying Observed Scour data, indicate that it New Inspection
refers to water flow.
Waterway Inspection Type Support two waterway inspections, probing and New Inspection
underwater. The current BMS treats all waterway
inspections as underwater. On the BMS AW screen,
the W11-B field, Unit Inspection Type, allows coding
that distinguishes between inspections done by probing
or divers. Typically, when the water is less than four
feet deep the inspection is considered probing; greater
than four feet is underwater.
BMS Re-write Phase 2 Conceptual System Design Report 66
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Beam Characteristics Record the beam width, beam depth, flange web New Inventory
thickness and depth, W-shape, AASHTO beam shape,
and beam spacing. Potential problem for increasing
EDC and BMS database size. See Craig Beissel for
beam size, type, and shape.
Concrete/Steel Member Capture concrete or steel member properties, such as New Inventory
Properties the Charpy V-Notch (CVN) test used for evaluating
steel requirements (can get this information from the
plans - product performance).
Contribution to Historic Capture Contribution to Historic District for planning New Inventory
District purposes. FHWA and EQAD determine eligibility.
Eligibility is different for individual historic bridges than
for those in Historic Districts.
Culvert Access Information Capture culvert access information, e.g., a narrative New Inventory
that a culvert ends in storm drains, manhole access,
etc.
Culvert Fill Height Capture culvert fill height including maximum and New Inventory
minimum under the roadway as it impacts load ratings.
Culvert Floor Type Indicate if a culvert has a floor (yes or no). New Inventory
Culvert Opening Capture culvert opening height and width for multiple New Inventory
Height/Width inlets and outlets.
Decorative Treatments Capture presence of decorative treatments on noise New Inventory
walls (Yes or No indicator).
Deicing System Type Capture deicing system information for a bridge. New Inventory
Demolition Date Maintain historical data for structures that have been New Inventory
demolished or replaced, including previous inspection
data, maintenance, preservation, and replacement
information. A demolished field and date can be added
for this purpose. This can also be used to determine
loss rates for different types of bridges and longevity of
structure types.
DEP Stream Designation Capture DEP Stream designation information for a New Inventory
structure. Designation information includes the
following: (1) HQ, EV, CWF, WWF & PFBC Wild Trout
Classification, (2) time frame you can do the work, and
(3) the type of permit.
Detour Length and Route Record detour length and route for legal size and New Inventory
weight and for over size and weight for a specific
structure. This information must be available to the
design team on a project for consideration in MPT
planning.
Estimate Total Deficiency Indicator (M23 - Estimated/Updated) to show that the New Inventory
Rating Indicator total deficiency rating has been estimated based on
default values or needs to be updated due to recent
data changes. The 3 estimated/updated fields on the
AM screen in the current BMS are: M07 (Eligibility of
Bridge FCB Funds), M23 (Estimated/Updated) and
M35 (County Ranking Based on Maintenance
Deficiency Points).
BMS Re-write Phase 2 Conceptual System Design Report 67
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
High Mast Light Bulb Type Capture voltage and wattage of high mast light tower. New Inventory
High Mast Light Distance Capture high mast lighting tower distance from New Inventory
from Road roadway, looking segments ahead R, L.
High Mast Light Foundation Capture type of foundation material and mounting for New Inventory
Material high mast lighting structure.
High Mast Light Grounding Indicate (yes or no) if the mounting anchor bolt base is New Inventory
Type grounded.
High Mast Light Utility Capture power supplier or utility company responsible New Inventory
for high mast lighting.
Historic District Indicate that Bridge location, for example, is in a New Inventory
historic district.
Historic Maintenance and Capture narrative information about maintenance and New Inventory
Improvement Description improvement guidelines for historic structures and
other historical data.
Homeland Security Identify if a bridge meets certain criteria for Homeland New Inventory
Designation Security designation. Currently 48 bridges meet the
criteria. The system must identify critical structures for
infrastructure security purposes.
Infrastructure Security Record information for a structure related to New Inventory
infrastructure security. (Is parking allowed under the
structure? What other key access points are there for
the structure? What emergency services use the
structure? How close are emergency services to the
structure? This could be a separate screen where this
information is listed.) These should be separate fields
to allow sorting on each question. Per Jon Oravec, this
can be a narrative screen
Lockbox Location Capture location of key to lockbox for a high mast light New Inventory
tower or other structure type.
Minimum Crane Reach Identify the minimum reach crane needed for a New Inventory
Required structure. For example, a 40-foot crane does not work
on a structure that requires a 60-foot reach crane. The
original idea was to coordinate crane reach with deck
geometry.
Miscellaneous Structure Capture narrative information about miscellaneous New Inventory
Narrative details for a structure such as who puts flags up on
Flag Day.
Mounting Type Capture structure mounting type - mounted on the New Inventory
bridge, ground, in the earth (for noise walls).
MUSIC Location Reference Store the Municipal Service Information Center New Inventory
(MUSIC) location reference for the segment within
which the structure exists (Municipality code + Road
name + Township route+ segment). MUSIC is used to
track location of local roads and is tied to liquid fuels
tax.
Network/Corridor Define networks and corridors to support structure New Inventory
analysis and planning, including the business plan
network and corridor in which a structure exists.
BMS Re-write Phase 2 Conceptual System Design Report 68
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Noise Wall Distance from Capture noise wall distance from the road. New Inventory
Road
Noise Wall Height Capture height of noise wall. New Inventory
Noise Wall Installation Type Capture if noise wall was installed on a new roadway or New Inventory
retrofitted to an existing roadway.
Noise Wall Length Capture length of noise wall. New Inventory
Noise Wall Location Capture location of the noise wall on the left or right New Inventory
side of highway.
Noise Wall Manufacturer Capture manufacturer of noise walls. New Inventory
Noise Wall Plan Number Capture noise wall plan number. New Inventory
Noise Wall Start/End Capture start and end segment and offset for the noise New Inventory
wall. Same requirement as a retaining wall - use
segment and offset for beginning of wall.
Noise Wall Type Capture type of noise wall, for example: post and New Inventory
panel, other, etc.
Record Storage Box Id Capture storage box numbers identifying location of New Inventory
paper documents in storage for a structure.
Retaining Wall Distance from Capture distance from the retaining wall to the road. New Inventory
Road
Retaining Wall Height and Capture height and clearance for retaining walls that New Inventory
Clearance protect the roadway.
Retaining Wall Manufacturer Capture manufacturer of retaining walls. New Inventory
Retaining Wall Start/End Specify the beginning and ending segment or offset of New Inventory
a retaining wall.
Retaining Wall Support Type Identify what a retaining wall is supporting, using up New Inventory
(holding back the side of a hill) or down (supporting the
roadway) indicators.
Safety Feature Type Identify the types of safety features (precast, cast in New Inventory
place, barrier types, etc.) and their location
(Near/Far/Right/Left). Rating appraisals are not
enough. Also, do not tie to a standard because
standards change. Should be accomplished by
BQAD's revision of BMS item E28A, Traffic Safety
Features.
Speed Reduction Factor Record psychological speed reduction factors. New Inventory
Structure Foundation Capture narrative data on structure foundation from soil New Inventory
Narrative borings.
Tunnel Drainage Capture inventory information on tunnel drainage New Inventory
systems, for example: type, location, age, etc.
Tunnel Historic Eligibility Capture inventory information for tunnels with individual New Inventory
and/or contributing historic eligibility.
Tunnel Invert Type Record the tunnel invert type. The invert of a tunnel is New Inventory
the slab on which the roadway is supported.
BMS Re-write Phase 2 Conceptual System Design Report 69
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Tunnel Lighting Capture inventory information on tunnel lighting New Inventory
systems, for example: mounting type, location (over
traffic or not), age, etc.
Tunnel Monitoring Location Identify specific station or distance from the end of the New Inventory
tunnel for recording and monitoring defects.
Contributes to inspection consistency by establishing a
baseline
Tunnel Shape Record tunnel shapes. Typically, highway tunnel New Inventory
shapes can be circular, rectangular, horseshoe, and
oval or egg.
Tunnel Traffic Protection Capture inventory information on tunnel traffic New Inventory
protection barriers, for example: type, location, age,
etc.
Turnback Information Capture structure and roadway turnback data for a New Inventory
structure. This data is inconsistently captured on the
BMS AL screen today. This is to improve ownership
data and make consistent statewide.
Parameter Last Updated Capture user name and user ID of the person who New Programming
User and Timestamp changed the parameters last, and the timestamp when
the change occurred.
Bridge Bill Candidate Identify if a bridge is a candidate for a future bridge bill. New Project
Contractor Work Breakdown Capture time and materials breakdown for contractor New Project
work. Typically this is not a lump sum - however, if
PENNDOT wants it contracted as a lump sum, that is
what will be in ECMS.
Cost Estimate Store multiple estimates for a variety of scopes of work; New Project
maintenance, preservation and/or improvements.
District Project Priority Record District priority number for a structure project. New Project
Paint Code Maintain a history of paint coating ID codes and New Project
application dates. Verify input at project finalization by
construction.
Phase Forecast Cost Report forecast dollars needed for the individual New Project
phases (PE, FD, U-ROW, Const) separately from
current estimate for TIP program in order to flag
potential areas of bridge funding shortfall per user-
defined criteria. Consider in-house versus consultant
cost differentials, changes in cost from rural to urban
area; and include contractor and in-house work if both
are required.
Related MPMS Number Provide MPMS number(s) and indicate if a structure is New Project
programmed as part of a roadway project or
independently. When a bridge project is entered in
MPMS it should have a BMS number. However, if
structures have not been associated with a project
within MPMS, no links will be created within BMS even
if the project is actually related to one or more
structures.
Related Roadway Indicate planned roadway improvement projects near New Project
Improvement Project bridge location.
BMS Re-write Phase 2 Conceptual System Design Report 70
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Work Category Split Identify the work category splits for a project. New Project
Environmental Clearance Indicate the level of environmental clearance or if there New Work Candidate
Level Required are significant environmental issues with the project.
Extreme Scour Indicator Indicate if there is extreme stream scour and New Work Candidate
associated costs.
Include Highway Flag or identify desired or required highway New Work Candidate
Improvements In Bridge improvements to be included in bridge projects.
Project
MP&T Requirements Indicate special M&PT requirements that significantly New Work Candidate
impact construction costs, for example, half-width
construction, night work, incentive clauses.
Project Cost by Category Track and archive estimates of engineering, right-of- New Work Candidate
way, and construction costs for all TIP projects
involving bridges.
Roadway Reconstruction Identify roadway costs associated with a bridge New Work Candidate
Cost reconstruction.
Temporary Structure Indicate if temporary bridges are required as part of the New Work Candidate
Required project.
County/SR/Segment/Offset Record the location of a structure by its A01 Inventory
County/SR/Segment & Offset.
Senatorial District Record the location of a structure by its State A02 Inventory
Senatorial District (same as R13 today).
Congressional District Record the location of a structure by its US A03 Inventory
Congressional District (same as R14 today).
Legislative District Record the location of a structure by multiple A04 Inventory
Legislative Districts (same as R15 today).
Agency Submitting Record the agency responsible for preparing and A05 Inventory
submitting the Structure Inventory Record. Capture at
least 4 characters to accommodate DCNR.
Latitude/Longitude Record the location of a structure by its latitude and A07, 8 Inventory
longitude. Allow for multiple latitude longitude points for
structure over 8 feet.
Intersecting Boundary Record the county or municipal boundary that A10 Inventory
intersects with a structure.
Federal Funds Used for Record if a structure was built or reconstructed with A12 Inventory
Construction federal funds.
PUC Docket Number Record PUC docket number when the PUC has A13 Inventory
jurisdiction over a structure.
Legislative Act Number Record the Legislative Act number that transferred A21 Inventory
ownership.
Maintenance Responsibility Record the party responsible for maintaining each A22, 23 Inventory
portion of the bridge.
Approach Pavement Width Record the pavement width of the roadway A29 Inventory
approaching the structure.
Structure Width Variance Record variances in width for a structure. A32 Inventory
BMS Re-write Phase 2 Conceptual System Design Report 71
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Ground-level Bypass Record if a ground-level bypass exists and the length A35 Inventory
of the detour if the structure is closed.
Structure Curve Record whether the structure is on a vertical curve or a A36 Inventory
horizontal curve.
County Subdivision Record the county subdivision for the structure. A37 Inventory
LRS Feature Designation Record the SR and segment designations of features B02 Inventory
inventoried using PENNDOT Location Referencing
System.
Skew Angle Record the skew angle of the feature intersected. B09 Inventory
Number of Electrified Record the number of electrified railroad tracks for B12 Inventory
Railroad Tracks each railroad feature being recorded.
Railroad Name Record the service status and the name of the railroad. B13 Inventory
AAR Number Record the Association of American Railroads (AAR) B14 Inventory
number for the specific railroad-highway crossing for
the specific structure.
Railroad Milepost Record the railroad milepost at which the structure is B15 Inventory
located.
Administrative Jurisdiction Record the administrative jurisdiction for the highway. B16 Inventory
Jurisdiction refers to responsibility for planning, design,
and construction of the roadway.
State Highway Network Record the State highway network designation of the B19 Inventory
highway feature being described. For example, Priority
Commercial, Core Highway, Agri-Access, and ICAN.
Defense Vertical Clearance Record the defense vertical clearance left and right B23 Inventory
Left/Right (defense vertical clearance is the maximum height a
ten foot wide vehicle may be and still pass along the
described feature).
Vertical Clearance Signing Record the presence of vertical clearance signing for B31 Inventory
the highway feature described.
Estimated Cumulative Truck Record the number of trucks (in thousands) that C02 Inventory
Traffic Fatigue Life represents the estimate of the cumulative truck traffic
that will result in the initiation of fatigue damage on the
most fatigue prone member of the bridge.
Design Method Indicate if Service Load Design or Load Factor Design C04 Inventory
was the method used in the design of the bridge.
Culvert Barrel Length Under Record culvert barrel length under fill, along its C06 Inventory
Fill centerline.
Beam Geometry Record the geometry of the main beams or girders of a C11 Inventory
bridge (currently capture 7 types).
Steel Type Record the types of steel used in the fabrication of C12 Inventory
main steel bridge members such as beams, girders,
and trusses. Currently limited to entry of 4 types of 15
available choices.
Estimated Cumulative Truck Record the estimated cumulative truck traffic in C14 Inventory
Traffic thousands. (Reserved for future use.)
BMS Re-write Phase 2 Conceptual System Design Report 72
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Date of Cumulative Truck Record the month and year of estimated cumulative C15 Inventory
Traffic Estimate truck traffic in thousands. (Reserved for future use.)
Adjacent Span Count and Record the number and lengths of adjacent spans. C17 Inventory
Length
Critical Ranking Factor Record the bridge or approach Critical Ranking Factor, C18-A Inventory
including the following: Type of member (capture 6
types today), Fatigue crack susceptibility (capture 9
AASHTO Stress Categories today), Material (capture 7
Weldable Steel grade/CVN at +40 types today) and
cumulative truck traffic (includes ADTT and Remaining
Fatigue Life).
Deck Form Type Record the type of deck form used: removable or C20 Inventory
permanent metal (stay-in-place).
Steel Splice Type Record the type of field splice used for steel beam C24 Inventory
structures.
Compressive Strength at Record the compressive strength of beam concrete at C26 Inventory
Release (F'CI) the time of initial prestress (release) for bridges with
prestressed girders.
Compressive Strength at 28 Record the compressive strength of beam concrete at C27 Inventory
Days (F'C) 28 days for bridges with prestressed girders.
Strand Size Indicate the size(s) of strand used on bridges with C28 Inventory
prestressed girders.
Design Tensioning Method Indicate the design tensioning methods used for a C29 Inventory
bridge with prestressed girders.
Strand Type Indicate if the prestressing strands used in the C30 Inventory
prestressed girders are straight or draped.
Prestressed Vacuum Indicate if the vacuum process for concrete curing was C31 Inventory
Process used for a bridge with prestressed girders.
Haunch Type Indicate the type of haunch (inside and outside) in the C32 Inventory
prestressed beams.
Void Type Indicate the type(s) of voids in the prestressed girders. C33 Inventory
Utilities Present Indicator Indicate if utilities are present in the prestressed girders C34 Inventory
of a bridge.
Live Load Design Type Indicate if live load was incorporated in the design of C35 Inventory
the beams.
Prestressed Splice Type Indicate the type of joints (field splice) used. C36 Inventory
Culvert Tie Type Indicate the type of tie used on a tied arch culvert. C42 Inventory
Utility Company Occupancy Reference utility company occupancy. D01 Inventory
Utility Contact Name and Record the name and address of the owner of the utility D02 Inventory
Address relative to any utilities carried by the structure.
Utility License Number Record the license number of the utility that allows the D03 Inventory
utility to occupy the structure, including the date the
license was approved.
Utility Weight Record the total weight of the utility including all D05 Inventory
hardware attached to the bridge in kips to the nearest
tenth.
BMS Re-write Phase 2 Conceptual System Design Report 73
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Size of Drainage Area Record the size of the drainage area for the stream the D07 Inventory
bridge passes over.
Design Flood Record the design flood data for a stream passing D09 Inventory
under a bridge including magnitude, frequency,
elevation and velocity.
Date of Maximum Known Record the year the maximum known water surface D10 Inventory
Water Elevation elevation occurred.
Maximum Known Water Record the maximum known water surface elevation. D10 Inventory
Elevation
Fishable Indicator Record if a stream is fishable (fishable is also D11 Inventory
stockable).
Navigation Protection Indicate the presence and adequacy of navigation D12-A Inventory
Feature protection features such as fenders, dolphins, etc.
when navigation control exists.
Calculated Scour Depth Record the calculated scour depth for bridges requiring D12-B Inventory
divers for underwater inspection and if the calculation is
for 100 year flood or 500 year flood.
Closed/Posted/Open Status Record closed, posted or open status including specific D13 Inventory
signage and stress level information.
Special Restrictive Posting Record the type of special restrictive posting for the D14 Inventory
bridge.
Posted Load Limit Record the posted load limits for the bridge. D15 Inspection
Load Limit Field Condition Record the field conditions that may influence the D19 Inventory
determination of load limits for a posted bridge.
Examples of field conditions: stop signal and steep
grade.
Load Limit Special Condition Record special conditions that may influence the D20 Inventory
determination of load limits for a posted bridge.
Examples of special conditions: near a quarry, truck
stop.
AASHTO Impact Factor Capture the AASHTO Impact Factor for a bridge and D21 Inventory
indicate if the determination of load limits is influenced
by the impact being lower or higher than permitted by
AASHTO Specifications (AASHTO Impact Factor)
Flood Inspection Indicator Identify structures for inspection after heavy rainfall or E02-A Inspection
flooding.
Special Inspection Required Record the type of special inspection that is needed E04 Inspection
before the next bridge inspection.
High Voltage Power Line Record the presence of cables or high voltage power E05-A Inventory
lines that may impede an inspection.
Inspection Cost Record the cost of the bridge inspection. This data is E11 Inspection
also used to recoup the local share of inspection costs
in accordance with Act 44 of 1988.
Estimated Remaining Life Record the estimated remaining service life of the E23 Inspection
bridge in years until its next major rehabilitation or
replacement.
Inventory Rating Record the Inventory rating for up to five load types. E30 Inventory
BMS Re-write Phase 2 Conceptual System Design Report 74
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Operating Rating Record the Operating rating for up to five load types. E31 Inventory
Rating Analysis Method Record the analysis method for determining the E32 Inventory
inventory and operating ratings and the controlling and
governing stress.
AASHTO Manual Year Record the year of the AASHTO manual, for bridge E38 Inspection
maintenance inspections used to determine condition
ratings.
Type of Service After Indicate the type of service to be provided on a F03 Project
Improvement structure after the proposed improvements are made.
Proposed Improvement Record the length of the proposed improvement with F04 Work Candidate
Length approach (structure + roadway).
Proposed Structure Record the length of the proposed structure or length of F05 Work Candidate
Improvement Length the structure that is to be improved (required by
HBRR).
Proposed Structure Width Record the out-to-out width of the proposed structure. F06 Work Candidate
Proposed Roadway Width Record the width of the proposed reconstructed F07 Work Candidate
roadway.
Proposed Design Load Indicate the proposed design load for the improvement. F08 Work Candidate
Proposed Number of Lanes Record the number of lanes proposed as part of the F09 Work Candidate
improvement.
Drawing Number Capture the drawing number for the repair. Data in this G03 Work Candidate
field must be evaluated to determine the
appropriateness of converting it for use in BMS.
Painted Steel Weight Capture the weight of the steel painted in tons. G10 Project
Estimated Paint Surface Capture the estimated surface area (sq.ft.) requiring G11 Project
Area painting.
Number of Coats Capture the number of coats of paint applied to the G12 Project
bridge.
Paint Quantity Capture the number of gallons of paint applied to the G13 Project
bridge.
Paint Color Code Capture the color code number of the finish coat of G14 Project
paint applied to the bridge.
Structure Cleaning type Capture the type of cleaning used on a bridge. G15 Project
Paint Coat Type, Extent and Capture the type, extent and thickness of paint used on G16 Project
Thickness a bridge for the primer, intermediate and finish coats.
Estimated Cost Manual For proposed maintenance, indicate if the estimated H07 Work Candidate
Override cost of bridge maintenance activity computed by the
system has been manually overridden.
Inspection Date Manual For proposed maintenance, indicate if the current H10-A Work Candidate
Override inspection date has been manually overridden.
Maintenance Foreman Code For proposed maintenance, record the code of the H11 Work Candidate
assistant maintenance manager or foreman
responsible for implementation of the work.
BMS Re-write Phase 2 Conceptual System Design Report 75
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Maintenance Program Year For proposed maintenance, record the tentative H12 Work Candidate
implementation or actual program year of the
maintenance activity.
Main Fracture Critical Group Populate bridge record with the main fracture critical J02 Inventory
group number. This information is transferred from
values entered in C18 on the AC (Structure Data)
screen.
Main Fracture Criticality Populate bridge record with the main fracture criticality J03 Inventory
Ranking Factor ranking factor. This information is transferred from
C18A on the AC (Structure Data) screen.
Total Main Criticality Ranking Record the sum of the main fracture criticality ranking J04 Inventory
Factor factors for a bridge.
Approach Fracture Critical Populate with the approach fracture critical group J06 Inventory
Group number. This information is transferred from C18A on
the AC (Structure Data) screen.
Approach Fracture Criticality Populate with the approach fracture criticality ranking J07 Inventory
Ranking Factor factor. This information is transferred from C18A on
the AC (Structure Data) screen.
Total Approach Criticality Record the sum of the approach failure criticality J08 Inventory
Ranking Factor ranking factor.
Controlling Fracture Critical Record the location of the controlling Fracture Critical J09 Inventory
Member Member and detail.
Fracture Critical Member Record the fracture critical member. J10 Inventory
Fracture Critical Detail Record the fracture critical member detail. J11 Inventory
Fracture Critical Fatigue Record the fatigue category of the fracture critical J11-A Inventory
Category detail.
Fracture Critical Member Record the fracture critical member detail condition. J12 Inventory
Condition
Sufficiency Rating - S1 Indicate the structural adequacy and safety component M01 Inventory
of the Sufficiency Rating of the structure.
Sufficiency Rating - S2 Indicate the serviceability and functional obsolescence M02 Inventory
component of the Sufficiency Rating of the structure.
Sufficiency Rating - S3 Indicate the essentiality for public use component of M03 Inventory
the Sufficiency Rating of the structure.
Sufficiency Rating - S4 Indicate the special reductions component of the M04 Inventory
Sufficiency Rating of the structure.
Load Capacity Deficiency Record the number of deficiency points assigned to the M09 Inspection
bridge or culvert based on load capacity.
Deck Deficiency Record the number of deficiency points assigned to the M10 Inspection
bridge based on deck deficiency.
Superstructure Deficiency Record the number of deficiency points assigned to the M11 Inventory
bridge based on superstructure deficiency.
Substructure Deficiency Record the number of deficiency points assigned to the M12 Inspection
bridge based on substructure deficiency.
Culvert Deficiency Record the number of deficiency points based on M13 Inspection
culvert deficiency.
BMS Re-write Phase 2 Conceptual System Design Report 76
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Width Deficiency Record the number of deficiency points assigned to the M14 Inspection
bridge based on width deficiency.
Remaining Life Deficiency Record the number of deficiency points assigned to the M15 Inspection
bridge or culvert based on remaining life.
Vertical Clearance Record the number of deficiency points assigned to the M16 Inspection
Deficiency bridge based on vertical clearance deficiency.
Approach Alignment Record the number of deficiency points assigned to the M17 Inspection
Deficiency bridge or culvert based on approach alignment
deficiency.
Vertical Underclearance Record the number of deficiency points assigned to the M18 Inspection
Deficiency bridge based on vertical underclearance deficiency.
Waterway Deficiency Record the number of deficiency points assigned to the M19 Inspection
bridge or culvert based on waterway adequacy
deficiency.
Total Raw Deficiency Points Record the total number of raw deficiency points prior M20 Inspection
to application of any final multipliers or limiting values.
Total Factored Deficiency Indicate the total factored deficiency points M21 Inspection
Points (automatically computed by the system).
Total Deficiency Rating Indicate the deficiency point rating of the structure M22 Inspection
(automatically computed by the system).
TDR Estimated Indicator Indicate that the total deficiency rating has been M23 Inspection
estimated based on default values.
TDR County Rank Record a number assigned to each bridge or culvert in M25 Inspection
the County based on a ranking (descending) of
deficiency ratings (automatically computed by the
system).
TDR District Rank Record a number assigned to each bridge or culvert in M26 Inspection
the District based on a ranking (descending) of
deficiency ratings (automatically computed by the
system).
TDR Statewide Rank Record a number assigned to each bridge or culvert in M27 Inspection
the State based on a ranking (descending) of
deficiency ratings (automatically computed by the
system).
Cost Index - ADT Identify cost per average daily traffic (ADT) indices M28 Inspection
showing rehabilitation and replacement cost divided by
ADT (automatically computed by the system).
Cost Index - TDRR Identify cost per total deficiency rating reduction M29 Inspection
(TDRR) indices showing rehabilitation and replacement
cost divided by TDRR (automatically computed by the
system).
Cost Index - ADT/TDRR Identify cost per ADT per TDRR indices showing M30 Inspection
rehabilitation and replacement cost divided by ADT
divided by TDRR (automatically computed by the
system).
BMS Re-write Phase 2 Conceptual System Design Report 77
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Cost Index - LL/ADT Identify cost per lane length (LL) by ADT indices M31 Inspection
showing rehabilitation and replacement cost divided by
LL divided by ADT (automatically computed by the
system).
Cost Index - LL/TDRR Identify cost per lane length (LL) by TDRR indices M32 Inspection
showing rehabilitation and replacement cost divided by
LL divided by TDRR (automatically computed by the
system).
Cost Index - LL/ADT/TDRR Identify cost per lane length (LL) per ADT per TDRR M33 Inspection
indices showing rehabilitation and replacement cost
divided by LL divided by ADT divided by TDRR
(automatically computed by the system).
Total Maintenance Identify the total maintenance deficiency points M34 Inspection
Deficiency Points assigned to the bridge (automatically computed by the
system).
MDR Estimated Indicator Indicate if the total maintenance deficiency is or is not M35 Inspection
up to date (automatically computed by the system).
MDR County Rank Indicate the County ranking of the structure based on M36 Inspection
its maintenance deficiency point assignment
(automatically computed by the system).
MDR District Rank Indicate the District ranking of the structure based on M37 Inspection
its maintenance deficiency point assignment
(automatically computed by the system).
Construction Project Id Identify the construction project by District, County and O02 Work Candidate
Contract number.
MPMS Number Record the Project Management System (PMS) O03 Work Candidate
number or MPMS number.
State Project Number Record the state project number. O04 Work Candidate
12-year Program Indicator Record the 12-year program indicator in the MPMS O07 Work Candidate
system by project phase (design, ROW, const) and 1st,
2nd or 3rd 4 years.
Bridge Bill Indicator Indicate if a project phase is included in a Bridge Bill O09 Project
Capital Budget.
Contract Let Date Record the actual date of construction project contract O10 Project
letting.
Contract Award Date Record the actual date of construction project contract O11 Project
award.
Contract NTP Date Record the actual date of the contractor’s notice to O12 Project
proceed.
Date Opened to Traffic Record the actual date that the improved structure was O14 Work Candidate
opened to traffic.
Final Certification Date Record the actual date of the final certification of work. O15 Project
Federal Aid Project Number Indicate the federal aid project number for the bridge O18 Project
improvement project.
Roadway Location Capture the location of the roadway in relation to the R01 Inventory
bridge (County/SR/Segment/Offset).
BMS Re-write Phase 2 Conceptual System Design Report 78
System Architecture
BMS Re-write Phase 2
New or Pontis Data
Field Name Field Description Exist Category
Roadway Federal Aid Status Identify the Federal Aid status for roadways on and R09 Inventory
under the structure.
Total Sign Area Record the total area (sq ft) of signs on the sign S05 Inventory
structure.
Number of Signs Indicate the number of signs displayed on the sign S13 Inventory
structure.
Sign Total Height Record the height of the highest column of the sign S19 Inventory
structure.
Sign Median Width Record the width of median located under an overhead S21-A Inventory
sign structure.
Minimum Retaining Wall Record the actual minimum retaining wall height. T04 Inventory
Height
Maximum Retaining Wall Record the actual maximum retaining wall height. T05 Inventory
Height
Retaining Wall Total Length Record the actual total overall length of the retaining T06 Inventory
wall.
Retaining Wall Total Area Record the total area of the retaining wall in sq ft. T07 Inventory
Retaining Wall Use Type Describe the use of the retaining wall (8 choices T10 Inventory
provided).
Backfill Material Describe the type of backfill material used (11 choices). T11 Inventory
Backfill Slope Type Record the slope of the backfill behind the retaining T12 Inventory
wall.
Stream Bed Material Correlate the stream bed material (native or paved) W07 Inspection
with its potential for general scour.
Observed Scour Depth Record the observed scour depth at the time of the W11-C Inspection
inspection at a substructure unit.
100-year Flood Calculated Indicate the 100-year flood calculated scour depth at W11-D Inventory
Scour Depth specific pier, abutment, culvert, and wingwall sites.
500-year Flood Calculated Indicate the 500-year flood calculated scour depth at W11-E Inventory
Scour Depth specific pier, abutment, culvert, and wingwall sites.
Underwater Inspection Record the number of units of the bridge that had an W14 Inspection
Number of Units underwater inspection. A unit can be a pier, abutment,
or culvert.
Underwater Inspection Indicate which agency hired the consultant to perform W17 Inspection
Consultant the scour and underwater inspection.
BMS Re-write Phase 2 Conceptual System Design Report 79
Risks and Controls
BMS Re-write Phase 2
3. Risks and Controls
3.1 Overview
Because of the importance of BMS and the criticality of the information that BMS provides it is
crucial that effective controls be established to help ensure that the new Pontis-based BMS
achieves PENNDOT’s objectives in terms of security and the appropriate access of data.
3.2 System Security
According to the published Network Security Policy for the Commonwealth Office of
Administration / Office of Information Technology (OA/OIT), all multi-user systems must employ
"unique userids and passwords and user privilege restriction mechanisms" (OIT Information
Technology Bulletin for Security, Privacy and Business Continuity Planning, section I.6.2).
Other application-level security items addressed by the policy include the following:
• All users must have unique userids and passwords - the use of shared passwords is
prohibited.
• Users must not use passwords that are identical (or substantially similar) to passwords
they have previously used. Where possible, software must block and prevent password
reuse.
• Incorrect password attempts must be limited - after three (3) consecutive, unsuccessful
attempts to enter a password, the associated user id must be suspended until reset by a
system administrator.
• If there is no activity on a system for a period not to exceed fifteen minutes, the system
must automatically blank the screen and suspend the session.
The security processes related to the new Pontis-based BMS must support the OIT and
PENNDOT standard security policies while addressing security from three different perspectives
- access to the Pontis client application for PENNDOT users, access to the BMS web
application for PENNDOT and external users, and access to specific structure information.
3.2.1 Access to the Pontis Client
The base Pontis application supports some of the requirements described above. For example,
all users can be assigned unique userids. However, Pontis itself allows unlimited login failures
and offers no functionality to control the format and use of passwords.
Although the user logs into Pontis with a single signon, Pontis security actually occurs at two
levels. The first level is the Pontis application itself. A user must be defined within the Pontis
user tables in order to access the application. The second level is the database connection.
The user must be authorized to connect and perform actions against the BMS Oracle database.
The userid defined for the user in Pontis must match the userid defined for the Oracle database.
The user's password is only used for connection to the Oracle database; it is not stored within
Pontis (except as an encrypted variable while the user is logged in) and therefore no password
synchronization is required between the Pontis application and the Oracle database.
When the user logs into the Pontis client application using their userid and password, the
application first attempts to establish a database connection. If the supplied userid and
BMS Re-write Phase 2 Conceptual System Design Report 80
Risks and Controls
BMS Re-write Phase 2
password cannot be used to establish a valid connection to the database, the login is
unsuccessful and the user is presented with an error message. If the database connection is
successful, Pontis then determines whether the user is defined within the Pontis User and User
Roles tables. If the user is not found or is found but does not have the necessary permission to
login, they are presented with an error message and the login is unsuccessful. The base Pontis
application requires tight synchronization between the Pontis application and the Oracle
database. Functional roles assigned to the user within Pontis require that corresponding
database privileges be assigned within Oracle. For example, a user assigned with the Delete
Bridge permission within Pontis will see the Remove button active on the Pontis Inspection
Desktop, allowing the user to attempt to delete structures. However, that same user must also
be granted the Delete privilege on the corresponding tables within the Oracle database in order
for a delete action to be successful. If not assigned the proper database privileges, the user is
presented with an error message and the action does not succeed, even though the user was
granted the required permission within Pontis.
Based upon the above description, there are three basic issues with the security for the Pontis
client application:
• Access to Pontis - users defined within the Pontis User table
• Access to Pontis functionality - users assigned permissions through the Pontis User
Roles table
• Access to the BMS database - users defined and assigned privileges to the database
within Oracle while not allowing the user to change the database outside of Pontis (e.g.,
through Microsoft Access or some other tool)
Many, if not all, of the security policies required by PENNDOT for the management of user
passwords and other security-related issues can be met using standard Oracle security
capabilities. In addition, the management of users within Oracle can be simplified using Oracle
roles and other capabilities available from the Oracle Enterprise Manager, including possible
linkages to PENNDOT Windows domain user security. Since these Oracle policies apply
beyond the BMS application, however, they must be established and confirmed by the
PENNDOT BIS DBA group.
Ultimately, the use of Oracle security capabilities to implement the security policies will also help
to provide the other levels of database control required for the BMS database - specifically, to
restrict or prohibit updates to the BMS data from other applications or users outside of Pontis. A
major complication of relying upon Oracle capabilities for meeting security requirements is the
required level of synchronization of user information and permissions/privileges with the Pontis
application. Ensuring that a particular user is granted adequate database privileges matching
their Pontis permissions could be a time consuming and tedious process.
A more common approach to manage the Oracle database security is to create a number of
standard “BMS User” roles that would include all of the database privileges required for each of
the limited number of BMS user types (e.g., District Bridge Engineer, Bridge Inspector). Each
Pontis user would then be associated with one of these defined roles. The Pontis application
would continue provide the functional and data access restrictions for a given user.
However, the problem with this approach is that Oracle cannot differentiate between a database
connection made from Pontis and a database connection made from other software on the
client workstation (e.g., MS Access). This introduces an exposure that someone could connect
BMS Re-write Phase 2 Conceptual System Design Report 81
Risks and Controls
BMS Re-write Phase 2
to the Pontis database and issue indiscriminate updates apart from the programmed logic of
Pontis. One alternative for eliminating this exposure is to create a Pontis “launcher” program
that creates a database connection before invoking Pontis. Using a launcher program, users
would not invoke Pontis directly - instead, users invoke the launcher program to start Pontis (the
launcher program could be made "invisible", so that the user thinks they're invoking Pontis
directly rather than the launcher program). When a user enters a password into the launcher
program, the password is converted (using an encryption algorithm) into a "hidden" password
before being passed to Oracle. The password associated with the user within Oracle is actually
the encrypted password. Thus, the user does not know the real password, which prevents the
user from creating a database connection from any other program (including Pontis, apart from
the launcher program). A separate utility screen would be required for the DBA group and/or
the information security group, so that all password maintenance would be performed using the
same password modification logic. The utility screen would also provide the necessary
synchronization between the Pontis permissions and the corresponding database privileges,
significantly reducing DBA group involvement in BMS user administration.
The Florida Department of Transportation (FDOT) created a similar launcher program for their
implementation of Pontis which could be used as the basis for the PENNDOT program.
3.2.2 Access to the BMS Web Application
The new Pontis-based BMS also requires that external users have access to BMS for viewing
and maintaining structure-related data. For example, consulting firms performing bridge
inspections will need to have access to BMS for submitting and maintaining inspection data for
structures they are assigned to inspect (e.g., upload and download EDC data, create and edit
manual inspection data). The BMS security requirements for external users, including the need
to uphold OIT and PENNDOT security policies, as well as the need for external businesses to
administer their own users (to reduce PENNDOT help desk workload), are similar to the
requirements for non-PENNDOT Business Partners within ECMS. In addition, many local
bridge owners and inspection consulting firms are already defined (or need to be defined) as
ECMS Business Partners. Therefore, the ECMS Business Partner Registration subsystem
represents a possible alternative for controlling access to the BMS web application. The
Business Partner Registration functionality includes the following:
• Business Partner Registration creates one BP Administration userid. This userid must
be used to manage that organization's users.
• The BP Administration user has access only to security and Business Partner
information. “Named” userids must be created to gain access to other ECMS (and BMS)
Business Partner functions.
• BP Administrator users can Create, Modify, or Delete other users for their company, and
reset passwords for their company’s users.
Under this scenario, individual business partners, representing all possible external users
including inspection consultants, local bridge owners and other organizations such as FHWA,
will use ECMS to set-up their users, identifying security groups associated with each user
corresponding to the roles they would require within BMS. Once complete, user data will be
copied into the necessary user tables within the BMS Oracle database and the necessary users
will be created/updated and assigned privileges within the Oracle database. Common routines
that are shared with the Pontis launcher and user administration programs described in the prior
section will be used to provide this functionality.
BMS Re-write Phase 2 Conceptual System Design Report 82
Risks and Controls
BMS Re-write Phase 2
The following table provides a high-level summary of the user groups required for the new
Pontis-based BMS, and indicates whether the groups are already defined within ECMS.
Group BMS User Type Existing ECMS BP Definition?
Municipality & Other Local Governments Local Bridge • $ECMSBP Municipality Approver
Owner • $ECMSBP Municipality General User
• $ECMSBP Municipality Legal
Other State Agencies within BMS: Local Bridge None
• PTC – Pennsylvania Turnpike Owner
Commission
• DRC – Delaware River Joint Toll Bridge
Commission
• DPA – Delaware River Port Authority
• DER – DCNR PA Dept of Conservation
and Natural Resources
• BBC – Burlington County Bridge
Commission
• DGS – PA Dept of General Services
• DOH – PA Dept of Health
• DPW – PA Dept of Public Welfare
• PSU – Penn State
• NJS – NJ DOT
• NYS – NYDOT
• OSA – Other State Agency
• OPA – Other private agency
• OTH – Other agency
FHWA Local Bridge • $ECMSBP FHWA Approver
Owner • $ECMSBP FHWA General User
Consultants performing inspections for Inspector • $ECMSBP Data Entry
PENNDOT owned structures • $ECMSBP Financial Officer
• $ECMSBP Principal
• $ECMSBP Project Manager
Consultants performing inspections for Inspector None
non-PENNDOT owned structures
Planning Partners (don’t own any bridges, Planning Partner • $MPMSBP Partner
but want data about them)
3.2.3 Access to Structure Data
The new Pontis-based BMS must provide the ability to limit the structures to which a user has
access, based upon criteria such as the user's organization or location. For example, local
bridge owners should only be able to maintain and view information for the bridges that they
own, planning partners should only be able to view information for structures within their
planning area, and non-PENNDOT consultant inspectors should only have access to the
inspection data for structures they are assigned to inspect. Based upon these examples, there
are a number of possible criteria that may be used to limit access to structure information,
including owner code, county, district, location, inspection agency, etc. There is also a
BMS Re-write Phase 2 Conceptual System Design Report 83
Risks and Controls
BMS Re-write Phase 2
correlation to the user's roles within the new BMS. For example, only authorized bridge
inspectors for a business partner may be given authority to view structure inspection
information.
Due to the relationship between a user and the structures they are authorized to access, the
security administration functionality of the new BMS must also incorporate the requirements for
structure-level access restrictions. Internal PENNDOT users accessing the Pontis client
application will be limited in functional authority through the use of Pontis user roles (e.g., only
inspectors may be allowed to update inspection information), but will not have restrictions
placed upon the structures they are authorized to view - PENNDOT BMS users will be able to
access the data for all structures. For non-PENNDOT users, access to the new BMS will occur
via the BMS web application, and therefore it must incorporate the necessary logic for limiting
information access. Since each external user will be linked to a particular Business Partner
Identifier, all of the criteria for limiting structure access must eventually tie back to the user's
Business Partner Id. The following is a summary of the external user types required for the new
BMS, and the criteria to be used to limit structure access:
BMS User Type Purpose
Local Bridge Owner This category includes other state and local agencies, municipalities and
outside companies (e.g., railroad).
Access to structure information for local bridge owners will be limited based
upon the Owner Code for the structure. Owner Code values must be cross-
referenced to the corresponding Business Partner Ids for those owners - in
other words, the new BMS must maintain a link between each Owner Code
and one or more associated Business Partner Ids to define the external
users that can access structures for that Owner Code.
Planning Partner Access to structure information for planning partners will be based upon
criteria defined during the BMS detailed design phase. Possible criteria
include location (e.g., counties or districts linked to a defined planning
partner area) and a structure-level planning partner id field. When a user's
Business Partner Id is identified as a planning partner, the new BMS must
restrict the structures to those that the user has access based upon the
defined criteria. If a structure-level planning partner id field is defined, the
new BMS must maintain a link between each planning partner id and the
one or more Business Partner Ids for that planning partner.
Municipality Access to structure information for those Business Partners defined as
municipalities will be limited based upon the Municipality code for the
structure. The new BMS must maintain a link between each Municipality
code value and the one or more Business Partner Ids for that municipality.
FHWA Access to structure information for FHWA users will not be restricted. Like
PENNDOT users, FHWA users will be able to view data for all structures.
Consultant Inspector Access to structure information for consultant Business Partners will be
limited to those structures to which they are specifically assigned to inspect.
When assigned to inspect a structure, the inspection consultant's Business
Partner Id will be linked to the structure. This linkage can be established
several ways:
• Manually set by an administrator. For example, a PENNDOT inspection
manager assigns each applicable structure to an inspection consultant
through the inspection screens within the Pontis client application.
• Programmatically set, such as an ECMS interface. ECMS is used to
create all of the consultant agreements that are established for consultant
inspectors, including the identification of specific bridges to which the
BMS Re-write Phase 2 Conceptual System Design Report 84
Risks and Controls
BMS Re-write Phase 2
BMS User Type Purpose
consultant is assigned. However, the bridge links are currently maintained
in a free-form document that cannot be used to establish the links
programmatically. Changes would be required to ECMS to facilitate this
method.
• Use a custom built screen that allows a PENNDOT user to specify a
business partner and select all structures to be inspected by the business
partner within a given timeframe.
3.3 Risks and Controls
In general, to satisfy business objectives, there are specific requirements for quality information.
These requirements include the following:
• Effectiveness deals with information being relevant and pertinent to the business
process as well as being delivered in a timely, correct, consistent and usable manner;
• Efficiency concerns the provision of information through the optimal use of resources;
• Confidentiality concerns the protection of sensitive information from unauthorized
disclosure;
• Integrity relates to the accuracy and completeness of information as well as to its validity
in accordance with business values and expectations;
• Availability relates to information being available when required by business processes
now and in the future. It also concerns the safeguarding of necessary resources and
associated capabilities;
• Compliance deals with complying with those laws, policies, regulations and contractual
arrangements to which the business process is subject; and
• Reliability of information relates to the provision of appropriate information for
management to operate and to exercise its financial and compliance reporting
responsibilities.
Providing effective controls ensures the quality of information. A control is defined as:
The policies, procedures, practices and organizational structures designed to provide
reasonable assurance that business objectives will be achieved and that undesired events
will be prevented or detected and corrected.
Risks are defined as:
Those undesired events that may cause BMS to not meet its objectives.
Risks can be grouped into the following categories: data origination risks, data input risks, data
processing risks and data output risks. The following table identifies the relevant risks the new
BMS faces and the controls that should be established to prevent, detect or recover from the
risk.
BMS Re-write Phase 2 Conceptual System Design Report 85
Risks and Controls
BMS Re-write Phase 2
Risk Control
Data Origination Risks
Unauthorized personnel A manual process should be in place to verify that an authorized
submit structure person has manually submitted structure inspection data.
inspection results via
paper or some other
mode outside an eForms
electronic submission.
Unauthorized personnel A manual process should be in place to verify that an authorized
submit structure inventory person has manually submitted structure-related information for
information via paper or entry into BMS by PENNDOT staff.
some other mode for
PENNDOT personnel to
enter.
Data Input Risks
Unauthorized access to A userid and password will be used to verify security access to
system BMS, information for both PENNDOT and external users.
Internal Users: Internal users must complete a BMS userid request
form that must then be approved by the BMS coordinator within the
PENNDOT Bridge Quality Assurance Division (BQAD). The Pontis
security administrator will then set user access to BMS based on
the approved information on the request form. Manual verification
should be performed to confirm that the form has been approved by
the appropriate party.
External Users: The security administrator for each external
business partner authorized to access BMS will maintain userids
and passwords for employees of their particular organization.
Unauthorized access to As noted in the prior section, the new BMS will allow administrators
specific bridge data to set access to bridge information at the bridge level. Access for
internal PENNDOT users will be controlled based upon the
organization to which they are assigned (e.g., District bridge staff,
BQAD, Central Office Program Center, etc.) - the user's
organization is included on the BMS userid request form and should
be confirmed before the form is approved by the BMS coordinator.
Access for external users will be controlled based upon bridge data
maintained by PENNDOT staff - BMS will limit external user access
to specific bridge data programmatically. For example:
• Local bridge owners will be able to view/update limited data for
only the bridges they own, defined by an Owner field
maintained by PENNDOT.
BMS Re-write Phase 2 Conceptual System Design Report 86
Risks and Controls
BMS Re-write Phase 2
Risk Control
• Consultant Inspectors will be able to view specific data and
update inspection data for only the bridges that have been
assigned to them for inspection, defined by a Consultant
Inspector field maintained by PENNDOT.
• Planning Partners can view specific data only for the bridges
within their planning area, defined by a Planning Partner or
County field maintained by PENNDOT.
Unauthorized modification The userid and password and the privileges assigned to the user
of bridge inspection will restrict access to modify bridge inspection results only to
results authorized users.
Electronic submission of The userid and password and the privileges assigned to the user,
bridge inspection results as well as the structure information that identifies the responsible
by unauthorized inspector organization (e.g., PENNDOT District, consultant
personnel business partner id), will restrict access for the submission of bridge
inspection results only to authorized users.
Data Processing Risks
Incorrect data Edit checks will be in place to reduce the number of errors related to
the entry of bad data by a user. Edit checks will also be performed
by batch programs as appropriate to prevent incorrect data from
being saved in the database (e.g., through an interface program or
batch calculation); batch program edit failures will be listed in
reports and/or forwarded to an appropriate user for disposition.
Data Output Risks
Predictive modeling PENNDOT should involve experienced bridge personnel in setting
results forecast bridge the maintenance, preservation and improvement policies to be used
conditions and remaining in the configuration of the Pontis and PENNDOT Bridge Modeling
needs outside tools. Once element level data is collected, a calibration effort
expectations or defined should be performed, similar to Task 2 of the BMS Re-write Phase
tolerances 2 project, to confirm the level of accuracy and reasonability of the
policy configuration. When utilizing the results of predictive
modeling, separate output from the Pontis and PENNDOT Bridge
Modeling systems should be compared to provide alternative views
of future needs. Also, the recommended maintenance and
improvement actions identified by the models should always be
reviewed and approved by a qualified PENNDOT bridge engineer
prior to actually scheduling the actions.
BMS Re-write Phase 2 Conceptual System Design Report 87
Infrastructure Requirements
BMS Re-write Phase 2
4. Infrastructure Requirements
4.1 Overview
The following is a conceptual technical diagram for the Pontis Level E solution, with the shaded
areas representing new hardware/software components in comparison to the current PENNDOT
environment:
Other application databases;
Printer e.g.,
Plotter
ECMS
MPMS DB2
Database
Scanner District Office
EDMS Server
District Office OS/390
LAN
BMS Electronic Data BMS Mainframe Application
Collector Integration with existing systems
Remote application
Synchronize on LAN
St
t
at
EDC DB2
e
BMS Oracle Database
W
Database
i de
SMS Gateway Pontis-defined
W
BMS District User Server Oracle
AN
A
Database
PENNDOT extensions
Pontis Fat-client application
Browser-based application Bridge Engineer
Workstation ORACLE
Central Office
Server
LAN
BMS Central Office User BMS Server Application
Pontis Fat-client application Batch processes
Browser- based application Custom development
Application
BQAD/BOD
EDMS Server
Workstation
Crystal Servers
Enterprise
Server
EDMS
Storage
New Servers
EDC
Firewall
BMS Web Application Server
WebSphere/Java
Printer Serving bot h internal and external users
PENNDOT DMZ BMS
Web
Server
Scanner
Internet Crystal Enterprise Server
Internet
Replicat ed from inside the firewall
Crystal Subset of reports for external users
Industr y User Enterprise
Firewall
Internet-connected Commonwealth Server
Workstation SMTP Server
As depicted in the diagram, the infrastructure requirements for the new Pontis-based BMS will
be based significantly upon technical elements that have already been implemented to support
other PENNDOT systems, such as the database gateway servers, EDMS servers, SMS
servers, etc. However, the new BMS does require some additional resources that have not yet
been implemented, such as an Oracle database server and a Crystal Enterprise server for
external users.
The following sections describe the overall infrastructure requirements for the new BMS, and
describe in detail the new technical elements that the system requires. The descriptions
primarily address technical elements required for the production Pontis-based BMS.
Corresponding development, test and training environments are also required to support the
implementation of the new BMS; the technical element requirements for each of these individual
environments are not separately described. However, the overall requirements for hardware
BMS Re-write Phase 2 Conceptual System Design Report 88
Infrastructure Requirements
BMS Re-write Phase 2
and software for all four environments are included within section 6 - Hardware and Software
Cost Estimates.
4.2 Data Volumes
As noted in previous sections, the database for the new Pontis-based BMS is built upon the
Pontis database structure, with additional fields and tables established as needed to meet the
requirements of the new BMS. The production database supporting the day-to-day data
maintenance needs of BMS will be created within the server-based Oracle Database
Management System (DBMS). An additional mainframe DB2 copy of the database will be
created to support reporting and provide the basis for the interfaces to other mainframe-based
PENNDOT systems.
The following are the assumptions upon which the estimated size of the new Pontis-based BMS
database was based. The database size estimate is made as of the third year of production
implementation for the new BMS, which is the point at which the element definitions for all
structures will be complete and all structures will have at least one element-level inspection:
Quantity.
Data Item Type of Items Notes
Structures 60708 Includes the count of structures in the current BMS database,
an estimate of new structures added (e.g., noise walls, high
mast lights), and the inclusion of the approximately 19,000
municipal structures.
Inspections per Bridge 8 Includes at least one new inspection and the average number
of inspections converted from the current BMS.
Elements per Bridge 8
Structure Units per Bridge 2
Roadways per Bridge 2 On and Under.
Inspection Work Candidates 5
per Bridge
Scenarios (max number) 12 One per district plus central office.
Years per Scenario 20
Element Definitions 150
Users 600 Internal and external users.
Programs 12 No analogous entity in the current BMS.
Years per Program 4
Projects per Program 50
Work Items per Project 5
Funding Source 5
Simulation Rule Sets 12 One per district plus central office.
Rules per Set 15
Flex Actions 20
Agency Policy Sets 1 Assumes that all districts are required to use the same policy
set.
Rules per Agency Policy 20
BMS Re-write Phase 2 Conceptual System Design Report 89
Infrastructure Requirements
BMS Re-write Phase 2
Quantity.
Data Item Type of Items Notes
Budget Sets 2
Improvement Policy Sets 1
Formulas 10
Using these assumptions, the estimated size of the new Pontis-based production BMS
database is approximately 81,600 Megabytes (MB), or 81.6 Gigabytes (GB).
This estimate represents the amount of the data to be stored in the database, normalized as
character data. However, the estimate also includes some physical characteristics of the
database such as indexes, percentage of free space and number of extents. This estimate
does not include structure-related electronic documents and images that will be stored within
EDMS, which are difficult to estimate due to dependencies on the physical characteristics of the
item being stored, such as file format and document type.
The estimated database size is driven primarily by the number of scenarios (predictive models)
to be stored within the production database. As noted in the table above, for the purposes of
this estimate the project team assumed that the production database would always contain a
scenario for each district and a statewide scenario, for a total of 12. The Pontis client
application provides the option of using a standalone workstation-based database, which in turn
could be used for predictive modeling and therefore significantly reduce the overall size of the
production database. If the number of scenarios in the database is reduced to one 20-year
scenario, the estimated size of the Pontis-based production BMS database is reduced to
approximately 12,000 MB, or 12 GB. If no scenarios are stored in the production database, the
database size is reduced to approximately 6,200 MB, or 6.2 GB. One major penalty for not
including the scenarios in the production database is that it would significantly reduce the ability
for users to query or run reports against the scenario data.
4.3 Network Impacts
The network impact of the new Pontis-based BMS was estimated based upon row lengths for
applicable tables within the Pontis database structures, the data item assumptions included
within the Data Volumes section above and current transaction summary information from the
current BMS. Two basic types of data maintenance and viewing activity were estimated -
structure and planning/programming. By estimating based upon these two activity categories,
corresponding tables within the Pontis database can be directly related to a projected user
transaction and therefore an estimate of the required network bandwidth can be calculated.
Within Pontis, inspection data is stored within structure-related tables and therefore inspection
data maintenance and viewing activity is included within the structure data category.
To provide an estimate for the number of user transactions in a given time period, the
transaction summary from the current BMS was obtained and the corresponding BMS
transactions were broken into the structure (including inspection) and planning/programming
categories. For the purposes of the estimate, no distinction was made between Add/Insert,
Update or View activity - it was assumed that each transaction requires approximately the same
amount of data transmission across the network. The current BMS transaction data is as
follows:
BMS Re-write Phase 2 Conceptual System Design Report 90
Infrastructure Requirements
BMS Re-write Phase 2
Structure Activity Planning/Programming Activity
Total Daily Total Daily
BMS Screen Transactions BMS Screen Transactions
AA - General 205 AF - Proposed Improvement 84
AB - Features Intersected 170 AG - Repair & Paint 2
AC - Structure 131 AH - Proposed Maintenance 224
AD - Utility, Hydro & Posting 59 AO - PI/PMS Activity 1
AE - Inspection 732 AN - Completed Maintenance 7
AJ - Fracture Critical 8 Total 318
PA/PB/PC - APRAS Permit 202
AL - Narrative 27
AM - Condition Rating 7
AR - State Roadway 45
AS/AT - Sign and Ret Wall 14
AW - Underwater Inspection 172
AX - Seach 50
Total 1822
To account for the fact that the new BMS will be available to more (external) users, the daily
transaction counts were increased by 30% to 2369 and 413, respectively.
The number of bytes associated with each transaction were estimated by linking specific Pontis
database tables to the transaction, and then calculating an expected data size by multiplying the
corresponding row length by the number of expected records. For a structure activity, the
estimated data for a transaction was estimated as follows:
Est Number Bytes per
Table Name of Records Record Total Bytes
BRIDGE 1 1570 1570
ROADWAY 2 853 1706
INSP_WCAND 5 688 3440
USERRWAY 2 75 150
INSPEVNT 1 855 855
USERBRDGE 1 380 380
ELEMINSP 8 933 7464
STRUCTURE_UNIT 2 804 1608
USERSTRUNIT 2 230 460
USERINSP 1 180 180
CICOCNTL 1 247 247
Total 18060
BMS Re-write Phase 2 Conceptual System Design Report 91
Infrastructure Requirements
BMS Re-write Phase 2
For a planning/programming activity, the estimated data for a transaction was estimated as
follows:
Est Number Bytes per
Table Name of Records Record Total Bytes
PROJECTS 1 873 873
PRJ_FUNDSRC 5 537 2685
PRJ_PRJFUND 2 291 582
PRJ_PROGFUND 1 267 267
PRJ_PROGRAMS 1 696 696
PRJ_WITEMS 5 696 3480
USERPROJ 1 233 233
Total 8816
The total daily traffic in terms of BMS data being transmitted across the network can then be
calculated by multiplying the number of transactions for each activity type by the total amount of
data for each transaction. That calculation is as follows:
(2369 structure trx * 18060 bytes) + (413 planning/programming trx * 8816 bytes)
= 42784140bytes + 3641008 bytes = 46425148 or 46.4 MB
This figure includes an estimated 30% increase in the number of transactions due to the use of
the new BMS by external users. Converting this figure to a network measurement of
Megabits/sec yields a network bandwidth requirement of 10.3 Mbits/sec for the new Pontis-
based BMS. Note that this figure represents the maximum network bandwidth required; typical
requirements should be lower because each user transaction may not require the transmission
of complete records (i.e., often only selected fields/columns are included in a data transaction).
4.4 Mainframe Resources
As described in prior sections, the new Pontis-based BMS, while primarily resident on servers,
will require mainframe resources to provide the DB2 BMS reporting database and to meet batch
interface requirements between BMS and other PENNDOT systems such as RMS, MPMS and
ECMS. The current Relational Bridge Inventory Database (RBIDB), the DB2 reporting database
for the current BMS, is approximately 400 MB, which is significantly smaller than the projected
size of the new Pontis-based BMS database. However, the new BMS will eliminate the
corresponding IMS versions of the current BMS database (including reporting and test copies),
approximately 2500 IMS online transactions per day (average), and a significant number of
BMS-related batch programs devoted to the running of reports and other related data extracts in
the current PENNDOT overnight cycle. While the space requirements for the new Pontis-based
BMS database in DB2 will increase, the number of CPU cycles required for BMS will most likely
decrease. Therefore, the expected impact to the PENNDOT mainframe in comparison to the
mainframe resources required for the current BMS is expected to be minimal.
BMS Re-write Phase 2 Conceptual System Design Report 92
Infrastructure Requirements
BMS Re-write Phase 2
4.5 Server Resources
The following is a description for each of the servers to be utilized by the new Pontis-based
BMS. Those servers that represent new servers within the PENNDOT infrastructure specifically
for use by BMS are described in more detail with regards to sizing and configuration. The
server descriptions define the needs of the BMS production environment; similar server
requirements are also needed for the Development, Test and Training environments. Note that
the hardware configurations for the new servers represent typical configurations for the
PENNDOT environment, and can be changed as dictated by PENNDOT BIS.
4.5.1 BMS Production Servers
4.5.1.1 SMS Server
This server is used to deploy application software to one or more workstations attached to the
PENNDOT network, using Microsoft Systems Management Server (SMS) software.
Status: Server is already in place in production.
4.5.1.2 DB2 Gateway Server
This server provides a gateway to the DB2 reporting database on the PENNDOT mainframe,
using DB2 client software. Connections to the DB2 reporting database are required to support
the Crystal Enterprise report servers, as well as ad hoc Crystal Reports users.
Status: Server is already in place in production.
4.5.1.3 EDMS Server(s)
These servers support the production requirements for the PENNDOT EDMS. It is assumed
that BMS will utilize existing EDMS resources for the storage and retrieval of structure-related
electronic documents, and that additional EDMS hardware and/or software resources are not
required to meet the needs of the new BMS.
Status: Server is already in place in production.
4.5.1.4 Crystal Enterprise Server (Internal)
This server is used to provide browser access to reports created using the Crystal Reports tool.
Reports deployed on the Crystal Enterprise server can be executed and viewed using a web
browser, and do not require the user to have the Crystal Reports tool installed on their local
workstation. This particular server supports the reporting needs of internal PENNDOT users,
and therefore is installed inside the PENNDOT firewall. Software currently installed on this
server includes Crystal Enterprise and Microsoft Internet Information Services (IIS); IIS provides
the web server for Crystal Enterprise.
Status: Server is already in place in production.
4.5.1.5 BMS Web Server
This server is used to deploy the BMS web application, supporting the user interface and other
functionality requirements of BMS to both internal PENNDOT and external users. All online
web-based BMS functionality is implemented on this server. Based upon a decision by
PENNDOT BIS, Websphere Enterprise Application Server software will be used for BMS,
providing the ability to support multiple applications on a single Websphere server. Therefore,
BMS Re-write Phase 2 Conceptual System Design Report 93
Infrastructure Requirements
BMS Re-write Phase 2
although labeled as the "BMS Web Server", this server is capable of supporting multiple
applications simultaneously. No BMS data is physically stored on this server.
Status: New
Hardware Summary: Dual (2) Processor Intel Xeon 3.2 GHz or above, 2 GB RAM, 146 GB
or more hard drive in a RAID 5 configuration, DVD-ROM and required network adapters
Primary Software: Windows 2003, IBM Websphere Enterprise Application Server v4.0
4.5.1.6 Oracle Database Server
This server is used to deploy the Oracle RDBMS in support of the production Pontis BMS
database. The Pontis database stored and maintained on this server is the production
database for the new Pontis-based BMS. This server therefore supports the data needs of
internal PENNDOT users accessing the Pontis client application and external users accessing
the BMS web application, although it is assumed that this server will be located inside the
PENNDOT firewall. The Oracle database software used by BMS can support multiple
databases on a single server, and therefore this server is capable of supporting the database
needs of multiple applications simultaneously.
Status: New
Hardware Summary: Quad (4) Processor Intel Xeon 2.8 GHz or above, 4 GB RAM, 500 GB
or more hard drive in a RAID 5 configuration, DVD-ROM and required network adapters
Primary Software: Windows 2003, Oracle Enterprise Server 9i
4.5.1.7 Crystal Enterprise Server (External)
Similar to the Crystal Enterprise Server (Internal) described above, this server is used to provide
browser access to reports created using the Crystal Reports tool. Reports deployed on the
Crystal Enterprise server can be executed and viewed using a web browser, and do not require
the user to have the Crystal Reports tool installed on their local workstation. This particular
server supports the reporting needs of external (non-PENNDOT) users, and therefore is
installed outside the PENNDOT firewall in the DMZ. The reports deployed on this server
represent a subset of reports available to internal PENNDOT users, and the reports restrict data
access such that users are only able to retrieve information for those structures associated with
their agency or company. This is accomplished through the use of user-level filters within the
reports and/or the deployment of reports that do not contain confidential data and therefore do
not require restricted structure data access. The Crystal Enterprise software used by BMS can
support the reporting needs of multiple applications/user communities on a single server, and
therefore this server is capable of supporting reporting needs beyond BMS.
Status: New
Hardware Summary: Dual (2) Processor Intel Xeon 3.2 GHz or above, 2 GB RAM, 146 GB
or more hard drive in a RAID 5 configuration, DVD-ROM and required network adapters
Primary Software: Windows 2003, Crystal Enterprise v9.0, Microsoft IIS (web server for
Crystal Enterprise)
4.5.1.8 BMS Application Server
This server is used to support the batch functionality requirements of BMS, including the nightly
batch cycle and various online BMS services (e.g., supporting BMS/GIS integration). This
BMS Re-write Phase 2 Conceptual System Design Report 94
Infrastructure Requirements
BMS Re-write Phase 2
server could also be used to support other BMS application requirements, such as the use of
Windows Terminal Server (WTS) if required as an alternative to deploying the Pontis client
application via SMS. Since the batch scheduling software for this server has not yet been
identified, and due to the fact that the BMS server-based batch window has not been specifically
defined, this server has been sized to support a significant processing capability. It is therefore
possible that this server is capable of supporting the batch application processing needs of
multiple applications simultaneously.
Status: New
Hardware Summary: Quad (4) Processor Intel Xeon 2.8 GHz or above, 4 GB RAM, 500 GB
or more hard drive in a RAID 5 configuration, DVD-ROM and required network adapters
Primary Software: Windows 2003, Windows Task Scheduler (possible), Windows Terminal
Server (possible)
4.5.2 Development, Test and Training Environments
As noted above, similar servers are required in other environments to support the development,
testing and training needs of the new BMS. In some cases, however, either existing servers in
those environments can be utilized (e.g., Crystal Enterprise development server) or servers can
be consolidated/eliminated in these environments. For example, a separate BMS application
server is likely not required for the Training environment because it is unnecessary to execute a
standalone batch cycle in training. A summary of server requirements for these alternative
environments is as follows:
Pontis Lvl E
Environment Server Type Quantity
Web Server 2
Production
Application Server 2
Web Server 1
Test
Application Server 2
Web Server 1
Development
Application Server 1
Web Server 1
Training
Application Server 1
Total Web 5
Total App 6
Total 11
Note that the Server Type "Web Server" corresponds to the BMS Web Server configuration
described above, and the "Application Server" corresponds to the Oracle Database Server
configuration described above. Some specific details about each of these servers is as follows:
Environment Server Name Description
Development BMS Web Combination BMS web and application server supporting the user
interface and other functionality requirements of BMS. Since the
development environment does not require the same level of
performance as the production BMS web application, it is assumed that
separate BMS Web and BMS Application servers are not required for the
Development environment. (Web Server configuration)
BMS Re-write Phase 2 Conceptual System Design Report 95
Infrastructure Requirements
BMS Re-write Phase 2
Environment Server Name Description
Development Oracle Database Database server for the storage of all BMS data within the Pontis
database structure. (Application Server configuration)
Test BMS Web BMS web server supporting the user interface and other functionality
requirements of BMS. (Web Server configuration)
Test Oracle Database Same as above
Test BMS Application BMS application server supporting the batch functionality requirements
of BMS. (Application Server configuration)
Training BMS Web BMS web server supporting the user interface and other functionality
requirements of BMS. (Web Server configuration)
Training Oracle Database and Combined Oracle Database and BMS Application servers - combined
BMS Application due to the low processing requirements for the BMS Application server
(Combined) in the training environment. (Application Server configuration)
No Crystal Enterprise server requirement is included for the development or test environments.
A development Crystal Enterprise server already exists and can be used for report development
for the new BMS. A test environment Crystal Enterprise server is not required because the
reports themselves are not dependent upon the configuration of the server and therefore reports
that are successfully tested on the development server will run successfully on the production
server (assuming the software versions for the two environments are compatible).
4.6 Workstation Requirements
For internal PENNDOT users, the new Pontis-based BMS will utilize workstations for executing
the Pontis client application and other related application components in the office, and
Electronic Data Collector (EDC) tablet PCs for PENNDOT bridge inspectors in the field.
External users will primarily access BMS through a web-based user interface, although a subset
of external users will also utilize tablet PC EDCs for bridge inspection.
This section documents the recommended and minimum configuration for the PENNDOT
workstations and tablet PCs. The workstation configuration for external users is not included
because it is only dependent upon the use of a web browser (most like Internet Explorer); the
table PC configuration applies to both PENNDOT and external users.
4.6.1 Office Workstations
The requirements listed below comply with the requirements for the use of the Pontis client
application as documented in the Pontis 4.3 User Manual.
4.6.1.1 Hardware
Recommended Minimum
Intel Pentium III, 500+ MHz, 128+ MB Intel Pentium II; 300 MHz, 64 MB RAM
RAM
Hard Drive with 300+ MB free disk space Same as recommended
Microsoft-compatible mouse or other Same as recommended
pointing device
BMS Re-write Phase 2 Conceptual System Design Report 96
Infrastructure Requirements
BMS Re-write Phase 2
Recommended Minimum
CD ROM Same as recommended
Windows compatible laser, inkjet or Same as recommended
standard dot matrix printer
SVGA 15” color monitor (800x600 pixels) Same as recommended
Ethernet NIC Same as recommended
4.6.1.2 Software
The software configuration requirements are:
• Windows NT 4.0, Windows 2000, or Windows XP operating system
• Microsoft Internet Explorer version 5.5 or higher
4.6.2 Electronic Data Collectors
The requirements listed below comply with the requirements for the use of a pen-enabled
application on a tablet PC, which supports both pen and keyboard data entry.
4.6.2.1 Hardware
Recommended Minimum
Intel Pentium M, 1.5 GHz, 64+ MB RAM Transmeta Caruso; 500+ MHz, 51 MB
RAM
Hard Drive with 40+ GB free disk space Same as recommended
Pen-based pointing device Same as recommended
CD ROM Same as recommended
4.6.2.2 Software
The software configuration requirements are:
• Windows XP operating system
• Microsoft Internet Explorer version 5.5 or higher
• PENNDOT eForms EDC software, including a MSDE (SQL Server) runtime database
(no SQL Server license required - distributable Microsoft Desktop Engine)
BMS Re-write Phase 2 Conceptual System Design Report 97
Training Plan
BMS Re-write Phase 2
5. Training Plan
5.1 Overview
The purpose of the Training Plan is to identify the training requirements for end users and
technical personnel for the new BMS. Training for the new Pontis-based BMS will include the
National Highway Institute (NHI) Pontis Bridge Management Course as well as training covering
PENNDOT-specific customizations made to Pontis.
The audience of students for end user training will include BMS users in the Districts and
Central Office. Technical training will be provided for PENNDOT BIS technical support staff.
This Training Plan assumes that the BMS project team will not be providing BMS training to
external business partners.
5.2 End User Training
Training will be provided to approximately 200 PENNDOT end users of BMS. This estimate
represents approximately 15 users from each of the 11 Engineering Districts statewide and
Central Office Bridge Quality Assurance Division (BQAD), as well as Program Center
representatives and PENNDOT BIS technical resources, as required.
End user training will consist of the NHI Pontis Bridge Management Course and PENNDOT-
specific Pontis training to cover customizations made to Pontis to meet the new BMS
requirements. The NHI Pontis Bridge Management Course is designed for bridge program
managers, bridge management engineers, bridge maintenance engineers, bridge inspectors,
and project planning and programming personnel. PENNDOT BIS technical resources will also
attend this training as a foundation for additional technical training.
5.2.1 NHI Pontis Bridge Management Course
The NHI Pontis Bridge Management Course consists of a 2.5-day class, plus a 2-hour session
developed as part of the course to serve as an introduction to the attributes and benefits of the
Pontis program. This introduction is designed for Federal, State and local executives and upper
and mid-level highway agency professionals responsible for an agency's bridge/highway
program. Executives and management officials are encouraged to attend the opening
introduction and overview sessions. Class size ranges from a minimum of 10 to a maximum of
20 students.
The NHI Pontis Bridge Management Course is focused on a description of the Pontis
application, which is designed to assist bridge managers and practitioners in analyzing bridge
data to predict future bridge conditions and needs, determine optimal policies, and recommend
projects and schedules within budget and policy limitations. The course covers:
• Entering and editing inspection data
• Developing a bridge preservation policy
• Performing bridge network level analyses
• Developing bridge projects
• Running Pontis reports
BMS Re-write Phase 2 Conceptual System Design Report 98
Training Plan
BMS Re-write Phase 2
• Refining Pontis results.
The course focuses on an agency's business process steps, key concepts of bridge
management and their application to Pontis, using the software, instructor demonstration
exercises, and practical student exercises. Each participant will receive a participant notebook.
Six laptop computers are furnished by the NHI for use in the training course, each with the
Pontis application installed and accessing a sample training database.
The objectives of the NHI Pontis Bridge Management Course are to have participants of the
course be able to:
• Use Pontis to support bridge management
• View, enter and edit bridge inspection and inventory data
• Develop, update, optimize and interpret a preservation policy
• Enter program simulation inputs, run network analyses and review results
• Create and rank bridge projects
• View and interpret Pontis results
• Generate and interpret reports
• Customize Pontis to support agency business practices
As referenced above, the estimated 200 PENNDOT end users will attend the 2.5-day NHI
Pontis Bridge Management Course. The total time commitment for NHI training of the
estimated 200 end users is approximately 3800 hours.
5.2.2 PENNDOT Pontis Customization Course
Training for the PENNDOT Customizations will cover the extensions to the Pontis user interface
that will be made throughout all functional interfaces. Additional PENNDOT Customization
training will include information on new capabilities such as:
• Planning – Predicting future performance measures given a budget and facilitate
investment trade-off analyses between bridges and other assets
• Programming – Generate candidate project and maintenance activity lists
• Maintenance integration – Automatic updates for maintenance info including cost and
synchronization with maintenance system activities
• GIS integration – Using maps to plot planned maintenance work and to otherwise
analyze BMS information,
• EDMS integration – View stored electronic documents within BMS, such as bridge plans
and inspection photos
• eForms - Training for the new version of eForms and the use of EDCs
The estimated length of the PENNDOT Customization course is 2 days. Class size will be
similar to the NHI Pontis Bridge Management Course, ranging from a minimum of 10 to a
maximum of 20 students per instructor. This will necessitate 10 – 20 classes. Multiple
instructors can be provided to conduct more than one session simultaneously. The total time
commitment for customization training of the estimated 200 end users is 3000 hours.
BMS Re-write Phase 2 Conceptual System Design Report 99
Training Plan
BMS Re-write Phase 2
The overall total training time for the estimated 200 PENNDOT end users attending the 2.5-day
NHI Pontis Bridge Management course and the 2-day PENNDOT Customization course is 6800
hours (34 hours x 200 students).
5.3 Technical Training
Technical support staff will receive the same training as the end users, as described above. In
addition, they will need training in development tools for the maintenance and operation of the
new BMS, including:
• Java/WebSphere
• Oracle database support training including Oracle SQL training and Oracle DBA training
• PowerBuilder
• VisualBasic.NET
• Crystal Reports/Crystal Enterprise
Application development training will consist of PENNDOT BIS staff attending formal or self-
study classes for the new technologies being introduced and development tools being used.
This training must be obtained outside of the BMS project, most likely through classes available
from the individual tool vendor firms. BIS staff will also actively participate in development and
implementation activities in conjunction with the BMS project team to acquire practical
experience with these technologies and tools and to gain experience with the various
components of the new Pontis-based BMS.
BMS Re-write Phase 2 Conceptual System Design Report 100
Hardware and Software Cost Estimates
BMS Re-write Phase 2
6. Hardware and Software Cost Estimates
6.1 Overview
The purpose of this section is to document the hardware and software costs for the new Pontis-
based BMS, excluding the development costs associated with the BMS Phase 3 project itself.
In other words, these costs represent the off-the-shelf hardware and software costs required to
support the BMS project team and ultimately the production implementation of the new BMS.
The costs summarized within this section are based upon the following assumptions:
1. The potential number of users for the new BMS, including internal PENNDOT users and
external consultants and planning partners, is approximately 600. However, it is assumed
that these will not be simultaneous users.
2. Hardware and software costs associated with the utilization of the existing PENNDOT
mainframe resources, such as the CPU, operating system, DB2, etc., are not included in the
estimates. However, any new software that is not currently deployed by PENNDOT but is
required by the new Pontis-based BMS is included in the estimates.
3. Costs associated with the utilization of existing network resources, such as routers, firewalls,
etc., are not included in the estimates.
4. Costs associated with the utilization of existing common servers, such as the DB2 gateway,
e-mail servers, domain controllers, etc., are not included in the estimates.
5. Costs associated with developer workstations for the project team are not included in the
estimates.
6. Existing hardware and software resources utilized by the new Pontis-based BMS have
sufficient capacity to support the new BMS requirements without significant upgrades or
additional costs. For example, the new BMS DB2 database will be implemented in the
existing development, test and production DB2 subsystems, and communication to that
database from the server(s) will take place using the existing DB2 gateway servers.
6.2 Hardware Cost Estimates
The following is the estimated costs for the new servers required for the new BMS, as described
in section 4.5. Costs associated with the acquisition of new or additional Electronic Data
Collector (EDC) notebook or tablet computers, if necessary to support bridge inspection, are not
included in the estimates.
These hardware estimates are based upon the following configurations for the web (BMS Web
and Crystal Enterprise) and application (BMS Application and Oracle Database) servers:
• Web Server - Dual (2) Processor Intel Xeon 3.2 GHz or above, 2 GB RAM, 146 GB or
more hard drive in a RAID 5 configuration, DVD-ROM and required network adapters
• Application Server - Quad (4) Processor Intel Xeon 2.8 GHz or above, 4 GB RAM, 500
GB or more hard drive in a RAID 5 configuration, DVD-ROM and required network
adapters
The cost for a single web server with the above configuration is approximately $10,000, while
the cost for a single application server is approximately $30,000. The cost estimates were
developed using a standard server configuration from Dell, Inc., which does not take into
account more favorable pricing that may be available to PENNDOT as a state government
BMS Re-write Phase 2 Conceptual System Design Report 101
Hardware and Software Cost Estimates
BMS Re-write Phase 2
entity. IBM servers with equivalent configurations are typically more expensive, but state
government pricing may offset the price difference in comparison to the estimate. The total
estimated cost for the new servers in the Development, Test, Training and Production
environments is as follows:
Pontis Level E
Environment Server Type Server Cost Qty $
Web Server $10,000 2 $20,000
Production
Application Server $30,000 2 $60,000
Web Server $10,000 1 $10,000
Test
Application Server $30,000 2 $60,000
Web Server $10,000 1 $10,000
Development
Application Server $28,500 1 $28,500
Web Server $10,000 1 $10,000
Training
Application Server $28,500 1 $28,500
Total Web 5 $50,000
Total Application 6 $177,000
Total 11 $227,000
6.3 Software Cost Estimates
The following is the estimate for the off-the-shelf software required to develop and support the
Pontis Level E alternative for the new Pontis-based BMS. It is based upon the following
assumptions:
1. For the web development platform, Java/Websphere will be used in an Enterprise
Websphere configuration allowing centralized administration and resource sharing for
Websphere applications. The Websphere Studio Application Developer will be the Java IDE
for development.
2. For customization of the workstation-based Pontis client application, PowerBuilder v9.0 will
be used.
3. For development of the new eForms client application, Visual Studio .NET will be used.
4. For server-based batch cycle management, existing batch management software such as
Windows Task Scheduler will be used. Although the specific software package has yet to
be identified, it is assumed for this estimate that it would not represent any additional cost.
5. For the external report server, Crystal Enterprise will be used, with the capacity to support
applications other than BMS.
All of these assumptions have been discussed and confirmed with PENNDOT BIS, with the
exception of using Visual Studio .NET as the development platform for the new eForms client
application. However, since Websphere Studio Application Developer and PowerBuilder v9.0
are alternatives for eForms development, Visual Studio .NET has been included in the estimate
as a "worst case" cost scenario (e.g., if eForms is developed in PowerBuilder, no additional tool
is required for eForms development).
All software prices were obtained from ASAP Software, the current Commonwealth software
provider. It is therefore assumed that the software package and maintenance prices are
representative of what PENNDOT can expect to pay. The estimate also does not take into
BMS Re-write Phase 2 Conceptual System Design Report 102
Hardware and Software Cost Estimates
BMS Re-write Phase 2
account which PENNDOT organization (e.g., Bureau of Design, BIS) is expected to bear the
cost of those software packages that may be utilized by applications beyond the new BMS, such
as Websphere or Crystal Enterprise. As with the hardware cost estimate, the total estimated
cost for the software in the Development, Test, Training and Production environments is as
follows:
Pontis Level E
Environment Package License 1 Year Maint Qty License $ Maint $
Crystal Enterprise Pro 9 Processor $38,834 $7,767 1 $38,834 $7,767
Oracle Enterprise Server 9i $31,200 $7,800 1 $31,200 $7,800
Websphere Enterprise Application $13,901 $3,475 1 $13,901 $3,475
Server 4.0 128 BIT WIN 32
Production
Pontis 4.x $25,000 $25,000 1 $25,000 $25,000
Batch Process Manager (e.g., $0 $0 1 $0 $0
Windows Task Scheduler)
Sub-Total 5 $108,935 $44,042
Oracle Enterprise Server 9i $31,200 $7,800 1 $31,200 $7,800
Websphere Enterprise Application $13,901 $3,475 1 $13,901 $3,475
Server 4.0 128 BIT WIN 32
Test
Batch Process Manager (e.g., $0 $0 1 $0 $0
Windows Task Scheduler)
Sub-Total 3 $45,101 $11,275
Crystal Reports Developer v9.0 $411 $83 2 $822 $165
MS Visual Studio .NET Professional $346 $86 2 $692 $173
2003
Oracle Enterprise Server 9i $31,200 $7,800 1 $31,200 $7,800
Development PowerBuilder Professional v8.0 $976 $244 4 $3,903 $976
Websphere Enterprise Application $13,901 $3,475 1 $13,901 $3,475
Server 4.0 128 BIT WIN 32
Websphere Studio Application $3,416 $854 4 $13,665 $3,416
Sub-Total 14 $64,183 $16,005
Oracle Enterprise Server 9i $31,200 $7,800 1 $31,200 $7,800
Websphere Enterprise Application $13,901 $3,475 1 $13,901 $3,475
Server 4.0 128 BIT WIN 32
Training
Batch Process Manager (e.g., $0 $0 1 $0 $0
Windows Task Scheduler)
Sub-Total 3 $45,101 $11,275
Totals 25 $263,319 $82,598
$345,917
The Pontis software itself is only listed under the Production environment because the purchase
of a Pontis license allows PENNDOT to install as many instances of the application as required,
across all environments (i.e., the license is a universal license that can be installed on any and
all PENNDOT workstations). As noted in section 4.5, a Crystal Enterprise server is not included
in the Development environment because one already exists and can be used for the new BMS;
a Crystal Enterprise server is not included in the Test environment because the reports
themselves are not dependent upon the configuration of the server and therefore reports that
are successfully tested on the development server will run successfully in production.
BMS Re-write Phase 2 Conceptual System Design Report 103
