Web viewSI03 CVIEW Interface KSCVIEW is a SQL Server database housing commercial carrier and vehicle...

ProMiles’ Response to K-TRIPS Systems Requirements of 139

GR- General RequirementsGeneral Requirements

Ref # Requirement DescriptionM

M/FO

Code

GR01 Thin Client The solution shall be a thin-client design. M 1 2 3 4

GR01 Vendor Response: PSDC’s system is a 100% web-based system accessible from any browser with an internet connection that uses HTML and java script for functionality. The system does not use any plugin or other thick-client component.

GR02 Multiple Issuing and Printing Locations

The solution shall allow for the issuing and printing of permits at multiple locations, including remote terminals, ports of entry, KTC offices and at the carriers and trucker’s locations. This includes the ability to print to locally connected and network printers. The solution shall use universal printing methods to support the widest range of printing solutions.

M 1 2 3 4

GR02 Vendor Response: PSDC’s system is a 100% web-based system accessible from any browser with an internet connection. All permits and reports are generated using industry standard formats and include PDF, HTML, and Excel. The user is able to print using virtually any printer accessible to their computer including locally connected and network printers.

GR03 Standard Graphical Interface (GUI)

The solution shall provide for and support a standard graphical user interface throughout the application. M 1 2 3 4

GR03 Vendor Response: PSDC’s system is designed to maintain a consistent user interface between all aspects of the interface. This is done using stylesheets and other elements of modern wed application design. PSDC will work with the Kansas Agencies to identify this interface standard.

GR04 Rules and Regulations Compliance

The solution shall maintain compliance with Kansas Statutes, Rules and Regulations of the KDOT and KDOR. M 1 2 3 4

GR04 Vendor Response: PSDC understands and agrees that the system must be developed to and maintain compliance with Kansas Statutes, Rules and Regulations of the KDOT and KDOR. PSDC will work with State staff to identify all such requirements and agrees that compliance with such shall be the priority of the system and that any work necessary to modify existing functionality to meet said Statutes, Rules and Regulations of the KDOT and KDOR must be performed before acceptance of the system can happen.


General Requirements


M/FO

Code

GR05 Accessibility

The solution shall be compliant with KDOT standards for accessibility by people with disabilities. Reference the following web site for the web accessibility standards for the State of Kansas.http://www.da.ks.gov/itab/was/default.htm

M 1 2 3 4

GR05 Vendor Response: Please see the response to requirement SD09.

GR06 Multi-Tasking The solution shall give users the ability to open multiple screens/windows/sessions concurrently. M 1 2 3 4

GR06 Vendor Response: PSDC will provide an interface for a user to open multiple ‘desktop’ screens concurrently using a single login. All system functionality will be available to the user through each ‘desktop’ screen. Modifications required include an interface element such as a link on all screens to open another ‘desktop’ screen using the same session information.

GR07 KSTrucking.org The solution shall be accessible through KSTrucking.org. The solution shall include any branded graphics and/or link descriptions to be placed on KSTrucking.org. M 1 2 3 4

GR07 Vendor Response: PSDC’s solution will be accessible through a link from the KSTrucking.org web site and in order to ensure user confidence that the solution is the official permitting system for the State of Kansas, PSDC will customize its solution to include branded graphics, links, style sheets and other interface elements from the KSTrucking.org web site as required by KDOT. Modifications required include developing style sheets, creating matching graphics, and adding links.

GR08 Data OwnershipThe data collected and stored by the solution shall be the sole property of the State of Kansas and KDOT. The solution developer shall not be able to use the data for any purpose beyond testing and verification of the solution functionality and operation.

M 1 2 3 4

GR08 Vendor Response: PSDC understands and agrees that all data collected and stored by the solution shall be sole property of the State of Kansas and KDOT and further agrees not to use any of this data for any purpose beyond testing and verification of the solution functionality and operation.

GR09 Open Framework The system shall be designed to support open data exchange formats including XML via web services. M 1 2 3 4

http://www.da.ks.gov/itab/was/default.htm

http://www.truckingks.org/


General Requirements


M/FO

Code

GR09 Vendor Response: PSDC’s permitting system is designed to use web services using open data exchange formats for internal and external communications. The system also supports communications with external systems using web services and open formats such as XML. The system accepts query and report requests via web services, accepts permit applications via web services, and can query external systems for such purposes as validating carriers and trucks using web services. The system will be modified to integrate with State of Kansas systems as they are currently implemented and to provide such data as KDOT and other Kansas agencies require.

GR10 Data Retention The solution shall provide an administrator a configurable timeframe for retention of all permit data and records within the system as defined by KTC data retention policies. M/F 1 2 3 4

GR010 Vendor Response: PSDC’s system has a web interface, accessible by properly authenticated administrators, allowing for the configuration of data record retention.

SD - Solution DesignSolution Design

Ref # Requirement Description

MM/F

OCode

SD01 Modular-Design The solution shall have a modular design such that it may later be modified to include new, related functionality that is not specifically identified in these requirements. M 1 2 3 4

SD01 Vendor Response: PSDC's system has been designed and developed using modern programming techniques including the use of a modular design. The system has been designed for and can be readily modified to meet the specific needs of each jurisdiction including both current needs and any future needs that may arise due to legislative and other changes.

SD02 Web-basedThe solution shall provide its functionality described in these requirements through a web interface. The solution allow for the submission of all information for applications, reporting and communicating through the web interface.

M 1 2 3 4


Solution DesignRef # Requirement Description

MM/F

OCode

SD02 Vendor Response: PSDC’s system is a 100% web-based system. All functionality for the system can be accessed using a browser from any computer with access to the internet.

SD03 Permit Types The solution shall be able to accept applications for, process, and issue all permit types described in Appendix 2. M 1 2 3 4

SD03 Vendor Response: PSDC’s system is designed with an interface that allows users to configure parameters for most permit types. This system has a proven ability to implement most permit types allowing for the modification of existing permits and the creation of new permits to be implemented without code change. PSDC has reviewed the permits listed in this RFP and believes its system has the capability to implement each of these permit types, with the exception of the pilot vehicle permit, with no code changes.

SD04 Bridge Analysis Reports

The solution shall be able to create and manage bridge analysis reports created by KDOT for Superload permits. See Appendix 3 for a sample bridge analysis report. M 1 2 3 4

SD04 Vendor Response: PSDC will implement the bridge analysis reports within its system as required by KDOT. The report will closely mirror what is described in Appendix 3 of the RFP or another format as required by KDOT.

SD05 Pilot Vehicle Permits The solution shall be able to create and manage pilot vehicle permits. See Appendix 5 for an example pilot vehicle permit. M 1 2 3 4

SD05 Vendor Response: PSDC will implement pilot vehicle permit functionality that will issue pilot vehicle permits. These permits will be virtually identical to the sample permit or will be configured as the State desires. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

SD06 Queue Management

The solution shall implement the concept of queue management for permit applications. The queue concept entails a capability to display, manage and monitor the status of all workflows. Queue control and report capabilities shall be role-based with supervisors and administrators exercising the highest level of queue control and visibility.

M 1 2 3 4



MM/F

OCode

SD06 Vendor Response: PSDC’s system implements permit workflow using queues. Administrative users are able to create and modify queues. Permits that are cannot be self-issued will be stored in a queue awaiting Kansas staff to process permits in the queues. Supervisors and administrators will be able to manage and monitor the status of the workflow using these queues.

The system can take into account the following factors when deciding which queue a permit should be in:

Permit type Permit status Height Length Width Weight Axle weight Axle grouping weight Queue evaluation order Default queue

Supervisors are able to create permit status types to assist in assigning permits to queue. For example, after a Superload has been approved by the KDOT BEU staff it is to be sent to the district coordinators for approval. A permit status type could be created and assigned to such permits to assist assigning the permits to a queue for the district coordinators to review.

Users are able to monitor the status of all work queues in real time from their dashboard. This includes the count of permits in each queue, the length of time the oldest permit has been in the queue, and the average processing time for permit in the queue. Screenshots of the queue definition screens, viewing the permits within queues, and queue statistics can be found on page Error: Reference source not found of this response.

SD07 Kansas Staff Intervention

The solution shall allow Kansas Staff to manage the processing of specific permits as indicated in these requirements. Management may include approval, rejection, prioritizing in a queue, reviewing or assigning routing, and collecting any approvals required for a permit.

M 1 2 3 4



MM/F

OCode

SD07 Vendor Response: Permit Office Staff are able to manage the process of reviewing and issuing permits. The work queues provide access to permits for review and processing. Permits can also be accessed using the search functionality. Permit Staff users can be limited to the queues they are able to work and can be limited to only processing the next permit in the queue. Note: All Permit Staff are able to view all permits in queues they have permission for. Permit Staff with authorization are able to process permits out-of-order in queues and are able to prioritize permits within queues. Permit staff are able to perform the following tasks to permits:

Review Process Route Modify Approve Reject Assign status Add notes Upload documentation

Screenshots of managing permits can be found in the response to requirement SA18.

SD08 Web-based The solution shall provide permitting capabilities for users with minimal Internet bandwidth. (Users accessing the solution via modem at speeds as low as of 33 kbps.) O 1 2 3 4

SD08 Vendor Response: PSDC’s permitting system is usable at speeds as low as 33 kbps.

SD09 Web Design Standards All web pages designed as part of the solution shall comply with the KDOT Web/Windows Application Standards and Internet/Intranet Web Design Standards available in Attachment 3. M 1 2 3 4



MM/F

OCode

SD09 Vendor Response: PSDC believes its permitting system meets the requirements of KDOT’s Website Design Standards with the following exceptions:

All maps on the system provide information through the use of color that is not directly available through other means (Priority 1 checklist 2.1) Note: text driving directions are provided with the system

PSDC’s permitting system, like virtually all other modern web applications, makes extensive use of scripting to improve the user’s experience. (Priority 1 checklist 6.3) PSDC is not currently including, but can if requested, a version of the system without scripting.

PSDC’s system does use some popup pages. (Priority 2 Checklist 10.1) Some of the tables used to for layout will not linearize well (Priority 2 Checklist 5.3)

PSDC will be glad to work with the State to identify appropriate methods to mitigate these exceptions.

SD10 Web Browser Compatibility

The vendor shall indicate which web browsers the solution shall be compatible and fully functional in:

- Microsoft IE 6 and higher- Firefox 3 and higher

Vendors are encouraged to indicate which of the following web browsers and platforms the system shall provide functionality in:

- Safari 2, 3 and higher- Google Chrome 1 and higher- Google Droid- Apple iPhone/iPad- RIM Blackberry- Windows Mobile- Other

The vendor shall identify any functional differences in the solution by operating system for the web browsers.

M/F 1 2 3 4



MM/F

OCode

SD10 Vendor Response: PSDC’s system currently works optimally and is tested to ensure complete functionality with the following browsers:

Microsoft IE 7 and higher Firefox 3 and higher Safari 2, 3 and higher Google Chrome 1 and higher

PSDC’s system can be made to work with Microsoft IE 6 but currently does not due to IE 6’s declining share of the market, TxDOT’s decision to require IE 7, and idiosyncrasies in IE 6. PSDC anticipates that by 2012, the share of the market that will use IE 6 to be negligible. If the State decides to require PSDC to implement IE 6, it will be able to do so with no extra charge.

PSDC’s system runs on the iPad with no modifications and no usage issues. PSDC’s system currently runs on Google Droid, Apple iPhone, and Windows Mobile. However, the system’s screen size is larger than can be readily used on these mobile platforms. To make the system usable of the small screen size inherent in these mobile platforms will require functionality changes in the system. The charge for these changes is included in the pricing offer. RIM Blackberry browsers prior to the Blackberry Torch support very limited scripting functionality which is used extensively by PSDC’s system. PSDC’s system would undergo significant changes to work on these older platforms. PSDC’s is not including pricing for implementing the operating system natively on any of these platforms due to requirement GR01.

SD11 Hardware Standards Solution hardware shall meet Kansas’ hardware requirements and be approved by KDOT project staff prior to deployment. Kansas prefers Hewlett Packard hardware. M/F 1 2 3 4

SD11 Vendor Response: PSDC agrees that all hardware used to implement the solution will meet current Kansas hardware requirements. Where available, PSDC will use Hewlett Packard hardware in its implementation.

SD12 Software Standards All software developed as part of the solution shall meet Kansas Software Standards. Kansas’ preferred development environments are .NET and JavaScript. M/F 1 2 3 4

SD12 Vendor Response: PSDC’s system is developed using .NET and JavaScript. All development specific to the Kansas solution will be done using Kansas Software Standards as provided to PSDC by the State.



MM/F

OCode

SD13 Database

The solution shall use a relational database structure that is approved by KDOT project staff prior to deployment. Databases currently approved by KTC include:

- SQL Server- Oracle 10g

If any other database is proposed, the Offeror shall describe the reasons why and the advantages that database offers for this project.

M/F 1 2 3 4

SD13 Vendor Response: PSDC’s system is designed using MS SQL Server and can be modified to use Oracle 10g. PSDC’s preferred database is MS SQL Server.

SD14 Database DesignThe vendor shall provide detailed database design documentation for the solution, including database schemas, data dictionaries and interface control documents created during the solution design phase. Design documents shall be maintained as the system is updated or changed.

M 1 2 3 4

SD14 Vendor Response: PSDC agrees to create and provide detailed database design documentation for the complete solution, including database schemas, data dictionaries and interface control documents. PSDC agrees that such documents will be maintained during the development and implementation of the system and after the system has been placed in production and as it is updated or changed. This documentation will be created using industry documentation standards as directed by the State in industry standard formats such as Word, Excel, or PDF. Sample documents have been included in Section 2.12 of this response.

SD15 Load-Balanced Servers The solution shall have front-end load balanced web servers. M/F 1 2 3 4

SD15 Vendor Response: PSDC’s system has been designed from the ground up to run on multiple servers and to use front-end load balancing. User session information can be stored in a common database allowing users to continue their session using different web servers. PSDC will provide front-end load balancing hardware in its deployment of the system.



MM/F

OCode

SD16 Solution Speed and Capacity

Assuming bandwidth speeds of 1.5 MBps or higher, the system shall be able to complete 95% of all requests within five seconds and 100% of all requests within 15 seconds. (This includes map rendering, panning and zooming.) Offeror must identify all transactions that may not comply with this requirement and describe the reasons they may not comply.

The solution shall be able to process over 200,000 permit applications per year with surge capacity of up to 200 concurrent users making 25 requests per second. The solution shall have the capacity to store and maintain 15,000 unique user accounts.

M/F 1 2 3 4

SD16 Vendor Response: PSDC’s system meets the speed requirements listed in this requirement with the following exceptions:

1. Users are able to request reports that can both take longer than 15 seconds to create and can take longer than 15 seconds to deliver at a speed of 1.5 MBps.

2. Users are able to request routes with a sufficient number of legs that creating and delivering the response will take longer than 15 seconds. The system will be able to deliver routes with up to 4 legs in 15 seconds or less.

PSDC’s system is, when running in an environment with sufficient hardware, capable of processing in excess of 1,000,000 permits per year and more than 100,000 accounts. PSDC’s system easily meets the surge capacity listed in this requirement.

SD17 Solution Reliability

The solution shall be capable of providing full functionality 24 hours/day, 7 days/week, 99% of the time, excepting scheduled maintenance. KTC shall be informed of scheduled maintenance in writing at least three weeks in advance. Maintenance periods shall be performed during non-peak usage hours.

M 1 2 3 4

SD17 Vendor Response: PSDC’s system has been designed and developed to work in high availability environments. Each of PSDC’s currently installed systems have uptimes in excess of 99%. PSDC agrees that if it is awarded the solution, it will notify KTC in writing of all scheduled maintenance at least three weeks in advance and to perform all maintenance during non-peak usage hours.

SD18 Network Protocol The solution shall work on an Ethernet network and support TCP/IP network protocol. M 1 2 3 4

SD18 Vendor Response: PSDC’s system works on Ethernet networks and uses the TCP/IP network protocol.



MM/F

OCode

SD19 Display Version The solution shall display the current version and operating environment within the solution. M 1 2 3 4

SD19 Vendor Response: PSDC will include the current version and system environment (development, test, or production) in a place of KDOT’s choosing. This modification will consist of placing code in the selected location to identify and display the current version and system environment. PSDC’s system currently displays this information.

SI - System InterfacesAppendix 6 provides an overview of the anticipated K-Trips system-to-system interfaces. Specific requirements follow.

System InterfacesRef # Requirement Description

MM/F

OCode

SI01 Batch Permit Processing Interface

The solution shall have a defined interface for batch permit application data input and shall support receiving permit applications and issuing permits in a batch file format. The interface shall be utilized by authorized 3rd party permit service providers. Vendor must also produce the ability for users of the system to generate batch/flat files of issued permits.

Type: BatchDirection Send, ReceiveFrequency Real TimeFormat Text or XMLData TBD

M/F 1 2 3 4



MM/F

OCode

SI01 Vendor Response: PSDC will implement an interface to accept batch permit applications. This interface will be developed in collaboration with KDOT personnel and will include the ability to generate batch or flat files of issued permits. Those permits that cannot be self-issued will be placed into queues for processing. PSDC expects that permits submitted using the batch interface will be accessible and modifiable by the permit service exactly the same as permits manually entered. Notifications of permits that could not be self-issued will be returned to the account after the completion of the individual batch file. PSDC will include administrative functionality allowing administrators to control the following aspects of the batch processing functionality:

Which Permit Service Accounts can make use of this capability Schedule for process the batch files Priority of batch files Processing parameters including maximum size, time of day, days of the week, etc. Backup, recover, restart, and cancel batch processing Reports of permit status for batch files

Modifications required include creating a batch interface, creating functionality to read such batch files and enter the requests contained therein, and creating an interface for these 3rd party permit services to review the applications submitted.

SI02 KSCVIEW/Safety Interface

KSCVIEW is SQL Server database of commercial carrier and vehicle information, housed within the KHP network, used for enforcement, querying and reporting purposes. The solution shall interface with KSCVIEW via web services for instant queries of permit applicant safety, authority, UCR and MCSIP status. The solution shall provide permit data to the Kansas CVIEW via web service in XML format that allow KHP to accurately verify permit status of carriers and vehicles through the CVIEW.

Type: Real TimeDirection Send, ReceiveFrequency Real TimeFormat Web ServicesData TBD

M 1 2 3 4



MM/F

OCode

SI02 Vendor Response: PSDC’s permitting system is designed to work with external systems to validate carrier accounts and vehicles. Currently PSDC’s system integrates with SAFER and TxDOT’s MCCS system using web-services to validate carriers. PSDC’s system also implements a permit validation interface using web-services for external systems to obtain current information on permits. PSDC will modify its system using interface documentation provided by KDOT to interface with KSCVIEW. This will include querying KSCVIEW for instant queries of permit applicant safety, authority, UCR and MCSIP status and to provide permit data to the KSCVIEW system. Modifications required include creation of a web services interface for requesting information from KSCVIEW and the creation of a listening web-service for providing permit information to KSCVIEW.

SI03 CVIEW Interface

KSCVIEW is a SQL Server database housing commercial carrier and vehicle information, housed within the KHP network, used for enforcement, querying and reporting purposes. KSCVIEW will be used by roadside enforcement officers to revoke permits when placing a truck out of service. The solution shall support a web services interface from KSCVIEW for receipt of a permit revocation transaction.

Type: Real TimeDirection ReceiveFrequency Real TimeFormat Web ServicesData TBD

M 1 2 3 4

SI03 Vendor Response: PSDC will work with Kansas state agencies to create a web service specification to accept permit revocation transactions and to modify its permitting system to accept such transactions. Modifications required include the creation of the specification, addition of database fields and functionality to implement such requests, including saving revocation dates and reasons, and the creation of a web service interface to accept the requests.

SI04 E-payment Interface

The solution shall interface with Kansas’ selected e-payment service via web services for the processing of electronic payment via credit card and debit card. A provider of e-payment services has not been selected, however, it is expected that the provider will have a web service interface.

Type: Real TimeDirection Send, ReceiveFrequency Real TimeFormat TBDData TBD

M 1 2 3 4



MM/F

OCode

SI04 Vendor Response: PSDC’s permitting system is designed to work with e-payment services using a variety of methods including web services. PSDC will configure its system to work with Kansas’s selected e-payment service provider. Modifications required are the configuration of the system to the selected provider’s requirements.

SI05 CANSYS Interface

CANSYS is an Oracle database (Oracle Spatial Data Network Model) housing KDOT’s spatially oriented road and bridge data. The solution shall interface with CANSYS for roadway data, including geometry, naming, linear referencing system, height, width, weight and length restrictions. The data shall be available from CANSYS on a nightly basis via FTP in materialized views. A description of data availability in CANSYS is included in Appendix 7.

Type: BatchDirection ReceiveFrequency NightlyFormat Table

(Materialized View)Data TBD

M 1 2 3 4

SI05 Vendor Response: PSDC’s permitting system will utilize all data found in the CANSYS database on a nightly basis. For more information on how this data will be used, please see the response to requirement AR04.

SI06 KANROAD Interface

KANROAD is an Oracle database housing road restriction and road condition data. KANROAD includes a public-facing 511 information web-page displaying The solution shall interface with KANROAD for construction and event data that creates width, height and weight restrictions. The data shall be available from KANROADS on a periodic basis that may be multiple times daily via FTP in a comma-delimited format. A description and data dictionary for KANROAD is included in Appendix 8.

Type: BatchDirection Send, ReceiveFrequency TBDFormat TextData TBD

M 1 2 3 4

http://511.ksdot.org/KanRoadPublic_VE/Default.aspx



MM/F

OCode

SI06 Vendor Response: PSDC will implement functionality to import all of the OS/OW restriction data from the KANROAD database into the K-TRIPS restriction database. Please see the response to requirement AR32 for more information on the restriction database. PSDC will use the linear reference data in the KANROAD database to identify road segments in the K-TRIPS routing database using the CANSYS linear reference data contain therein. See the response to requirement AR04 for more information on the linear reference network in the K-TRIPS routing database.

SI07 Virtis Interface

The solution shall interface with Virtis, the KDOT bridge analysis application, for the analysis of bridge structures. The solution shall submit vehicle characteristics and bridge identifiers for evaluation and integrate any warnings, requirements and restrictions generated by Virtis into its routing determinations. The interface shall allow for selection of a default bridge analysis engine (BRASS or ASSHTO) and the capability to override for an individual analysis. Virtis output shall be incorporated into solution processes for assessing and approving Superload permit applications and generating the Bridge Analysis report. (See requirement # RQ09 Appendix 3 and Appendix 4.)Virtis shall also be the source for creating the Statewide Weight Analysis Study reports. (See requirement # AR12.)


M 1 2 3 4



MM/F

OCode

SI07 Vendor Response: PSDC will implement an interface with Virtis for its permitting system if it is chosen for the solution. PSDC anticipates its program to use the COM interface available in Virtis. PSDC will implement an interface allowing BEU Routers to do the following:

Select bridge along the route, or from another list to submit for load rating View the permit application including any diagrams or other documents Select the rating engine to use View the results from the load rating Resubmit a route back to the routing engine with a set of bridges restricted Direct the system to create a Bridge Analysis report as described in the response to RQ09 Add notes to the Bridge Analysis report Approve the route

District coordinators will also have access to the results of the bridge analysis. The following diagram illustrates PSDC’s proposed system for this requirement:



MM/F

OCode

SI08 Alternate BRASS Interface

As an alternative, K-TRIPS shall interface with BRASS for the analysis of bridge structures. The solution shall submit vehicle characteristics and bridge identifiers for evaluation and integrate any warnings, requirements and restrictions generated by BRASS into its routing determinations. BRASS output shall be incorporated into solution processes for assessing and approving Superload permit applications and generating the Bridge Analysis report. (See requirement # RQ09 and Appendix 3 and Appendix 4.)BRASS shall also be the source for creating the Statewide Weight Analysis Study reports. (See requirement # AR12.)


M/F 1 2 3 4

SI08 Vendor Response: PSDC has elected to respond to requirement SI07 rather than alternative SI08.


UR - User RolesUser Roles


MM/F

OCode

UR01 User Roles

The solution shall have several user roles defined. Each user role shall have different functions within the solution. The solution shall be able to assign a user to more than one role. The solution shall provide for creation of a unique account type for each user role. For example, a K-TRIPS System Administrator will have her own account, with capabilities tied to the account, based upon the system administrator role.

M/F 1 2 3 4


User RolesRef # Requirement Description

MM/F

OCode

UR01 Vendor Response: PSDC’s permitting system has a flexible and easy to use permission system allowing for the creation of a variety of user roles. The permissions for each role are configurable, and users can be assigned multiple roles. User roles are created by selecting a name for the role and then selecting 1 or more permissions for that role. This list of permissions include all activities that can be performed by users of the system and include items such as the following:

Accept and enter permit applications View permits in a queue Review and edit permit applications Approve permits in a queue Void/Cancel permits Create permit definitions Create queues Add users Revoke permits Modify permits View error logs Modify error messages Manage restrictions Perform OS/OW routing review Generate reports Provide live chat support Provide email technical support

Note: This list is not exhaustive. Required modifications will include adding permissions for each item of functionality implemented for the solution. See page Error: Reference source not found of this response for sample screenshots showing creation of roles and assignment of permissions to the roles. Once this list of activities is implemented, additional roles can be created without any programming. There is essentially no limit to the number of user roles that can be created.



MM/F

OCode

UR02 K-TRIPS Permit Agent

K-TRIPS Permit AgentThe K-TRIPS Permit Agent accepts and enters permit applications submitted by carriers. The K-TRIPS Permit Agent role shall also be able to review and edit existing permit applications, issue permits, override, void and cancel permits, access limited customer account data, provide customer support, perform oversize/overweight routing reviews (with the exception of Superload and large structure routing), monitor permit application status and manage the permit application queue.

M/F 1 2 3 4

UR02 Vendor Response: PSDC’s user role system has the capability of creating a K-TRIPS Permit Agent role. The role will allow users assigned to it to perform all of the following: review and edit existing permit applications, issue permits, override, void and cancel permits, access limited customer account data, provide customer support, perform oversize/overweight routing reviews (with the exception of Superload and large structure routing), monitor permit application status and manage the permit application queue. The Permit Agent role will be implemented using the functionality described in the response to requirement UR01.

Note: In addition to the permissions described in the response to UR01, the system has several additional capabilities to control user access. These abilities include:

Assigning users to queues Assigning envelope limits to users

In the above example, the user could be limited from reviewing Superload and large structure loads either by permissions set in the Permit Agent role, or by limiting the user’s access to a Superload and large structure queue or by assigning envelope limits to the Permit Agents that preclude reviewing Superload and large structure loads.

UR03 K-TRIPS Customer Support

K-TRIPS Customer SupportThe solution shall have a role for K-TRIPS Customer Support that allows the role to provide live chat and e-mail technical support to customers using the solution.The K-TRIPS Customer Support role shall be able to interact with customers through live chat, view the status of customer permit applications and see a mirror copy of any screen from which the customer has requested help. The K-TRIPS Customer Support role will not issue permits.

M/F 1 2 3 4



MM/F

OCode

UR03 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Customer Support role. The role will allow users assigned to it to perform all of the following: live chat and e-mail technical support to customers, view the status of customer permit applications and see a mirror copy of any screen from which the customer has requested help, but not authorized to issue permits. The ‘live chat’ functionality is described in the response to requirement WI06. The Customer Support role will be implemented using the functionality described in the response to requirement UR01.

UR04 K-TRIPS Accounting

K-TRIPS AccountingThe K-TRIPS Accounting role allows the user to generate ad hoc and canned financial reports, review and edit daily balances and transactions, adjust account escrow balances, review financial audit trails and send out notices to carriers concerning financial issues.

M/F 1 2 3 4

UR04 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Account role allowing users access to the functionality described in this requirement. The Accounting role will be implemented using the functionality described in the response to requirement UR01.

UR05 K-TRIPS Supervisor

K-TRIPS SupervisorThe K-TRIPS Supervisor manages accounts, including creating, deleting and changing account information. The K-TRIPS Supervisor also manages permit applications including editing, voiding and cancelling.The K-TRIPS Supervisor role shall have the ability to manage the display of the following in the solution: contact information, links and location definitions and online help.The K-TRIPS Supervisor role shall have the ability to review audit trails.

M/F 1 2 3 4

UR05 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Supervisor role allowing users access to the functionality described in this requirement. The Supervisor role will be implemented using the functionality described in the response to requirement UR01.



MM/F

OCode

UR06 K-TRIPS System Administrator

K-TRIPS System AdministratorThe K-TRIPS System Administrator accesses all functionality described in other roles, in addition to functions to administer the system.The K-TRIPS Administrator role shall also be able to manage the solution, including entering standard dimensions and routes, defining vehicle limits, Superload and large structure parameters.The K-TRIPS System Administrator role includes the ability to view error logs and monitor system health. The role also includes the ability to generate canned and ad hoc reports on system performance, usage and user activity.

M/F 1 2 3 4

UR06 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS System Administrator role allowing users access to the functionality described in this requirement. The System Administrator role will be implemented using the functionality described in the response to requirement UR01.

UR07 Enforcement

EnforcementThe Enforcement role allows the user to view a permit or permit status for a carrier or vehicle. (Note: See SI02 and SI03 for definition of KSCVIEW interfaces to be established for roadside enforcement activities.)

M/F 1 2 3 4

UR07 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Enforcement role allowing users access to the functionality described in this requirement. The Enforcement role will be implemented using the functionality described in the response to requirement UR01.

UR08 Bridge Evaluation Supervisor

Bridge Evaluation SupervisorThe Bridge Evaluation Supervisor views the status of all Superload applications, manages (approve, reject, change, delete, add) Superload bridge analysis reports, generates bridge evaluation reports and manages the queue of Superload applications, including the ability to assign applications to users with the Bridge Evaluation role and overriding the need for a second Bridge Evaluation Router to validate the analysis of a first Bridge Evaluation Router. See Appendix 3 for an example of a bridge analysis report for a Superload permit.

M/F 1 2 3 4



MM/F

OCode

UR08 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Bridge Evaluation Supervisor role allowing users access to the functionality described in this requirement. The Bridge Evaluation Supervisor role will be implemented using the functionality described in the response to requirement UR01.

UR09 Bridge Evaluation Router

Bridge Evaluation RouterThe Bridge Evaluation Router reviews bridge analysis reports and routing for Superloads.The Bridge Evaluation Router role shall be able to select applications from the queue of permit applications for Superloads or be assigned an application by the Bridge Evaluation Supervisor, review permit applications, review and modify proposed routing, generate and review bridge analysis reports for individual trips, validate the analysis performed by another Bridge Evaluation Router, and override restrictions resulting from the bridge analysis.The Bridge Evaluation Router role shall also be able to manage the workflow of a Superload application, including submitting bridge evaluations to the Bridge Evaluation Supervisor for approval and forwarding to KDOT District Coordinators for review and approval.

M/F 1 2 3 4

UR09 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Bridge Evaluation Router role allowing users access to the functionality described in this requirement. The Bridge Evaluation Router role will be implemented using the functionality described in the response to requirement UR01.

UR10 District Coordinator

District CoordinatorThe District Coordinator reviews routing for Superload and large structure permit applications.The District Coordination role shall be able to review, approve, comment on and reject Superload and large structure permit applications and routings. The role shall allow for electronic signature, notations, and management of the Superload and large structure application queues including moving to adjacent District Coordinators for approvals.

M/F 1 2 3 4

UR10 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS District Coordinator role allowing users access to the functionality described in this requirement. The District Coordinator role will be implemented using the functionality described in the response to requirement UR01. Note: PSDC’s system is capable of identifying all of the districts a particular route travels through. This is done using fields in the GIS data for each road segment in the trip.



MM/F

OCode

UR11 K-TRIPS Account Holder

K-TRIPS Account HolderThe solution shall have a role for K-TRIPS Account Holders that allows the user to have an account within the solution and apply for and receive permits electronically and manage account information. There shall be one K-TRIPS Account Holder for each account. Each account shall have a unique USDOT Number and Taxpayer Identification Number (TIN).The K-TRIPS Account Holder role shall allow the user to use the solution’s web interface to apply for various permit types, recharge an escrow account, manage customer account information, manage vehicles within the account’s fleet, manage account user roles within the account, perform limited automated routing, pay for permits, generate canned permit account reports and receive permits.

M/F 1 2 3 4

UR11 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Account Holders role allowing users access to the functionality described in this requirement. The Account Holders role will be implemented using the functionality described in the response to requirement UR01. PSDC will add functionality to the system limiting the number of Account Holder roles for each account to one.

UR12 K-TRIPS Account User

K-TRIPS Account UserThe solution shall have a role for the K-TRIPS Account User that allows the user to apply for and receive permits electronically. There may be one to multiple K-TRIPS Account Users associated with a single K-TRIPS Account, however each user must be associated with an existing account and each K-TRIPS User may only be associated with one account.The K-TRIPS User role shall allow the user to apply for various permit types, perform limited automated routing, generate some reports, pay for permits and receive permits.

M/F 1 2 3 4

UR12 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Account User role allowing users access to the functionality described in this requirement. The Account User role will be implemented using the functionality described in the response to requirement UR01. PSDC’s system allows for multiple users assigned to a single customer account. All additional users for a customer account (other than the one Account Holder) will be K-TRIPS Account Users.



MM/F

OCode

UR13 K-TRIPS Permit Service Account Holder

K-TRIPS Permits Service Account HolderThe solution shall have a role for K-TRIPS Permit Service Account Holders that allows the user to have an account within the solution and manage the Permit Service Users within that account. There shall be one K-TRIPS Permit Service Account Holder for each Permit Service account. Each account shall have a unique Taxpayer Identification Number (TIN).The K-TRIPS Permit Service Account Holder role shall allow the user to use the web interface to recharge an escrow account, manage account information, manage user roles within the account, generate canned permit account reports and receive permits.

M/F 1 2 3 4

UR13 Vendor Response: PSDC’s permit system has the capability for creating Permit Service or Wire Service accounts. These accounts can order permits for other (non Permit Service) accounts. PSDC’s permitting system has the capability of creating a K-TRIPS Permit Service Account Holders role allowing users access to the functionality described in this requirement. The Account Holders role will be implemented using the functionality described in the response to requirement UR01. PSDC will add functionality to the system limiting the number of Permit Service Account Holder roles for each account to one. Only Permit Service Accounts can have a Permit Service Account Holder user.

UR14 K-TRIPS Permit Service User

K-TRIPS Permit Service UserThe K-TRIPS Permit Service User manages multiple accounts plus applies and pays for permits for multiple accounts. The role is intended for companies that provide permitting service to multiple carriers. Permit Service Users may purchase permits for any USDOT Number. Permit Service Users may apply for and receive permits electronically for multiple carriers. They may manage their account information.The Permit Service User role shall allow the user to use the web interface to apply for various permit types, manage customer account information, perform limited automated routing, apply for permits, pay for permits, generate canned permit account reports and receive permits.

The Permit Service User shall be able submit permit applications through a batch process.

M/F 1 2 3 4

UR14 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Permit Service User role allowing users access to the functionality described in this requirement. The Permit Service User role will be implemented using the functionality described in the response to requirement UR01. PSDC’s system allows for multiple users assigned to a single Permit Service customer account. All additional users for a Permit Service customer account (other than the one Permit Service Account Holder) will be K-TRIPS Permit Service Users.



MM/F

OCode

UR15 K-TRIPS Pilot Vehicle Service

K-TRIPS Pilot Vehicle ServiceThe solution shall have a role for Pilot Vehicle Service that allows a user to apply for, pay for and receive Pilot Vehicle permits through the solution.

M/F 1 2 3 4

UR15 Vendor Response: PSDC will implement Pilot Vehicle permit functionality that will allow Pilot Vehicle services to apply for, pay for, and receive Pilot Vehicle permits. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation. The Pilot Vehicle Service role will be implemented using the functionality described in the response to requirement UR01.

UR16 K-TRIPS Restriction Entry

K-TRIPS Restriction EntryThe solution shall have a role for K-TRIPS Restriction Entry that allows the user to manage, add, delete and edit route restrictions that are entered directly into the solution.

M/F 1 2 3 4

UR16 Vendor Response: PSDC’s permitting system has the capability of creating a K-TRIPS Restriction Entry role allowing users access to the functionality described in this requirement. The Restriction Entry role will be implemented using the functionality described in the response to requirement UR01. See the response to AR32 for more information of the Restriction Management system.


WI - Web InterfaceWeb interface


M/FO

Code

WI01 Consistent GUI

The solution shall provide for and support a consistent GUI across all components and provides a common look and feel across all modules, including:

Consistent function keys Screen naming functions Navigation patterns Menus (as defined by security profile) Style sheets, headers and footers

M 1 2 3 4

WI01 Vendor Response: PSDC’s permitting system is designed to maintain a consistent look and feel across all modules. PSDC will modify the system so the look and feel is consistent with the KSTrucking.org website include branded graphics, links, style sheets and other interface elements as required by KDOT. Modifications required include developing style sheets, creating matching graphics, and adding links.

WI02 Escrow BalanceFor accounts with escrow accounts associated, the solution shall display the account balance of the associated account upon log-in. If the escrow balance is below a configurable threshold, the solution shall highlight the balance for the user.

M/F 1 2 3 4

WI02 Vendor Response: PSDC includes the escrow balance on the dashboard screen for carriers and permit service users. See the screenshot on page Error: Reference source not found. PSDC will modify its software to highlight the balance if it is below a configurable threshold. Required modifications include a table to store the value, an interface for administrators to modify the value, and functionality to highlight it.

WI03 Drop-Down Lists The solution shall have the ability to use online drop-down lists of all valid values for each validated field. M/F 1 2 3 4

WI03 Vendor Response: PSDC’s permit system uses drop-down lists whenever this is a reasonable interface option. The system has an administrative interface allowing users to maintain the valid values for each drop-down list. Examples of drop-down lists include permit type, vehicle makes, tire sizes, and permit delivery method.


Web interface


M/FO

Code

WI04 Navigation The solution shall be able to access other input screens and modules without backing out of menus or menu paths. M/F 1 2 3 4

WI04 Vendor Response: PSDC will provide an interface for a user to open multiple ‘desktop’ screens concurrently using a single login. All system functionality will be available to the user through each ‘desktop’ screen. The user’s original screen can be saved so the user can resume work on that screen. Modifications required include an interface element such as a link on all screens to open another ‘desktop’ screen using the same session information.

WI05 Help Request Management

The solution shall provide to K-TRIPS Supervisor users the ability to view and manage the queue of incoming requests for help via e-mail and for “Instant Message” or “Chat” support. Management includes assigning priority of requests and directing them to K-TRIPS Customer Support users.

M/F 1 2 3 4

WI05 Vendor Response: Please see the response to requirement WI06.

WI06 Online Help

The solution shall provide to K-TRIPS Customer Support users the ability to interact with K-TRIPS customers through a text “live chat” feature. The solution shall allow K-TRIPS Customer Support to identify the customer requesting help and the status of their activity within the solution (e.g. identifying the page or permit type being applied for). The solution shall allow the K-TRIPS Customer Support user to see the customer’s screen in order to aid them in using the solution and allow KTC Supervisors the ability to turn on or off the link to online live help.

The solution shall provide up-to-date on-line help, including context-sensitive on-line help for all modules of the solution. The on-line help shall be specific to the user roles (e.g. K-TRIPS Users view help only for elements of the solution used by that role).

The solution shall provide links for customers to send e-mail questions and comments to K-TRIPS Permit Agents.

M/F 1 2 3 4


Web interface


M/FO

Code

WI06 Vendor Response: PSDC will implement a ‘live chat’ functionality into its system to meet this requirement. This live chat functionality will include the following:

Communicate between customer support personnel and customer via chat screen Maintain a queue of requests that can be viewed and prioritized by authorized users Save a record of the chats for a configurable time period Allow users to create a list of canned responses which can quickly be sent to the customer or can be edited before being sent out Allow the customer support personnel to view the screen as the customer is viewing it Allow the customer support personnel to support multiple customers simultaneously

PSDC will create an on-line help system using a specification of the State’s choosing. PSDC will ensure this help system is up-to-date and will include context sensitive help for all modules of the system. PSDC will also ensure this help system is specific to user’s roles.

PSDC will also provide a link to for customers to send email questions and comments.

Required modifications include creation of the interfaces and help files described above.

WI07 Frequently Used Customer Responses

The solution shall be able to allow Kansas staff to store responses to customer questions for recall. The purpose will be to allow K-TRIPS Customer Support users to recall and edit frequent responses, rather than rewrite them each time they are appropriate.

O 1 2 3 4

WI07 Vendor Response: Please see the response to requirement WI06.

WI08 Downloadable Manual

The solution shall provide a link to a complete downloadable instruction manual in PDF. The downloadable manual shall be maintained and remain current with solution changes and upgrades. M 1 2 3 4

WI08 Vendor Response: PSDC will create and maintain a complete instruction manual for the solution which the user will be able to download in PDF format. PSDC will work with State agencies on the format and contents of said manual. PSDC agrees that it will bear the responsibility of maintaining this manual for the life of the contract.


Web interface


M/FO

Code

WI09 Shortcuts The solution shall have the ability to provide keystrokes for rapid data entry and movement from screen to screen ("hotkeys" or coding reduction techniques). M/F 1 2 3 4

WI09 Vendor Response: PSDC will work with the Department users to identify hotkeys for rapid data entry and movement between screens and then to implement this capability. These hotkeys will be, where possible and appropriate, consistent across all modules of the system. Required modifications include identifying and implementing such functionality.

WI10 Keyboard Shortcuts The solution shall provide for and support keyboard shortcuts for common functions such as copy and paste. M/F 1 2 3 4

WI10 Vendor Response: PSDC’s system does not interfere with common keyboard shortcut functions and these functions will work within the interface elements of the system in their normal manner.

WI11 Default Screen Value The solution shall provide for and support default screen values. M/F 1 2 3 4

WI11 Vendor Response: The use of default values facilitates use of a permitting system, and PSDC’s system provides several methods for supporting default screen values. These include the ability to assign default values by permit type and for carriers to select default values such as contact method, address, email, and unit information. Modifications required will include working with KDOT personnel to identify and implement useful default values not currently supported.

WI12 Permit Type Recognition

Whenever possible the solution shall use data entered by the user to automatically identify the types of permits that should be applied for and direct further data entry to the process for that permit type. In some cases, the user will have to manually specify permit types. In these cases, the solution shall use the user selection to automatically determine the other data needed. See WI20 for discussions regarding “permit wizard” capabilities.

M/F 1 2 3 4


Web interface


M/FO

Code

WI12 Vendor Response: PSDC will work with State personnel to develop in intuitive interface that assists customers in the selection of the correct permit based on their vehicle, load, state requirements, and other needs. This will include a permit wizard as described in the response to WI20 in this document and will include dynamic screen input based in part on the permit type as described in the response to WI13. PSDC will also develop an interface, working with State personnel, allowing the user to enter vehicle and load information and assist the user in identifying the required permit. The following parameters will play a key role in this:

Vehicle and load dimensions Weight Load type Time period

PSDC will also develop an interface allowing this capability to be configured as the permitting requirements and types of the State change.

WI13 Smart Screens The solution’s screens shall contain triggers to additional data screens based on specific data input. M 1 2 3 4

WI13 Vendor Response: Providing a means to request only the information from a user required for the current request enhances the user’s experience with a system and facilitates the accurate entry of data into that system. One important way to implement this is identify where additional data is required base on the user’s data or selections. PSDC’s permitting system allows for such important capabilities including configuration of additional data screen based on data input. This configuration can be done based on permit type. For example, if a permit is routed the system will require an origin and destination. See the response to requirement SA18for more information on configuration of input data based on permit type. The system also has additional data fields that contain such triggers. For example, if the user enters a gross vehicle weight in excess of legal, they will be prompted to enter axle weights and spacings. PSDC will work with Kansas personnel to identify and implement additional data fields where such triggers would be useful.

WI14 Required Fields The solution shall have the ability to highlight missing or invalid required elements upon transaction entry. M 1 2 3 4

WI14 Vendor Response: PSDC’s permitting system supports the identification of missing or invalid responses supplied by the user facilitating the accurate entry of permit applications. The system identifies such instances and does not allow the user to continue past the screen. PSDC’s system allows for the identification of required fields and valid entries based on permit type and for many standard fields such as phone number, email address, and ZIP code. See the response to requirement SA18 for more information on this configuration capability. PSDC will work with Kansas personnel to identify additional data fields where such checking can be provided.


Web interface


M/FO

Code

WI15 Auto-SuggestThe solution shall be able to auto-suggest information in permit application fields that is based on the user account or typical entries. For example, when a user begins to enter a VIN, the solution may use the portion entered to autosuggest VINs associated with the user account.

O 1 2 3 4

WI15 Vendor Response: PSDC’s system currently allows users to enter a variety of data using dropdowns. These dropdowns are populated using saved account data and system data. Examples of account data accessible this way include Unit number and contact information. Examples of system data accessible this way include (but is not limited to) vehicle make, permit type, tire size, and county. PSDC will work with State personnel to identify additional fields where this interface behavior is appropriate and to implement this using dropdowns with type-ahead search or other similar interface features. Required modifications include identification and implementation of such fields.

WI16 Wildcard search The solution shall be able to allow for wild card searches of relevant data fields. For example, a user may enter a partial VIN and does a wild card search to find the complete VIN. M 1 2 3 4

WI16 Vendor Response: One of the day-to-day challenges working with a large permitting operation is identification of records based on incomplete data. Performing searches using wild cards is one way of helping with this problem. PSDC’s permitting system allows for the search of data using wild cards. In addition to wild card searches, PSDC’s system allows users to search for values within the fields. For example a use could search for SMITH and this search would flag JOHN SMITH TRUCKING and WILLIAM SMITH TRUCK as well as SMITH & SONS TRUCKING. Note: this is identical to performing a search on *SMITH*. In addition to these search methods, PSDC’s system uses index fields without punctuation and spaces for searching. One of these fields is the company name. Finding companies starting with initials or letters can be particularly difficult. This search index field facilitates the search for companies such as A. J. Smith Trucking. By stripping out the punctuation and spaces in this index field, a user could find this company by entering any of the following:

A.J. Smith TruckingA. J. Smith TruckingA J Smith TruckingAJ Smith Trucking

WI17 Error Checking

The solution shall configure certain fields with error-checking routines to provide the user with feedback in the cases of incorrect or mis-keyed information. Examples of fields that would be appropriate for error-checking include dates, e-mail addresses, addresses, load types, USDOT and VIN numbers.

M/F 1 2 3 4


Web interface


M/FO

Code

WI17 Vendor Response: PSDC will work with the K-TRIPS management team during the design phase to identify fields that will require error-checking. PSDC will implement error-checking routines based on the requirements defined during the design phase.

WI18 Fatal Error Messages

The solution shall automatically alert the user of errors in the permit application that will prevent processing of the application. Examples include an invalid USDOT number, an Out of Service order against the carrier and invalid vehicle dimensions. The error messages shall be configurable by System Administrators.

M/F 1 2 3 4

WI18 Vendor Response: PSDC’s permitting system notifies the user of errors in the permit application. Current errors identified include:

Failure to fill in all fields Invalid vehicle dimensions based on the permit definition and envelope parameters Lack of operating authority

PSDC will implement additional checks including invalid USDOT number (see the response to requirement UD03 for more information), Out of Service flags (see the response to requirements SA14 for more information), and other items as identified by the State. PSDC will implement the capability for these messages to be configurable by System Administrators.

WI19 Hard Stop The solution shall not allow a permit application to proceed beyond the entry of a fatal error until the error is corrected by the user. M/F 1 2 3 4

WI19 Vendor Response: PSDC’s permit entry forms identify fatal errors in the entered data and notify the user of the problem. In addition, the forms will not continue until valid entries have been made in all fields. PSDC will work with Kansas staff to identify any additional fields that will require such checks.

WI20 Permit Wizard

The solution shall have a guided system available to users that allows them to enter information through a question-and-answer format. The guided system shall ask simple questions and automatically identify the type of permit and what data is needed based on the response given by the user.

M/F 1 2 3 4


Web interface


M/FO

Code

WI20 Vendor Response: PSDC permitting system has a configurable Permit Wizard to aid the user in identifying the permit needed for their operations. Authorized users are able to setup and modify the wizard screens. The wizard operates as a series of screens with simple,direct questions. The user is offered two or more options on each screen. Each of these options will either direct the user to another screen with more questions or will instruct the user as to which permit they will need. After the wizard has identified the necessary permit, when the user clicks the next screen, they will enter the first permit entry screen with that permit selected. Please see sample screenshots of the permit wizard in use and the definition screens for this wizard starting on page Error: Reference source not found of this response.

WI21 Advanced User Data Input

The solution shall allow experienced users to bypass the Permit Wizard and directly enter information into forms designed to allow for the quickest data entry. M/F 1 2 3 4

WI21 Vendor Response: In PSDC’s system, the Permit Wizard is optional. Users can either select the Permit Wizard or they can select the permit they need on the first permit entry screen.

WI22 Graphic Display - Map

The solution shall be able to display a map of Kansas and all state highways. The map display and legend shall be consistent with other digital maps provided by CANSYS. (See SI05.) M 1 2 3 4

WI22 Vendor Response: PSDC’s permitting system has the capability to display a map of Kansas including all state highways as well as city and county roads. PSDC will configure this map and its legend to meet the needs of the State. The map will be consistent with digital maps provided by CANSYS at all times as described in the response to requirement AR04.

WI23Map Information The solution shall be able to display on digital maps the names of all highways, cities, state

borders and other locations and landmarks. The names of all origin and destination locations available to users to select shall be available to view on the map.

M 1 2 3 4

WI23 Vendor Response: The map included with PSDC’s permitting system displays all of the items described in this requirement except for landmarks. PSDC will add the functionality for entering landmarks, as described in the response to requirement SA17, and the functionality to display landmarks in a manner of the State’s choosing.

WI24 Map Legend The solution shall be able to display a legend that describes map elements, including roadway types, map icons and scale. M 1 2 3 4

WI24 Vendor Response: PSDC’s mapping system includes a configurable legend that will be modified to include each of the map elements listed in this requirement.


Web interface


M/FO

Code

WI25 Map Manipulation The solution shall provide user tools to zoom and pan the map. Map rendering should be close to instantaneous. (See SD16.) M 1 2 3 4

WI25 Vendor Response: PSDC’s permitting system allows users to zoom and pan the map. Zoom in and zoom out are performed with a zoom slider, the mouse wheel, and with the + and - keys. Panning can be done by dragging the map (in a manner similar to Google maps), using the cardinal direction buttons, and using the arrow keys. See the section on page Error: Reference source not found for a screenshot illustrating these capabilities. With sufficient bandwidth, map draws are performed in hundreds of milliseconds.

WI26 Map Detail The solution shall provide increased map detail in descriptions, roadways, landmarks and other features as the user zooms in to display smaller sections of the map. M 1 2 3 4

WI26 Vendor Response: PSDC’s system increases the level of detail on the maps as the user zooms in. See the section on page Error: Reference source not found for sample screenshots as the map is zoomed in closer.

WI27 Restrictions and Warnings Display

The solution shall be able to graphically display locations with specific warnings and restrictions collected from KANROAD. (See SI06.) The warning and restriction icons may be clickable to display additional information on the restrictions and warnings. The display shall be available to users even if they are not currently analyzing routing for a trip.

M/F 1 2 3 4

WI27 Vendor Response: PSDC’s system has the capability to display restrictions and warnings on a web-based map. See the response to requirement AR24 for a screenshot of the graphical map and a description of the information provided. PSDC will add a link to the system providing access to this map with all current restrictions highlighted to provide this functionality.

WI28 Graphic Display – Vehicle

For oversized/overweight permit applications, the solution shall dynamically render a vehicle profile including the configuration and dimensions. The display shall show overall length, trailer length, axle spacing, wheels per axle, front and rear overhang, total weight and axle and group axle weights.

M/F 1 2 3 4


Web interface


M/FO

Code

WI28 Vendor Response: PSDC’s system has the capability of creating an image of the vehicle profile as described in this example. See the following section from a sample permit:

Note: the overhangs were marked as legal for this vehicle.

WI29 External LinksThe solution shall be able to provide links to other Kansas government websites, such as KANROAD, Kansas commercial vehicle regulations, KDOT, KTC and the Kansas Highway Patrol.

M/F 1 2 3 4

WI29 Vendor Response: PSDC will customize its solution to include links to other Kansas government websites as required by KDOT. Modifications required include adding such links.

WI30 Application Tracking

The solution shall allow users to track the process of a permit application once it has been submitted. When a user enters information to identify a permit application the solution shall display the stage of the process including action history dates/times, pending actions / requests and current permit status, anything needed from the applicant and how long it has been in process.

M/F 1 2 3 4

WI30 Vendor Response: PSDC’s permitting system tracks the process of a permit application. The application is tracked through the use of a status assigned to the permit. These statuses can be configured to the needs of the K-TRIPS system. Statuses change automatically as the permit reaches assigned steps in the workflow and State staff can manually change the status. All changes to the permit application, including statuses, are logged. Customer and State users are able to add notes to the permit identifying anything needed from the applicant and any responses from the applicant. A complete history, including timestamps of any changes of the application, can be viewed.


Web interface


M/FO

Code

WI31 Application Change Tracking

The solution shall highlight which elements of an application that have been changed by the applicant after it has been approved. The highlighting shall be visible to the applicant and to Kansas Staff. The purpose is to allow the applicant to verify the changes are as desired, and to allow Kansas staff to quickly see what has changed in order to determine how changes impact the previous permit analysis and approval.

M/F 1 2 3 4

WI31 Vendor Response: PSDC’s permitting system tracks all changes in the permit application and the permit. PSDC will work with the K-TRIPS management team to devise methods to identify changes in the application so that both the customer and Kansas Staff can quickly identify changes.

SA - Solution AdministrationSolution Administration


M/FO

Code

SA01 ConfigurabilityThe solution shall allow K-TRIPS System Administrators to configure the solution display, the information displayed and the parameters, formulas and rules used by the solution in decision making.

M 1 2 3 4

SA01 Vendor Response: PSDC will work with the K-TRIPS project management team to develop the appearance of the application and to identify those items that will be configurable using the administrative interface and can be changed without programming. Follows are examples of items that are currently configurable in PSDC’s permitting system:

Permit types, limits, and fee calculations Envelope for self-issue Permit entry forms Data storage limits Permit wizard


Solution Administration


M/FO

Code

Follows are examples of items not currently user configurable but can be designed as such:

Error messages Help instructions Links to other Kansas websites

SA02 Security RolesThe solution shall provide security-role-based access to functionality. For example, K-TRIPS Supervisors will have more access to functions and data elements than K-TRIPS Customers. Security roles shall also determine ability to edit / delete information within permits and accounts.

M 1 2 3 4

SA02 Vendor Response: PSDC’s permitting system employs a flexible role-based permission system to provide access to functionality including the ability to edit/delete information within permits and accounts. Please see the response to requirement UR01 for more information on this permission system.

SA03 Manage Online Instructions

The solution shall allow K-TRIPS Supervisors to manage and change the online instructions that are provided to users. M/F 1 2 3 4

SA03 Vendor Response: PSDC will work with State personnel to develop an interface allowing K-TRIPS supervisors to manage and change the online instructions that are provided to users.

SA04 Manage Warning and Error Messages

The solution shall allow K-TRIPS Supervisors to manage and change all system warning and error messages provided to users when application data is incorrect or otherwise triggers a warning message.

M/F 1 2 3 4

SA04 Vendor Response: PSDC will implement the warning and error messages in the application data screens using a table-based system. The system will have a tag to identify each error message and will also have an interface allowing supervisors to edit the message for each tag. For example, the error message that is displayed when the user enters a USDOT number that is not recognized by KSCVIEW may have a tag of USDOTERR01. There will be an interface allowing users to modify the message displayed when the system identifies the error with the tag of USDOTERR01.

SA05 Create Hard Stops The solution shall allow K-TRIPS Supervisors to configure “hard stop” errors that the solution shall not proceed beyond without the error being corrected. The errors defined as “hard stops”

M/F 1 2 3 4




M/FO

Code

shall include missing data and the results of carrier checks for valid registration, satisfactory safety ratings, non-payment, etc.

SA05 Vendor Response: PSDC will implement configuration parameters and interface for “hard stop” errors as directed by the K-TRIPS management team. This may include additional items on the permit definitions. See the response to requirement SA18 for more information on permit definitions. The configuration for “hard stop” errors may also be performed system wide in the Administrative interface.

SA06 Announcements

The solution shall allow K-TRIPS Supervisors to create, change and delete blanket announcements that shall be seen by all users upon logging in to the solution. Blanket announcements shall be displayed based on a date range selected by K-TRIPS Supervisors. The solution shall also allow K-TRIPS Supervisors to create, change and delete role-based announcements. Role-based announcements shall be displayed based on a date range selected by K-TRIPS Supervisors.

M/F 1 2 3 4

SA06 Vendor Response: PSDC’s system allows for announcements to be displayed to any user on their dashboard. The following is an example:




M/FO

Code

The system allows Supervisors to modify the messages and to assign dates for display. PSDC will add functionality to display announcements based on role.

SA07 Solution Table Maintenance

The solution shall allow KTC Supervisors to configure and modify solution data in tables that are consistent with the solution’s appearance. All business rules associated with permits, including dimensions and time constraints, shall be managed through updating tables within the solution.

M/F 1 2 3 4

SA07 Vendor Response: See the response to requirement SA18 for more information on the interface that controls business rules and constraints associated with the different permit types.

SA08 Commodity Types The solution shall allow for K-TRIPS Supervisors to maintain a list of commodity types for users to select from during permit application. M/F 1 2 3 4

SA08 Vendor Response: PSDC’s permitting system maintains a list of commodity types that users can select during the permit application process based on the permit type. This list is stored in a table and will be maintained by administrative users. See the response to requirement SA18 for more information on this




M/FO

Code

interface.

SA09 Batch Submission Management

The solution shall allow K-TRIPS Supervisors to manage batch permit submissions by setting permissions to allow or disallow allow the batch submission by each K-TRIPS Permit Service user.

M/F 1 2 3 4

SA09 Vendor Response: Please see the response to requirement for SI01 for details for this requirement.

SA10 Fee Table Maintenance The solution shall allow K-TRIPS Supervisors to configure and update fee tables. M/F 1 2 3 4

SA10 Vendor Response: PSDC’s permitting system allows supervisor users to configure virtually all aspects of permit type definitions. This includes the fee charged for a permit. PSDC’s system allows for multiple fees to be assigned to a permit and each of these fees can be assigned to separate funds or accounts. Modification of the permit definitions including the setting of the fees is accomplished using an easy to use interface. For more details on this interface see the response to requirement SA18.

SA11 Table-Driven Solution

The solution shall allow K-TRIPS Supervisors to maintain and modify all business rules, and special conditions related to the routing of over-size and overweight vehicles, by permit and route. M/F 1 2 3 4

SA11 Vendor Response: Please see the response to requirement SA18 for this requirement.

SA12 Schedule Batch Jobs

The solution shall have the ability for K-TRIPS Administrator to manage batch permit processing. This includes:

Scheduling batch jobs Controlling priority of batch jobs Controlling batch job execution by size of batch file, time of day, date, processing cycle

(weekly, monthly, yearly, quarterly, on request, etc.) and other parameters. Backup, recover, restart and cancel batch jobs

M/F 1 2 3 4


SA13 Third Party Files The solution shall have the ability to accept third party interface data files in a solution-compatible format such as flat file or XML. M 1 2 3 4




M/FO

Code


SA14 Flag Accounts

The solution shall allow K-TRIPS Supervisors and K-TRIPS Permit Agents to flag accounts using a list configurable list of flags. For example, flags for non-payment, suspended credentials and violations or Out of Service order. The authorized user may also enter a reason for flagging an account. Flags shall have start and end dates defined by the authorized user.

M/F 1 2 3 4

SA14 Vendor Response: PSDC will include this functionality in its permitting system if it is chosen as the solution provider. PSDC will work during the development of the system specifications to identify the configuration requirements for currently envisioned flags and develop a database and interface to manage these flags and the actions the system takes when the flags are set or cleared by authorized users.

SA15 Change Account Information

The solution shall allow K-TRIPS Supervisors and K-TRIPS Permit Agents to change information in user accounts. Change details shall be recorded in audit trails as described in the Audit Trails (AU) requirements.

M/F 1 2 3 4

SA15 Vendor Response: PSDC’s system allows users with sufficient permissions to change information in a user’s account. The system maintains a complete audit trail and has the ability for supervisors to view a snapshot of the user account data for any time and to identify when and who made any changes.

SA16 Solution Contact Information

The solution shall allow K-TRIPS Supervisors to change all contact information provided through the solution. The contacts may include, but are not limited to, support telephone numbers and e-mail addresses, links to Kansas agencies, district contact information and local jurisdiction contact information.

M/F 1 2 3 4

SA16 Vendor Response: PSDC will modify its system so that contact information including email address, links to Kansas agencies, district contact information and local jurisdiction contact information are stored in database tables and configurable using an Administrative interface. PSDC’s system allows for the storage of jurisdiction contact information for each jurisdiction (district, county, and city) within the State and for assigning such contact information to each road segment allowing the system to identify contact information for any trip within the state. PSDC anticipates the functionality for this requirement will be an extension of this existing capability. Required modifications include identification of the expanded functionality and extension of existing capabilities within the existing system.

SA17 Identify LocationsThe solution shall allow K-TRIPS Supervisors to give physical Kansas locations new names using both a clickable map and text entry of highways and mileposts or addresses. The purpose of this will be to allow the solution to identify locations using common names.

M/F 1 2 3 4

SA17 Vendor Response: PSDC will modify its mapping system with the inclusion of a system allowing for naming Kansas locations. PSDC will implement both




M/FO

Code

a map interface allow the user to click on a physical position of the location and an interface for text entry using highways and mileposts of addresses. Each location will be resolved to a unique latitude and longitude for routing and mapping purposes. PSDC’s routing system is capable of routing to and from any latitude/longitude location within the boundaries of the state. Required modifications include the modification of the mapping interface and the creation of a text entry interface.

SA18 Permit Definition The solution shall allow K-TRIPS Administrators to define new types of permits and establish their parameters and the data required to process and issue them. M 1 2 3 4


SA18 Vendor Response: The types of permits and parameters that are issued by a state can change at any time and they sometimes change on short notice. Because of this reality, the permits that can be issued by PSDC’s permitting system and their parameters are defined using tables and can be changed using an interface accessible to system Administrators. The following is a list of parameters that can be configured when defining a new or existing permit

Permit name Permit description Start and end dates Size limits (length/width/height/GVW/etc) both minimum and maximum Preset size values Preset load descriptions Whether the permit requires routing Whether the permit can be self-issued Fees Moving authority requirements (bond/MCR number/etc) Whether the permit can be used in conjunction with other permits Whether the permit requires a specific truck/trailer Other required entry data for the permit Length of time the permit is valid for Whether a temporary registration can be requested with the permit Special items for specific permits Permit conditions Pilot vehicle requirements

All of these parameters can be changed using the system interface. The following screen illustrates this interface:


The following screenshot illustrates Assignment of permit conditions to a permit:


PSDC’s permitting system provides for flexible entry of permit fees. This includes the ability to implement multiple fees for a single permit. Fees can be separated into different funds. The following screenshot illustrates a permit with multiple fees separated into different State funds:

Fee amounts can be defined using formulas allowing for the easy configuration of complicated fee requirements as illustrated above.

PSDC will implement such changes in the permit definition functionality and interface as are required for the solution.

SA19 Legal DimensionsThe solution shall allow K-TRIPS Supervisors to define and manage the maximum dimensions allowed for vehicles before they are considered oversize/overweight and require oversize/overweight permits.

M/F 1 2 3 4

SA19 Vendor Response: PSDC’s system stores envelope limits for defining oversize/overweight loads. Currently the system allows for the following dimensions:

Height Length Width Front overhang Rear overhang Trailer length


Gross vehicle weight Axle weight Tandem weight Tridem weight 4 axle combination weight 5 axle combination weight 6 axle combination weight Exceeds NBI bridge limitations Pounds per linear inch of tire width

PSDC will add additional dimensions/requirements as needed for the solution.

SA20 Routing DimensionsThe solution shall allow K-TRIPS Supervisors to define and manage the maximum dimensions allowed for vehicles before they require either system or manual routing. Note that these limits may be higher than those that require the purchase of an oversize/overweight permit.

M/F 1 2 3 4

SA20 Vendor Response: PSDC’s system has a set of envelope dimensions that control whether a permit requires manual routing. These envelope dimensions can be configured using the Administrative interface and can be set to virtually any value.

SA21 Automated Routing The solution shall allow K-TRIPS Supervisors to define and manage dimensions or road segments that automatically trigger a manual review by Kansas staff before permit issuance. M/F 1 2 3 4

SA21 Vendor Response: PSDC’s restriction management system allows for the storage of specific dimensions for any road segments that require manual review by Kansas staff. This capability can be applied to all permit loads.

SA22 Superload Dimensions

The solution shall allow K-TRIPS Supervisors to define and manage the maximum dimensions allowed for vehicles before they are considered Superloads and must be processed as Superload permit applications.

M/F 1 2 3 4

SA22 Vendor Response: PSDC’s system has a comprehensive functionality allowing administrators to define and configure permit types and requirements. This functionality is described in detail in the response to requirement SA18. This functionality will preclude loads exceeding Administrator configured dimensions from being processed as anything other than a Superload permit.

SA23 Large Structure Dimensions

The solution shall allow K-TRIPS Supervisors to define and manage the maximum dimensions allowed for vehicles before they are considered large structures and must be processed as large structure permit applications.

M/F 1 2 3 4


SA23 Vendor Response: PSDC’s system has a comprehensive functionality allowing administrators to define and configure permit types and requirements. This functionality is described in detail in the response to requirement SA18. This functionality will preclude loads exceeding Administrator configured dimensions from being processed as anything other than a large structures permit.

SA24 Commodity Type The solution shall allow K-TRIPS Supervisors to define and manage the descriptions of commodity types that users may select from when applying for a permit. M/F 1 2 3 4

SA24 Vendor Response: PSDC’s will add a commodity definition to its commodity type table and will create an interface for Administrators to maintain it.

SA25 OverrideThe solution shall allow K-TRIPS Supervisors to override the approval or rejection of a permit application. Any override will be logged and the application audit trail shall indicate the authorized user who overrode the application, the time and the reason for overriding.

M/F 1 2 3 4

SA25 Vendor Response: PSDC’s permitting system allows for the overriding of virtually any business rule by users with the proper authority and requires a reason for the action to be entered. This authority will be added to the K-TRIPS supervisor role. This includes the ability to approve or reject a permit application. All changes to permit applications and permits are logged in the system’s audit trail.

SA26 Permit Changes

The solution shall allow K-TRIPS Supervisors to change existing permits, only when the changes are valid and do not change the cost or type of permit. Any change to a permit will be logged and the permit audit trail shall indicate the authorized user who changed the permit, the time of the change and the reason for the change.

M/F 1 2 3 4

SA26 Vendor Response: PSDC will implement this capability as described in this requirement. Every change in a permit creates an audit trail record indicating the type of change, the user who made the change, timestamp, and reason. The audit trail is searchable and reports can be generated from it.

SA27 Void/Cancel

The solution shall allow K-TRIPS Supervisors to void, cancel or adjust the fee for an issued permit. Any void, cancellation or fee adjustment will be logged and the permit audit trail shall indicate the authorized user who voided or canceled the permit, the time and the reason for overriding.

M/F 1 2 3 4

SA27 Vendor Response: PSDC’s system allows authorized users to void, cancel, and adjust fees for an issued permit. The system maintains an audit trail of such voids, cancelations, and adjustments and can produce reports from this data. The system records a timestamp of the action and requires the user to enter a reason.

SA28 Permit Application Queue

The solution shall be able to display to all agency users the permit applications that are in queue. The queue shall show, at a minimum:

- The permit application number- The permit type

M/F 1 2 3 4


- The requested permit dates - The applicant’s name- The carrier to whom the permit will be issued- Current permit process status with history- If permit application is currently “checked-out” by another user

SA28 Vendor Response: PSDC’s system provides a method for agency users to view all permit queue’s in the system. The system is able to display all of the fields listed in this requirement. Screenshots of permit queues can be found starting on page Error: Reference source not found of this response.

SA29Permit ProcessLock-Out

The solution shall lock out other users from changing a permit application if a user with security clearance “checks out” a permit for review. The solution shall allow a user with a K-TRIPS Supervisor security role to override a lock at any time.

M/F 1 2 3 4

SA 29 Vendor Response: PSDC’s system maintains a record lockout mechanism allowing only one user to modify a record at a time. Supervisors are able to override or release this record lock.

SA30 Configurable Archive Recall

The solution shall allow System Administrators to configure the length of history a customer can recall for reporting. The purpose is to limit the size of reports and queries generated by customers.

M/F 1 2 3 4

SA30 Vendor Response: PSDC’s system has the ability to configure the length of history a customer can recall. This time value can be changed by Supervisors without any programming changes.

SA31 Trouble Tickets

The vendor shall provide a “trouble ticket” system that allows authorized Kansas staff to submit solution issues to the vendor. The trouble ticket system shall allow Kansas staff to track, at a minimum, the status of the ticket, its submission date and resolution date, the submitter and the vendor staff assigned to address it.

M/F 1 2 3 4

SA31 Vendor Response: PSDC maintains an on-line help ticket tracking system. This system will be modified to meet the needs of the K-TRIPS project and system. For more information on this requirement see the response to requirement SM06.


KD - Kansas Staff Permit Data EntryKansas Staff Permit Data Entry


MM/F

OCode

KD01 Data AccessThe solution shall allow K-TRIPS Permit Agents to access data associated with a K-TRIPS Account Holder for the purpose of developing a permit application. This includes permit templates, route templates and carrier and vehicle information.

M/F 1 2 3 4

KD01 Vendor Response: PSDC’s permitting system allows State users with proper permission to access all Account Holder data.

KD02 Auto-PopulateThe solution shall auto-populate fields using data from a permit applicant’s account for K-TRIPS Permit Agents, if the permit applicant has an account. The K-TRIPS Permit Agents may edit the auto-populated data in the permit application.

M/F 1 2 3 4

KD02 Vendor Response: PSDC’s system provides all of the functionality available to customer users to state users. See the response to requirement UD05 for more information for this requirement.

KD03 Application Template The solution shall allow K-TRIPS Permit Agents to create, edit, save and delete and recall permit application templates. The templates shall be available to other Kansas Staff. M/F 1 2 3 4


KD04 Incomplete Applications

The solution shall allow K-TRIPS Permit Agents to view and modify a user’s incomplete permit application. O 1 2 3 4



Kansas Staff Permit Data EntryRef # Requirement Description

MM/F

OCode

KD05 Vehicle Profiles

The solution shall allow K-TRIPS Permit Agents to create, save , delete and recall vehicle profiles that include:

- VIN- Make- Year- Type (T, TK, TT, SME, OR, etc.)- Plate Number- Plate State- Unit Number- Kansas Registered Gross Vehicle Weight

When a user recalls a vehicle profile, the solution shall automatically populate a permit application with the vehicle data. The user shall be able to edit each populated field for each vehicle.

M/F 1 2 3 4

KD05 Vendor Response: PSDC’s permitting system includes the ability to store vehicle information including all of the fields listed above. Permit agents can perform all of the actions listed above. When a user selects a vehicle on a permit application using the unit number, all stored information is populated. See the response to requirement UD15 for a screenshot.

KD06 Revoke Permits The solution shall allow K-TRIPS Supervisors the ability to revoke permits for a configurable period of time. The solution shall also allow K-TRIPS Supervisors to reinstate revoked permits. M/F 1 2 3 4

KD06 Vendor Response: PSDC will add the capability described in this requirement to its permitting system.

KD07 Revocation Flags The solution shall allow configurable revocation flags for vehicle, carrier, and account levels. M/F 1 2 3 4KD07 Vendor Response: See the response to requirement SA14 for this requirement.

KD08 Contact InformationThe solution shall allow KDOT Bridge Evaluator Users and KDOT District Coordinators to add multiple e-mail contacts to Superload and Large Structure permit applications. The solution shall automatically notify the contacts when the permit is issued.

O 1 2 3 4

KD08 Vendor Response: PSDC will implement this capability to aid the workflow for Superload and Large Structure permits. Modifications include addition of a table allowing essentially unlimited number of email addresses to be added to a permit, functionality to add these emails to the permit, and the functionality to notify each of these contacts when the permit is issued.


Kansas Staff Permit Data EntryRef # Requirement Description

MM/F

OCode

KD09 Pilot Vehicle Requirement

The solution shall allow KDOT Bridge Evaluators to indicate the number of pilot vehicles that will be required for a Superload trip. Providing the number of pilot vehicles indicated by KDOT Bridge Evaluators shall become a requirement of the permit application to be completed by the applicant. (See requirements Section PV.)

M/F 1 2 3 4

KD09 Vendor Response: PSDC has functionality allowing authorized users to change the number of Pilot Vehicles required for a permit. Bridge Evaluators will have this permission.

KD10 District Coordinator Approval

The solution shall allow District Coordinators the ability to approve or reject and add notes to Superload and Large Structure permit applications that travel through their districts. The solution shall track District Coordinator approvals and not issue a permit without all required approvals or an override.

M/F 1 2 3 4

KD10 Vendor Response: PSDC’s system is designed to allow District Coordinators to work with the Superload and Large Structure permit process. The system will identify the districts the permit is routed through using the route, and PSDC will modify the system to require approval from such District Coordinators before the permit it issued. The system allows for multiple users to approve or reject a permit and allows for essentially unlimited number of notes to be assigned to a permit.

KD11 Bridge Evaluation Router Validation

The solution shall allow a second Bridge Evaluation Router to indicate on Superload permit applications that he has reviewed and approved the analysis of another Bridge Evaluation Router. The solution shall not issue Superload permits without the validation of a second Bridge Evaluation Router, or the override of a Supervisor.

M/F 1 2 3 4

KD11 Vendor Response: PSDC will modify its system to require 2 different users with the Bridge Evaluation Router role assigned to them to issue a Superload. Alternatively, the system will allow a Supervisor to approve the permit. Required modifications include implementation of this check before issuing the permit and an interface to identify all users who have approved or rejected a permit application.


UD - User Permit Data EntryNote: For the purpose of these requirements, the user is defined as users with the roles of K-TRIPS Permit Agent, K-TRIPS Account Holder, K-TRIPS Account User, K-TRIPS Permit Service Account Holder, K-TRIPS Permit Service User and K-TRIPS Pilot Vehicle Service except where otherwise indicated.

User Permit Data EntryRef # Requirement Description

MM/F

OCode

UD01 Create Account The solution shall allow users to enter all required information to create a carrier or permit service account. M 1 2 3 4

UD01 Vendor Response: PSDC’s permitting system allows users to enter all required information to create a carrier or permit service account.

UD02 Change Account Information

The solution shall allow users to change name, contact and vehicle information in their own accounts. M 1 2 3 4

UD02 Vendor Response: PSDC’s permitting system allows users to change name, contact, and vehicle information in their own accounts.

UD03 USDOT NumberThe solution shall require a permit applicant to identify the carrier responsible for safety of the load through a USDOT Number. For carriers without a USDOT Number, the solution shall issue a “default” number that will identify the carrier.

M 1 2 3 4

UD03 Vendor Response: PSDC will implement a method for the applicant to identify the carrier using the USDOT number and will work with State staff to determine the methods to identify those carriers without a USDOT number. PSDC will implement these methods insuring that each permit uniquely identifies the carrier responsible for safety of the load.

UD04 Permit Data Once the solution or user identifies the permit type being applied for, the solution shall only collect the data necessary for that permit type. M/F 1 2 3 4

UD04 Vendor Response: Using the permit definitions, see the response to requirement SA18, PSDC’s permitting system only collects the data necessary for the permit type applied for. For example, if the permit type does not allow for weight, the system will not ask for axle spacing and weight.

UD05 Auto-Populate The solution shall be able to auto-populate information fields in a permit application based on the user account. The user shall be able to edit auto-populated entries. M/F 1 2 3 4



MM/F

OCode

UD05 Vendor Response: PSDC’s permitting system auto-populates fields in the permit application forms using data from the user’s account and allows for editing.

UD06 Application Templates

The solution shall allow the user to save permit applications as templates that can be recalled by the user. The solution shall allow the user to retrieve and edit the data in the template for each new application. The solution shall allow the user to sort the list by data, route, VIN.

M/F 1 2 3 4

UD06 Vendor Response: PSDC will add the capability for customers to save permit applications as templates that can be reused by the customer. When the template permit is retrieved, the user will be able to make any changes for the new permit. PSDC will work with the K-TRIPS team to design this interface.

UD07 Copy Permits The solution shall allow the user to recall the user’s previous permits to use as templates for new permits. M/F 1 2 3 4

UD07 Vendor Response: Being able to use permit templates for new permit applications is an important time saving feature for a permitting system. PSDC’s permit system has the ability to ‘copy’ a permit a customer has applied for. The copied permit is then used as a template for the new permit application. All data on the new permit application can be changed. All lists of permits can be sorted by each field. See the screenshot on page Error: Reference source not found for an example.

UD08Route Templates The solution shall allow the user (including Bridge Evaluator Users) to save trip routes as templates

that can be recalled by the user. The solution shall allow the user to retrieve and edit the route in new permit applications or for route analysis.

M/F 1 2 3 4

UD08 Vendor Response: PSDC’s permitting system allows users to save routes that can be recalled for permit applications. During the permit application process for the new permit, users are able to change the route. Recalled routes will be verified against current restrictions.

UD09 Template Deletion The solution shall allow users to delete templates that they have previously saved. M/F 1 2 3 4

UD09 Vendor Response: PSDC will implement the ability for a user to delete templates.

UD10 Incomplete Applications

The solution shall save the data entered in incomplete permit applications and allow the user to continue from the point of incompletion at a later time. M/F 1 2 3 4

UD10 Vendor Response: PSDC’s permit system allows users to save incomplete permit applications for later use. When the user recalls one of the permit applications, the system continues from that point on, although it allows users to go back in the application process to change data previously entered.



MM/F

OCode

UD11Incomplete Application Deletion

The solution shall delete incomplete applications after a configurable period of inactivity on the application. M/F 1 2 3 4

UD11 Vendor Response: PSDC’s permitting system deletes incomplete application after a configurable period of inactivity. The period can be configured by administrative users.

UD12 Draft Permits

The solution shall allow a user to save a permit application that is complete and approved, but not yet paid for, as a draft permit. The solution shall allow the user to recall draft permits for amendment, payment and issuance up until the first date for which the permit is valid. Permits requiring routing will have varying time limits for amendments. For example, changes to an application that require new routing analysis cannot happen less than one business day before the permit’s first valid date. A Superload or large structure permit cannot have changes that require new analysis within a configurable number of days of the first date the permit would be valid.

M/F 1 2 3 4

UD12 Vendor Response: PSDC’s system is designed with the capability for users to save draft permit applications and then to change, pay for, and issue up to the activation day for the permit. PSDC will work with the K-TRIPS management team to identify the details for this capability as needed by the State of Kansas and the Kansas OS/OW carriers. These details will include the number of days prior to the activation date that the route can be changed based on permit type and possibly vehicle and load parameters. PSDC will implement the details so identified.

UD13 Application Attachments

The solution shall allow users to submit attachments with their applications. The solution shall accept PDF, JPG, PNG and TIF formats and have a system for detecting and preventing malware or viruses from being submitted. Attachments shall be associated with the permit application such that a Kansas staff member viewing the application is able to recall and view the attachment submitted with it.

The number of attachments and total size of all attachments shall be a configurable parameter.

M/F 1 2 3 4

UD13 Vendor Response: PSDC’s permitting system allows users to submit documents of various types to a permit application and for viewing and printing these documents. PSDC’s system accepts each file format listed in this requirement. PSDC will add software to detect and prevent preventing malware or viruses from being submitted. PSDC will also add functionality to limit the number and total size of all attachments and create an interface to set these values. Required modifications include the addition of a malware and virus identification system and the creation of attachment count and total size limitation functionality.



MM/F

OCode

UD14 Commodity Types The solution shall allow the user to select the commodity type from a pull-down menu. The solution shall also allow the user to provide additional detail through text entry. M/F 1 2 3 4

UD14 Vendor Response: PSDC’s system currently allows administrators to create and assign a list of commodities for each permit type. PSDC will modify its system to include a text entry box allowing users to provide additional data about the load. Required modifications include an additional test entry field, a field in the database to store such data, and the ability to print the field on the permit and in reports.

UD15 Vehicle Profiles

The solution shall allow a user to create, edit, save , delete and recall vehicle profiles that include:- VIN- Make- Type (T, TK, TT, SME, OR, etc.)- Year- Plate Number- Plate State- Unit Number- Kansas Registered Gross Vehicle Weight

When a user recalls a vehicle profile, the solution shall automatically populate a permit application with the vehicle data. The user shall be able to edit each populated field for each vehicle.

M/F 1 2 3 4



MM/F

OCode

UD15 Vendor Response: PSDC’s permitting system includes the ability to store vehicle information including all of the fields listed above. Users can perform all of the actions listed above. When a user selects a vehicle on a permit application using the unit number, all stored information is populated. Follows is a screenshot showing displaying the listbox with stored vehicles for this customer:

After the user selects one of the vehicles, the data is auto-populated:

UD16 Emergency ContactThe solution shall require the user to enter an emergency contact telephone number and e-mail address on each permit application that the solution will use in the event a notification must be sent to a permit holder.

M/F 1 2 3 4

UD16 Vendor Response: PSDC’s system currently requires users to enter contact telephone number and e-mail address on each permit application.

UD17 Pilot Vehicle Selection

For those permits requiring escort vehicles, the solution shall allow the user to select permitted pilot vehicle service provider(s) from a list of company names with current pilot vehicle permits. M/F 1 2 3 4



MM/F

OCode

UD17 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow permit applicants to select pilot vehicle service providers from a list of companies with current pilot vehicle permits. This list will include the company name for each pilot vehicle service provider. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

UD18 Trip Report

The solution shall provide K-TRIPS Account Holders and Users the ability to complete and submit a trip report after completion of any trip requiring pilot vehicles. The solution shall collect in the information described in the report downloadable at http://www.ksdot.org/burTrafficEng/KTC/PDFs/EscortPostTripReport.pdf. The solution shall allow for the printing of reports consistent with the current format, and relate the trip report to the associated permit.

M/F 1 2 3 4

UD18 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow users to submit trip reports after completion of any trip requiring pilot vehicles. These reports will collect the information described in the current report and will be consistent with the current format. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

http://www.ksdot.org/burTrafficEng/KTC/PDFs/EscortPostTripReport.pdf


AR - Automated RoutingAutomated Routing


M/FO

Code

AR01 Automated RoutingThe solution shall attempt to automatically route all trips requiring routing for which an origin and destination are provided. The solution shall review and validate or reject routing suggested by a user.

M 1 2 3 4

AR01 Vendor Response: PSDC’s permitting system is based on a complete OS/OW routing package. As part of the permitting process, all permit applications which require routing are attempted to be routed. The system provides a number of means for the user to modify the route. These methods are described in the response to requirement AR14.

AR02 Roadway Naming The solution shall follow Kansas conventions for the naming of Interstates, U.S. highways and state highways. Naming shall be consistent with the naming in KANROAD and CANSYS. M 1 2 3 4

AR02 Vendor Response: PSDC’s routing and mapping engine has been modified to meet the naming conventions of DOT’s from other jurisdictions and if the State chooses PSDC as its vendor, PSDC will make such modifications as necessary to be consistent with the naming in KANROAD and CANSYS.

AR03 Reference Posts The solutions shall follow Kansas Department of Transportation’s linear referencing, as presented in CANSYS, to ensure consistency with other Kansas GIS. M 1 2 3 4

AR03 Vendor Response: Please see the response to requirement AR04 for this requirement.

AR04 GIS Data Source The solution shall be consistent with the roadways and their characteristics in CANSYS at all times. M 1 2 3 4

AR04 Vendor Response: An accurate and complete routing database is essential to the success of an OS/OW routing system. This database needs to accurately represent the highway network that the jurisdiction has authority to route OS/OW trucks. This database forms the basis for the restrictions, should provide driving directions, and ideally should include a GIS component allowing for display of maps including the route on the map and for the location of routing points using addresses, intersections, and clicking on a map. This routing database must support routing and thus have connectivity where it exists in the world, and needs to support such items as directionality, turn restrictions, and should have complete ramp, interchange, and frontage road structures.

PSDC has 17 years experience in routing heavy trucks using a variety of sources and is ready to assist the K-TRIPS team to identify and implement a routing database that can be used as the basis of the K-TRIPS system that will also support mapping and the rest of the features needed to successfully route OS/OW loads in Kansas.


Automated Routing


M/FO

Code

In addition to the above requirements for the routing database, PSDC recognizes that it must be consistent with the roadways and their characteristics in CANSYS at all times.

PSDC tentatively proposes the following suggestions for the K-TRIPS routing database. The suggestions are separated into two categories: The first category assumes that the CANSYS database has routing. The second category assumes that the CANSYS database does not have routing.

Category 1 – the CANSYS database has routing

PSDC will implement routing for K-TRIPS using a network built from the CANSYS data. PSDC will include all data present in the CANSYS data including the KDOT’s linear referencing in the data used by PSDC’s routing engines. PSDC will implement database access to the linear reference data allowing users to select road segments using this reference system. PSDC will use its large team of GIS routing specialists and long years of experience to help the State ensure that routing is accurate using the CANSYS data. PSDC proposes the following recommendations for adding the city and county highways on the maps to facilitate the identification of intersections:

Data source Description/advantages and disadvantages

Tele Atlas data The Tele Atlas data can be licensed to provide these roads. PSDC will identify and exclude any roads that are included in the CANSYS database. PSDC will provide a means for users to identify which roads are part of the State highway network and which are provided for support. The Tele Atlas data is very accurate and if it is included, it can be used for geocoding, see the response to requirement AR18. The disadvantage is that licensing the data can be expensive for the limited purpose of displaying city and county roads and geocoding.

Tiger data Tiger data is a comprehensive GIS database made freely available by the US Census Bureau. PSDC can use this for the source for the State highway network. As with the Tele Atlas option, PSDC will provide a means for users to identify which roads are part of the State highway network and it can be used for geocoding, see the response to requirement AR18. Tiger data generally is not as up-to-date as Tele Atlas data but for the purposes here PSDC believes it would be sufficient.

Category 2 – the CANSYS database does not have routing

PSDC proposes the following options for creating a routing database for the K-TRIPS system:


Automated Routing


M/FO

Code

Data source Description/advantages and disadvantagesCANSYS In this option, PSDC will add routing to the CANSYS database. This will include insuring connectivity and

verify completeness of the intersections, ramps, and other connecting structures. PSDC will create or validate Z-level and one-way information. PSDC will provide this data to the Department and work with the department to ensure accuracy. There is an additional charge for this work. The options for providing the city and county roads are the same as in Category 1 above.

Tele Atlas data The Tele Atlas data can be licensed to provide this routing. Tele Atlas has a very high quality routing database that is used in millions of navigation devices. PSDC uses the Tele Atlas database as the basis for routing for the Texas system. PSDC will identify those roads that are part of the State highway network and will conflate the CANSYS data to these road segments as described below. The Tele Atlas data can be used for geocoding, see the response to requirement AR18, and includes all city and county roads. Another advantage is that Tele Atlas maintains this data and it can be updated quarterly. The disadvantage is that licensing the data is the most expensive option.

Tiger data Tiger data is a comprehensive GIS database made freely available by the US Census Bureau. The Tiger data is very comprehensive but does not include routing. PSDC has created routing on Tiger data before and could create routing on the Kansas state highway network. To accomplish this, PSDC will perform the following tasks:

Identify those road segments that are part of the State highway network Add directionality to the road segments Add turn restrictions to the road segments Add Z-level information to the intersections of roads Validate routing

After PSDC has added routing to the Tiger data, PSDC will conflate the CANSYS data to these road segments as described below. As with the Tele Atlas option, the Tiger data can be used for geocoding, see the response to requirement AR18, and includes all city and county roads. Tiger data generally is not as up-to-date as Tele Atlas data but for the purposes here PSDC believes it would be sufficient. There will be a charge for creating routing on the Tiger data. The advantage to Tiger data is that it is less expensive than Tele Atlas data.


Automated Routing


M/FO

Code

PSDC will work with the K-TRIPS team during the design phase of the project to identify and implement a source for the routing database that meets the State’s specifications and needs. The source may be one of the sources described above or may be different from any of these options.

If Tele Atlas or Tiger is used for routing, PSDC will conflate the CANSYS data to the routing database. The conflation will be verified using automated and manual processes. This will ensure that all of the CANSYS data is accurately represented in the routing database and PSDC will develop and implement procedures to ensure that updates to the CANSYS are promptly implemented. PSDC will ensure that each road segment in the routing database will contain unique linear reference information that corresponds to the linear reference information in the CANSYS data for the road segment in the CANSYS database that represents that section of highway in the real world. In addition to all other data found in the CANSYS data, PSDC will use the road names for the road segment part of the State highway network from the CANSYS data and not from the alternate data source. PSDC currently conflates substantial data from TxDOT’s GIS data to the routing database for the TxPROS system.

PSDC answered this requirement with both a code of a 2 and a 3 because some of the options described above include additional charges and some do not.

AR05 Available Roadways

The solution shall include Interstates, U.S. and state highways in Kansas for routing. City and county roads shall not be analyzed for restrictions and shall not be included in permit routing instructions. Where a portion of a vehicle trip is in a city or county, the solution shall indicate only “Local Roads” in the routing instructions for that portion

M/F 1 2 3 4

AR05 Vendor Response: PSDC will comply with this requirement.

AR06 Concurrent Roadways

The solution shall list all Interstate, U.S. and state highway names where the roadways are concurrent. The listing of roadway names shall be in the order of Interstate first, U.S. highway second and state highway third. Where more than one of the same type of roadway is concurrent, the solution shall list the lowest numbered roadway first.

M/F 1 2 3 4

AR06 Vendor Response: PSDC’s mapping system has the capability to label roads with multiple shields as illustrated below.


Automated Routing


M/FO

Code


Automated Routing


M/FO

Code

AR07Highway Entrances, Exits and Interchanges

The solution shall be able to display highway entrances, exits and interchanges. M/F 1 2 3 4

AR07 Vendor Response: PSDC’s mapping solution is able to display all roadbeds. The following screenshot illustrates a complicated interchange with highway entrances and exits:


Automated Routing


M/FO

Code


Automated Routing


M/FO

Code

AR08 Routing Preference

The solution shall allow K-TRIPS Supervisors, Bridge Evaluation Supervisor, Bridge Evaluation Routers and Large Structure District Coordinators to configure the criteria used for determining the most appropriate acceptable routing. The solution shall allow for different routing algorithms for different trip types, e.g. oversize/overweight, Superloads and large structures. The authorized users will be able to adjust the routing algorithms and weights given to routing optimization criteria.

M/F 1 2 3 4

AR08 Vendor Response: PSDC will work with Kansas staff to identify routing algorithms and parameters that they may wish to configure. Such factors may include but will not be limited to the following:

Road class Lane count and width Pavement type Shoulders Turning radii Turn angle Setting impedance on individual road segments Allow contra-flow travel

Using this list, PSDC will develop a web-based graphical interface allowing State personnel to experiment with these parameters. This interface will allow users to enter origins and destinations and have slide controls or other methods allowing for the configuration of the parameters. As the users adjust the parameters, the interface will redraw the calculated route based on the parameters. There will be a method to save the parameters and recall them at a later time.

AR09 Trip Mileage For the purpose of measuring trip distance, the solution shall measure the distance using only the segments on the state highway network. The solution shall not assume travel on city/county roads. M 1 2 3 4

AR09 Vendor Response: PSDC will comply with this requirement. Required modifications are to not include distance on non state highways.


Automated Routing


M/FO

Code

AR10 Vehicle Dimensions

The solution shall use the following vehicle characteristics for assessing the impact of restrictions and bridge analysis on a vehicle:- Overall length

- Trailer length

- Front and rear overhangs

- Number of axles and axle spacing

- Axle width

- Maximum vehicle width

- Maximum vehicle height

- Overall weight and axle weights (GVW)

- Axle Weights

- Internal Spacings

- Group Spacing

- Tires/Axle

- Total Axle Number

M/F 1 2 3 4

AR10 Vendor Response: PSDC’s system takes into account each of the above vehicle and load characteristics when routing a load. The interface allows for the user to enter each of these characteristics and takes all into account when routing. The system operates using the following steps:

1. User enters vehicle and load characteristics.2. PSDC’s system submits this list to a store procedure which identifies all restrictions that violate one or more of the restrictions active during the time

period the permit is valid.3. PSDC’s system then creates a list of road segments assigned to one or more restrictions identified in step 2.4. PSDC’s system then routes the load, if possible, disallowing travel on each road segment identified in step 3.5. Each of the road segments identified in step 3 can be displayed on a map as shown in the response to requirement AR24.6. Finally, PSDC’s system routes the load without any restrictions and records the list of restrictions identified in step 2 with road segments along the route


Automated Routing


M/FO

Code

generated in this step. This list of restrictions is identified and can be displayed to the user.

Note: PSDC can use weights other than completely disallow travel in step 4 above. For example, the system could use a weight of 1000 to allow travel on a road segment only if absolutely necessary. These weights will be adjustable as described in the response to requirement AR34.

AR11 Weight AnalysisThe solution shall automatically identify permit applications for vehicles that exceed in total or by axle the Superload limits and interface with the state’s bridge analysis application, Virtis, to perform bridge analysis and identify any restrictions by roadway segment. (See SI 107.)

M/F 1 2 3 4

AR11 Vendor Response: PSDC’s permitting system allows Administrative users to define permits including weight limits by axle or total weight. The system also enables permits to require bridge analysis. Using the permit definitions, PSDC’s permitting system can be configured to require bridge analysis for vehicles that exceed the Superload limits. Virtis interface requirements are addressed in the response to SI07.

AR12 Statewide Weight Analysis Study

The solution shall allow users with the Bridge Evaluation Supervisor and Bridge Evaluation Router roles to analyze bridges in the state for an entered vehicle size and weight. The solution shall allow for the user to enter a truck’s axle spacing and weights and then add the bridges. The solution shall allow the user to select bridges to be studied by KDOT District, KDOT District Area, county, route, bridge type or individual bridges. Output shall include the location of the bridge, controlling factor, where along the bridge the controlling factor is located and any warning associated with the bridge.This will be accomplished through an interface to Virtis. (See SI107.)

M/F 1 2 3 4

AR12 Vendor Response: PSDC will add an interface to Virtis to its permitting system as described in the response to requirement SI07. PSDC will work with the K-TRIPS management team to define an interface that will allow users with the Bridge Evaluation Supervisor and Bridge Evaluation Router roles to analyze bridges in the state for an entered vehicle size and weight. This interface will use the interface to Virtis to obtain bridge data and to evaluate the effect such a vehicle will have on the bridge.

AR13 Over-Dimension Restrictions

The solution shall use the length, width, vertical and weight restrictions on roadways contained in CANSYS, KANROAD and directly entered into the solution to analyze routing and identify restrictions on a route based on length, width, height and weight.

M/F 1 2 3 4

AR13 Vendor Response: Please see the responses to requirements AR04, AR23, and SI06 for this requirement.


Automated Routing


M/FO

Code

AR14 Origin/Destination Selection

The solution shall allow a user to select an origin or destination by landmark, address or location on highways graphically or textually. The applicant shall be required to indicate where the trip will enter and exit the state highway system. Landmarks shall be commercial-vehicle oriented locations such as state borders, interchanges and common locations that truck trips begin and end.

M/F 1 2 3 4

AR14 Vendor Response: PSDC’s system currently allows users to select an origin or destination using the following methods:

Address (enter address, city, ZIP code) Intersection of roads (enter two roads and optionally a city name) Border crossing (using a dropdown list) Enter a latitude/longitude location (using two numbers) Click on the map (any arbitrary location within the State)

PSDC will implement an interface allowing users to select landmarks based on the list of landmarks entered into the system as described in the response to requirement SA17. If the location the user selects is not on the state highway system, PSDC will implement a method for the user to identify where they will enter and leave the state highway system. Addressing options and capabilities are discussed in the response to requirement AR18 of the RFP. PSDC will work with the K-TRIPS management team to identify an interface for identifying land marks. The interface may utilize one of the following:

Simple dropdown list Quick lookup (user types in the first few letters of the landmark and the interface provides the user with list of landmarks that start with those letters) Identify the landmarks using a county of city list Other methods as identified

Methods for identify the point where the load enters and leaves the state highway system may include:

Clicking on the map Intersection Identification of the closest point on the state highway network Other methods as identified

All of these decisions will be made by PSDC working with State personnel using interface prototypes developed by PSDC and reviewed by State personnel.


Automated Routing


M/FO

Code

AR15Route Selection

The solution shall allow a user to select a desired route to be analyzed for its trip graphically, through a map-based tool, or through text entry. M/F 1 2 3 4

AR15 Vendor Response: PSDC’s system allows the user to click on the map to select a desired route for an OS/OW load. A discussion of the text entry method for selecting a desired route is included in the response to requirement AR16.

AR16 Route Through The solution shall allow a user to specify route through points such as a city or specific highway M 1 2 3 4


Automated Routing


M/FO

Code

Points interchange or other identifying highway feature, between the origin and destination, that the user would like to have the trip routed through

AR16 Vendor Response: PSDC’s permitting system allows users to identify VIA cities for specifying a route. PSDC will add the ability for users to use highway junctions and/or landmarks, as described in response SA17, as VIA locations.

Note: In addition to city VIA points, PSDC’s system allows users to enter highway names, latitude/longitude locations, and click on the map (See the response to requirement AR15) for VIA points.

AR17 Road Naming Convention

The solution shall recognize addresses entered using United States Postal Service-accepted road name abbreviations. For example, “RD” for “Road” and “BLVD” for Boulevard. M 1 2 3 4

AR17 Vendor Response: PSDC’s system implements a list of United States Postal Service-accepted road name abbreviations.

AR18 City and County Roadway Routing

When the origin and/or destination entered by a user are on a city or county road, the solution shall not give specific routing instructions for city and county roads. The solution shall begin all

M/F 1 2 3 4


Automated Routing


M/FO

Code

recommended routing only on the state highway network. The solution shall identify the jurisdiction(s) responsible for travel on the local roads (city and county roads) and advise the user to contact the jurisdiction(s).

AR18 Vendor Response: PSDC is prepared to offer geocoding options and options for identifying local jurisdictions to the K-TRIPS team. The following table summarizes potential geocoding options identified at this time:

Geocoding option Description/advantages and disadvantages

Using Tele Atlas data as the base routing data

If the K-TRIPS team opts to use the Tele Atlas data for base routing, see the response to requirement AR04 for more information, PSDC will be able to use this data for geocoding with no additional efforts. If the K-TRIPS team elects to use an alternative source for routing, the Tele Atlas option is an expensive option for providing only geocoding.

Using a freely available geocoding source from the internet such as Google

Google and other sources provide free web-based goecoding services. These services are generally quite good but the solution will be dependent on the service and the connection to the service for geocoding. The system will have to be able to deal with outages in the service and the State will need to either secure a long term contract for the service or be prepared to change services if they decide to discontinue service or start charging for the service. This option currently will not require any licensing fees or any additional charges for implementation.

Using Tiger data internally Tiger data is a comprehensive GIS database made freely available by the US Census Bureau. PSDC can implement a geocoding function using Tiger data locally within the system. PSDC can geocode using Tiger data but usually it is slightly inferior to the Tele Atlas or Google options. This option will not require any licensing fees or any additional charges for implementation.

Other options available to the State The State may have other sources for geocoding that PSDC is unaware of.

PSDC will work with the K-TRIPS team to identify and implement the geocoding option that it optimal for the solution.

PSDC is proposing the following option for identifying local jurisdictions in the event the user enters a location that is on a city or county road. For this option, PSDC assumes that the location has been identified and is returned with its latitude, longitude coordinates. PSDC also assumes the closest location on the state highway network has been identified and its coordinates provided. PSDC proposes drawing a line between these two points and identifying the jurisdictions the line passes through (see the illustration below):


Automated Routing


M/FO

Code

In this case the line passes through the city of Spring Hill and Johnson County.

The jurisdiction will be defined using polygons of the borders. PSDC will use polygons for the counties and incorporated cities. PSDC can use polygons provided by the State or commercially available polygons. Obviously this solution will not be perfect in all circumstances, but PSDC believes it will correctly identify the local jurisdictions in most. PSDC is prepared to work with the K-TRIPS team to implement this solution or other solutions identified during the design phase.

AR19 Standard Routes

For any given origin and destination pair, the solution shall first attempt to find a defined standard route that defines a path between the origin and destination which is acceptable for the vehicle dimensions. When a valid standard route is found, the solution shall assign it to the permit application.

M/F 1 2 3 4

AR19 Vendor Response: Deleted per Amendment 2.


Automated Routing


M/FO

Code

AR20No Route Available – Origin-Destination

If the solution finds no feasible route for a given vehicle between the origin and destination, the solution shall inform the user, including displaying the restrictions along the route. M/F 1 2 3 4

AR20 Vendor Response: PSDC’s system notifies the user that there is no route between the origin and destination and will configure this message to the State’s requirements. PSDC’s system displays the restrictions graphically on a map for the load. See the response to requirement AR24 for a screenshot. Note: The restrictions applicable to any load are available with any route request regardless if the request is successful or not. PSDC will add the capability for the user to view a text description of the restrictions on the route. See the response to requirement AR20 for more information on this added capability.

AR21 Multiple-Segment Routes

The solution shall allow for a single trip comprise multiple segments or multiple origin and destinations, including routing round-trips as single trips. M/F 1 2 3 4

AR21 Vendor Response: PSDC’s system implements the following trip types:

Origin to destination Origin to destination and return Multiple point-to-point segments

AR22 User-Selected Route Analysis

The solution shall identify all restrictions and warnings for the given vehicle’s dimensions on the user-selected route. The solution shall inform the user of the restrictions and warnings via text and graphical display.

M/F 1 2 3 4

AR22 Vendor Response: PSDC’s system currently identifies all restrictions application for a permit application graphically on a map. For more information on this display and a screenshot please see the response to requirement AR24. PSDC will modifications to the system to produce a text description of the restrictions along the user-selected route.

AR23 User-Selected Route Rejection

The solution shall not permit a trip with a route that has restrictions which would preclude passage given the vehicle’s dimensions. M/F 1 2 3 4

AR23 Vendor Response: PSDC’s system will not issue a permit with route that violates restrictions. Currently the system allows a State user with the proper permission to override this and issue the permit. This feature can be disabled at the State’s request.


Automated Routing


M/FO

Code

AR24 Route Rejection Information

The solution shall inform the user of the restrictions that caused a route rejection. The solution shall display the restrictions graphically and textually. The solution shall allow the user to return to the routing tool and start over using the same data, by selecting a different route or origin and destination.

M/F 1 2 3 4

AR24 Vendor Response: PSDC’s permitting system informs users that their route could not be completed and displays a graphical map with restrictions highlighted. All restrictions applicable to the current load are highlighted. Users are able to obtain information about each restriction by clicking on the highlight. See the following screenshot:


Automated Routing


M/FO

Code

PSDC’s system allows the user to return to the screen for entering the origin, destination, and route to select alternates.

PSDC will work with State personnel to identify restrictions to be included on a textual list to be submitted to the user for a failed route. Modifications required


Automated Routing


M/FO

Code

include identification of restrictions to be returned in a text format and the creation of the interface to do so.

AR25 Rejected Route Manual Submission

The solution shall allow the user to submit a permit application with a rejected route for manual review by KTC. M/F 1 2 3 4

AR25 Vendor Response: PSDC’s system has the capability for a user to submit a rejected route along with a text reason for why the carrier wishes to submit the route for Permit Agent review.

AR26 Test Routes

For loads that do not meet Superload criteria, the solution shall be able to generate suggested routing without a permit application. The user shall be able to enter vehicle dimensions, origin and destination and the solution shall generate a suggested route without the route being attached to a permit, and without the user having to enter permit application data. Test routes shall be clearly designated as test routes and shall be differentiated in appearance from standard permit routes. Users shall have the ability to save all test routes as templates.

M/F 1 2 3 4

AR26 Vendor Response: PSDC’s system includes a ‘bid route’ feature allowing a user to enter load dimensions and receive a route using the current highway network with restrictions. The user is able to print the route and the map. PSDC will work with Kansas staff to devise ways to indicate that this is for informational purposes and is not a permit. Required modifications to meet this requirement are the inclusion of the capability to save these routes as a template.

AR27 Annual Permit Routing

The solution shall allow users with annual permits to generate and print routing for individual trips and associate the routing and dates with the existing annual permit. M/F 1 2 3 4

AR27 Vendor Response: PSDC’s system includes a ‘bid route’ feature and also includes the ability to enter a non-routed time period permit to generate the route. The system will recall the dimensions of the permit and populate the interface with these dimensions. However, the user will be able to change these dimensions to a lower value for the particular trip they are requesting.

AR28 User Accepted or Refused Routing

The solution shall allow the user to accept or reject any route suggested for a trip, including routes suggested by Kansas Staff. If the user rejects a route, the solution shall ask them to provide a reason. The reason for rejection will be made available to the Kansas staff that developed or worked on the suggested routing.

M/F 1 2 3 4

AR28 Vendor Response: PSDC’s system has the capability for a user to submit a rejected route along with a text reason for why the carrier wishes to submit the route for Permit Agent review.


Automated Routing


M/FO

Code

AR29 User-Selected Route Approval

If a user-selected route is found to have no restrictions and is accepted by the user, the solution shall attach the route to the permit application. The route shall be described in text and graphically on a map both of which are printable.

M/F 1 2 3 4

AR29 Vendor Response: PSDC’s permitting system attaches the accepted route to a permit and can include a route description and or a map on the permit at the State’s desire. PSDC can modify the text route description to meet the Agencies requirements.

AR30 Routing WarningsThe solution shall attach any warnings associated with an accepted route to the permit application. Examples of warnings include any note of caution to a vehicle operator that is specific to the trip. For example, reduced speed limits at bridges.

M/F 1 2 3 4

AR30 Vendor Response: PSDC’s system is capable of adding warning notes to permits. Currently the system can add notes to permits based on the following:

Permit type Route – through the use of curfew type restrictions. See the response to requirement AR32 for additional information Load envelope Manual permit staff notes

PSDC will work with State staff to identify any additional methods to assign notes to permit applications and permits.

AR31Warnings and Restrictions Changes

When a restriction or warning has been added or changed in CANSYS, KANROAD or the solution, the solution shall be able to automatically identify all permits already issued or in draft that will be affected by the change or addition. The solution shall have the ability to e-mail or fax the change to the affected active permit holders.

M/F 1 2 3 4

AR31 Vendor Response: PSDC’s permitting system meets this important safety requirement using its Reroute Identification System (RIS). The RIS is a server application that runs as a scheduled task on one of the servers in the system. This application works as follows:

1. Load in all active, routed permits – this include load information and the road segments for the route2. Load in all active restrictions – this includes load parameters and road segments3. For each permit in step 1, identify those restrictions in step 2 that apply to the permit4. Compare the road segments for each restriction identified in step 3 that apply to a permit with the road segments for that permit


Automated Routing


M/FO

Code

5. If any road segments are identified in step 4, notify the State and the permit holder using the designated method6. Record any conflicts identified in step 5 so the system does not continue to send out notices

The system has this capability because each route is fully defined on a road segment by road segment bases and these routes are stored in the database tied to each permit. Note: The restrictions listed in step 2 can come from manual sources or from automated sources such as CANSYS and KANROAD.

AR32 Restrictions Input

The solution shall have the ability for a K-TRIPS System Administrator and K-TRIPS Restriction Entry user to create, edit and delete restrictions for height, weight, length and width directly in the solution. The restrictions shall include a description, type, lane(s) and direction of travel. The restrictions shall be time sensitive, allowing for a beginning and ending date that may be in the past, present or future. The system shall create an audit trail for all restrictions entered directly into the solution.

M/F 1 2 3 4

AR32 Vendor Response: PSDC’s permitting system includes a restriction management system for managing the routing of OS/OW loads on the GIS database. This restriction management system allows users to add, modify, and retire restrictions. A restriction is a database object that is tied into the GIS database that restricts the movement of different types of OS/OW loads. Example of restrictions would be low bridges (clearance), low weight bridges (weight), construction areas (width), or a downtown area where no permits are allowed (no-permits). A restriction has the following components:

Component DescriptionRoad segments 1 or more road segments from the GIS data that the restriction affects.Name A way to identify the restrictionDescription Description of the restrictionExternal link A text record that allows the system to tie the restriction back to an external system.

This record could be a primary key in another database or some other identification number.

Conditions A description of the loads that the restriction affects i.e. Height, width, weight, length, etc.

Effective date Begin date (if there is one) for the restriction. This date can be in the past, present, or future.

Expiration date Date the restriction ‘retires’. Restrictions that do not have an expiration date are considered active. The retirement date can be in the past, present, or future.

Owner Name of the person who set or has responsibility for the restriction


Automated Routing


M/FO

Code

Directionality Whether the restriction applies to both directions of the road segment or just oneLanes Whether the restriction applies to all lanes or if the restriction only applies to

specific lanes.Weight This is how the restriction affects travel of loads that the restriction applies to.

Generally the restriction either completely disallows travel (for instance a low bridge) or the restriction does not affect travel at all (this is for curfews, special pilot car requirements, etc)

Permit text If the restriction allows travel on a road segment but requires that special text or notes be added to the permit, this text will be added to the permit.

Audit trail A complete audit trail of all changes in the restriction. This includes the user who made the change, timestamp, and a complete description of the change. The restriction can be recreated as it appeared at any time in the past using this audit trail.

Restrictions can be entered, edited, and modified by users using a web-based GIS restriction management program or they can be entered, edited, and modified using an external database such as CANSYS or KANROAD. For more information on how restrictions are tied to records in these system see the response to requirement SI06. Modifications required include implementing a web-based version of PSDC’s Windows based application.

AR33 KDOT DistrictsUsing CANSYS data, the solution shall have the ability to identify the district in which each state highway road segment exists. The solution shall be able to automatically determine the districts that need to approve a proposed route for a Superload or large structure.

M/F 1 2 3 4

AR33 Vendor Response: PSDC’s system mapping data includes a field for identification of the DOT district for each state maintained road segment. PSDC will populate this field using the CANSYS data. Using this field, the system is able to determine the districts a route travels through.

AR34 Priority Routing

The solution shall provide a method whereby a K-TRIPS System Administrator may enter an adjustment factor for a group of roadway segments which would change the “apparent” distance when used by the solution’s routing engine (routing algorithm). In this way certain routes are given priority over others for the purposes of setting up priority trucking corridors. An example of priority routing would be an 11' wide load moving from Topeka to Manhattan. Assuming no construction or other restrictions the routing engine without adjustment factors would route the load up Highway 24 (55.6 miles) since this is the shortest distance. With priority settings, however the load would be routed more safely up I70 (57.8 miles).

M/F 1 2 3 4


Automated Routing


M/FO

Code

AR34 Vendor Response: PSDC will work with Kansas staff to develop ‘adjustment factors’ to be applied to roadway segments. Roadway segment parameters that may used to identify such ‘adjustment factors’ may include but will not be limited to the following:

Road class Lane count and width Pavement type Shoulders Turning radii Turn angle Setting impedance on individual road segments Allow contra-flow travel

Using this list, PSDC will develop a web-based graphical interface allowing State personnel to experiment with these parameters. This interface will allow users to enter origins and destinations and have slide controls or other methods allowing for the configuration of the parameters. As the users adjust the parameters, the interface will redraw the calculated route based on the parameters. PSDC’s routing engine will use the adjustment factors for calculating routes. In the above example, the adjustment factor for two lane rural state highways may be 1.5, so the routing engine would recognize the Highway 24 route as 83.4 miles long and it would recommend the I70 route.


PP - Permit ProcessingPermit Processing


M/FO

Code

PP01 Vehicle Specific All permits issued shall be specific to a vehicle and its Vehicle Identification Number (VIN). M 1 2 3 4

PP01 Vendor Response: PSDC’s permitting system allows permits to be assigned to a specific vehicle and to require the entry of vehicle information including the VIN before the permit will be issued. The vehicle information including the VIN will be printed on the permit, and the permit will be searchable by the VIN.

PP02 VIN Data Entry The solution should be able to complete vehicle information with VIN verification algorithms or software. O 1 2 3 4

PP02 Vendor Response: PSDC will add the capability for the system to complete the year, make, and type for a vehicle when the user enters the complete 17digit VIN. The system will also validate the VIN using the check digit. This capability is limited to standard 17 digit VINs. Required modifications include VIN validation code and the creation and maintenance of tables identifying year, make, and vehicle type based on the appropriate digits in the VIN.

PP03 Batch Entry The solution shall process permit applications from data input via a batch entry process. (See SI01.) M/F 1 2 3 4

PP03 Vendor Response: Please see the response to requirement for SI01 for details for this requirement.

PP04 Multiple Permit Types

The solution shall be able to issue multiple permit types within a single permit application process and to a single document. The solution shall provide the ability to build permit definitions which define various permit types and link permit types together. The solution shall automatically recognize permit types that must always be issued together. For example, a Raised Weight permit type is only sold in combination with Superload, Oversize/Overweight or Large Structure permits.

M 1 2 3 4

PP04 Vendor Response: PSDC’s system allows supervisors to build permit definitions. Please see the response to requirement SA18 for more details on this capability. PSDC will add this capability to link permit types together and to define an interface allowing these linked permits to be requested, issued, and printed using a single interface and or a single document. PSDC will work with Kansas staff to identify ways to link permits and the interface to implement this feature. Required modifications include the identification of such methods and the development of the interface and functionality to implement these methods.

PP05 OS/OW Processing The solution shall accommodate permit definitions for Kansas specific OS/OW processing and data requirements. M 1 2 3 4

PP05 Vendor Response: Please see the response to requirement SA18 for this requirement.


Permit Processing


M/FO

Code

PP06Safety and Credential Verification

The solution shall query the KSCVIEW using the permit applicant’s USDOT Number and TIN as the identifier to verify the permit applicant is currently registered and has a satisfactory safety rating before allowing the solution to issue a permit to the applicant. (See SI102.)

M/F 1 2 3 4

PP06 Vendor Response:: PSDC’s permitting system is designed to work with external system to validate carrier accounts and vehicles. Currently PSDC’s system integrates with SAFER and TxDOT’s MCCS system using web-services to validate carriers. PSDC’s system also implements a permit validation interface using web-services for external systems to obtain current information on permits. PSDC will modify its system using interface documentation provided by KDOT to interface with KSCVIEW to verify that the permit applicant is currently registered and has a safety rating. The system will use the USDOT number and TIN as identifiers and will not issue the permit if the applicant is not registered or does not have a satisfactory safety rating. Modifications required include creation of a web services interface for requesting information from KSCVIEW and functionality to disallow permit issuance if the required verification is not successful. The system will notify the user of the reason why the permit cannot be issued.

PP07 Permit RevocationThe solution shall flag revoked permits based on direct input to the solution or through interface with the KSCVIEW. Revoked permits shall be flagged in the solution and their status shall be displayed as revoked.

M/F 1 2 3 4

PP07 Vendor Response: PSDC will implement this capability as revoke a permit. PSDC will implement both an interface for authorized State staff to revoke the permit as well as implement it in the KSCVIEW interface. The status of the permit will be reported as revoked to any inquiry.

PP08 Carrier/Vehicle Verification

Through interface with the KSCVIEW, the solution shall verify the carrier and vehicle meet configurable criteria before the permit is issued or an account is created. Applications that do not meet minimum criteria shall be flagged by the solution.

M/F 1 2 3 4

PP08 Vendor Response: PSDC will work with the K-TRIPS management team to identify the criteria that will be obtained through the interface with KSCVIEW. PSDC will implement these criteria, the interface with KSCVIEW, and the method to flag the carrier within the solution. Kansas staff will configure the system to their requirements.

PP09 Permit Processing The solution shall be able to automatically process and issue all permits that do not require manual intervention and contain no errors. M 1 2 3 4


Permit Processing


M/FO

Code

PP09 Vendor Response: PSDC’s system allows for the self issue of permits 24 hours a day 7 days a week if the permit application does not require manual intervention and passes all integrity tests. See the response to requirement SA18 for more information on the parameters used to control self issue based on the permit type. The State is able to configure self-issue envelope limitations. These limitations include length, height, width, GVW, axle weight, and axle-group weights. The parameters can be set by State staff with the proper permissions. In addition to these parameters, PSDC’s system allows State staff to set a flag to disallow self issue for a company.

PP10 Permit GroupingThe solution shall be able to automatically identify permits from the same applicant for trips with the same origin/destination, vehicle and load types and similar travel dates and group them in the queue so they may be processed together.

M 1 2 3 4


Permit Processing


M/FO

Code

PP10 Vendor Response: PSDC’s system has the capability of batching similar trips to be processed together. PSDC will work with Kansas staff to identify the parameters for group processing. In addition to this batching capability, PSDC’s system allows users to enter multiple permits on the same application.


PV - Pilot Vehicle ServicePilot Vehicle Service


MM/F

OCode

PV01 Pilot Vehicle Service Account

The solution shall allow K-TRIPS Pilot Vehicle Service users to apply for an account and manage account information. The information will include:- Pilot Vehicle Service Company name- Applicant company name and contact information, including address, phone number and e-

mail address- The names of all drivers who will drive for the applicant company- Drivers license number for a one year permit- Defensive driving certification or commercial drivers license (CDL) number for each driver

that seeks a 3 year permit- Electronic acknowledgment that the applicant has read and understood Kansas’ pilot vehicle

rules and regulations

M/F 1 2 3 4

PV01 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow users to apply for a pilot vehicle permit. This functionality will include all of the information listed above and will have electronic acknowledgment that the applicant has read and understood Kansas’ pilot vehicle rules and regulations.

PSDC has reviewed the information presented in the RFP and attachments regarding the pilot vehicle permit. PSDC proposes the following functionality for implementing the pilot vehicle permit requirement. Note: These proposals are tentative based on the available information and are subject to change based on State feedback.

The pilot vehicle permit system will have the following capabilities:

Allow users to apply for a pilot vehicle permit Maintain a queue of pilot vehicle permit applications Allow authorized state users to approve a pilot vehicle permit application Create the pilot vehicle permit and deliver the permit in the PDF format via a link on the website or email Maintain a list of active pilot vehicle permits Allow authorized state users to require pilot vehicle for any permit type Allow authorized state users to require pilot vehicle based on load dimensions Present a list of active pilot vehicle permits, sorted by company name, to permit applications that require a pilot vehicle


Pilot Vehicle ServiceRef # Requirement Description

MM/F

OCode

Provide a means for permit applicants to review carrier feedback during the permit application process – if the State so chooses Require the permit applicant to select a configurable number of pilot vehicle permit holders during the permit application process Notify the pilot vehicle permit holder of their selection via email Allow pilot vehicle permit holders to access the permit Include the pilot vehicle permits in the permanent record for the permit Allow permit holders to complete trip reports Notification of pilot vehicle permit expiration Provide an administrative interface for configuration and to add, delete, suspend or change permit status

The following flow diagram provides an overview of the pilot vehicle permit system and interface components and a work flow for this permit:



MM/F

OCode

The pilot vehicle application screen will have links for required forms and will allow users to upload completed forms. The screens for reviewing the applications will have the ability to view and print all uploaded forms. If the application is accepted, all uploaded forms will be included in the permanent record for that permit.



MM/F

OCode

The list of active pilot vehicle permit holders will include a link so the OS/OW permit applicant can view trip reports submitted for each pilot vehicle permit holder. This list will also provide a means for the applicant to select the required number of pilot vehicles.

All screens and reports generated by the pilot vehicle permit system will mirror existing forms or will match State requirements.

PV02 Pilot Vehicle Permit Types

The solution shall provide the K-TRIPS Permit Agent the ability to assign one year and three year permits to applicants based on the credentials the K-TRIPS Permit Agents manually review. M/F 1 2 3 4

PV02 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow Permit Agents to assign one year and three year permits to applicants based on the credentials submitted by the applicant. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV03 Pilot Driver Permit

The solution shall allow K-TRIPS Pilot Vehicle Service users to apply for a Pilot Service permit online. The application shall require the applicant to submit at least the following:- Driver name- Applicant company name and contact information, including address, phone number and e-

mail address- Driver license number or CDL for each driver- Proof of completion of a defensive driving course (optional)- Electronic acknowledgment that the applicant has read and understood Kansas’ pilot vehicle

rules and regulationsThe solution shall allow for applicants to upload required forms and verifications.

M/F 1 2 3 4

PV03 Vendor Response: PSDC’s proposed Pilot Vehicle permit functionality will include online application screens allowing the user to submit the required information and allowing the user to upload required forms and verifications. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.PV04 Application Review The solution shall allow K-TRIPS Supervisors and K-TRIPS Permit Agents to approve the pilot

vehicle permit applications. The Kansas Staff will review the applicant outside of the solution. The solution will allow the Kansas Staff to accept or reject the application. Accepted applicants shall become permitted pilot vehicle services and shall be added to the K-TRIPS application for use in

M/F 1 2 3 4



MM/F

OCode

the Superload and large structure permit applications.

PV04 Vendor Response: PSDC’s proposed Pilot Vehicle permit functionality will allow Permit Agents to review and approve the Pilot Vehicle permit application. The system will provide all needed information to the Permit Agent including viewing and printing all uploaded forms. If the application is approved, the permit will be issued and the applicant will be added to the Pilot Vehicle list for Superload and large structure permit applications. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV05Permitted Pilot Vehicle Service Management

The solution shall allow K-TRIPS Supervisors and K-TRIPS Permit Agents to manage the permitted pilot vehicle services, including entering the start and end dates of the permit and the types of pilot services that can be provided.

M/F 1 2 3 4

PV05 Vendor Response: PSDC’s proposed Pilot Vehicle permit functionality will allow Permit Agents to manage all aspects of the Pilot Vehicle services. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV06List of Permitted Pilot Vehicle Services

The solution shall be able to display the list of currently-permitted pilot vehicle services to users. The solution shall only display those that have current valid permits, their contact information, the types of pilot service they are permitted to provide, and the date the permit expires.

M/F 1 2 3 4

PV06 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow users to view a list of currently-permitted pilot vehicle services. This list will include such information as required by the State. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV07 Pilot Vehicle Service Selection

The solution shall allow permit applicants to select from the list of permitted pilot vehicle services when pilot vehicles are required for the trip. The selected pilot vehicle services will be identified in the permit application. If the permit is issued, the solution shall notify the pilot service via e-mail that it has been identified by the permit applicant as the pilot service for the trip.

M/F 1 2 3 4

PV07 Vendor Response: PSDC will implement pilot vehicle permit functionality that will allow users to select permitted pilot vehicle services from the list of currently-permitted pilot vehicle services when required for the permit. The selected pilot vehicle service will be notified when the permit is issued that it has been selected as the pilot service for that trip. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV08 Pilot Vehicle Confirmation

The solution shall notify the Pilot Vehicle Service user(s) whenever its service has been selected by a permit applicant. M/F 1 2 3 4



MM/F

OCode

PV08 Vendor Response: PSDC’s proposed Pilot Vehicle permit functionality will notify the Pilot Vehicle Service user(s) that they have been selected by a permit applicant. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV09 Pilot Vehicle Permit Requirement

The solution shall not issue a permit that requires pilot vehicles until the minimum number of required permitted pilot vehicle providers have been selected by the applicant. M/F 1 2 3 4

PV09 Vendor Response: PSDC’s proposed Pilot Vehicle permit functionality will not issue a permit that requires pilot vehicles until the minimum number of required permitted pilot vehicle providers have been selected. See the response to PV01 for more details on PSDC’s proposed pilot vehicle permit implementation.

PV10Required Pilot Vehicles for Other Permits

While Superloads are currently the only permit type requiring pilot vehicles, the solution shall have the ability to allow a K-TRIPS Administrator to require permit applicants to identify pilot vehicle services in large structure permit applications in the future.

M/F 1 2 3 4

PV10 Vendor Response: PSDC’s permitting system allows administrative users to select whether any permit type is required to have pilot vehicles and how many vehicles are required. In addition, pilot vehicle requirements can be based on the load dimensions. State staff with the authority to do so may change the number of permit vehicles required for any particular permit. For more information on configuration of pilot vehicles for permit types see the response to SA18.

PV11 Pilot Vehicle Data Migration

The vendor shall migrate the existing list of pilot vehicle services into the solution. The list contains approximately 4000 records when sorted by driver name. The list shall be displayed in the solution by company name. The list will be provided by Kansas to the vendor as a comma-delimited text file.

M/F 1 2 3 4

PV11 Vendor Response: PSDC understands and agrees that it will be required to import the existing pilot vehicle services into its permitting system if the State selects PSDC as the vendor for the solution. Required modifications include creating an interface to import the text file.

ProMiles System Requirements

FM - Financial ManagementFinancial Management


M/FO

Code

FM01 Permit Payment The solution shall accept payment for permits through electronic payment and from an applicant’s escrow account, with the capability to recognize other payment sources in the future. M 1 2 3 4

FM01 Vendor Response: PSDC’s system accepts payment for permits using each of the following methods:

Electronic payment source Escrow payment Cash Check

PSDC’s will work with Kansas’s electronic payment provider to interface the permit system with that provider’s system. PSDC’s system also allows for cash to be accepted at multiple state locations. Customers can order a permit online and then pay for and pickup the permit at any designated cash location. The system produces daily closeout reports for each location or for each worker. These reports will be customized to meet the State’s needs. PSDC’s system can be easily modified to accept additional payment sources. These sources can be similar to credit cards with an interactive approval process or they can be modeled like an escrow system with a balance maintained for each customer.

FM02 Accounting The solution shall meet basic accounting functionality, refunding, apply credits, reconciliation and reporting. M 1 2 3 4

of 139


Financial Management


M/FO

Code

FM02 Vendor Response: PSDC’s permitting system allows authorized state users to perform account functions including refunding, applying credits, reconciliation, and reporting. In order to facilitate reconciliations, the system allows for a ‘settlement date’ capability to be built into each payment method. The following table would be an example of the logic for the settlement date:

Payment type Settlement dateVisa/Mastercard Transaction date + 2 days

American Express Transaction date + 3 daysCheck Transaction date + 1 business day

Cash/Escrow Transaction date

Reports generated using this settlement date can be generated to assist in the reconciliation process. The system will record electronic payment transaction data such as a confirmation number with each transaction allowing for the tracking of funds. Reports can be generated for refunding and credits to track such activity. PSDC will work with State personnel to tailor this functionality and reports to meet the needs of the State of Kansas.

FM03Permit Fee Breakdown by Deposit Fund

The solution shall calculate, display and store fees based on permit types, including information required for multiple fund distributions. M 1 2 3 4

FM03 Vendor Response: PSDC’s system allows for one or more fees to be assigned to a permit type and each of these fees can be assigned to separate funds for distribution. This fee information is part of the permit definitions. The system calculates and displays fees for the permits based on this fee information. Modification of the permit definitions including the setting of the fees is accomplished using an easy to use interface. Please see the response to requirement SA18 for more information on the fee calculations.

FM04 Permit Fee Fund Codes

The solution must provide for distribution of funds collected to Kansas specific fund codes. Some Permit Types may distribute to multiple fund codes. A single permit can include multiple types of permits and will also generate multiple accounting fund code transactions.

M 1 2 3 4

FM04 Vendor Response: PSDC’s system has this capability. Please see the response to requirement SA18 for more details.

of 139




M/FO

Code

FM05 Carrier Escrow Accounts

The solution shall require each K-TRIPS Account Holder to have no more than one escrow account. The solution shall also allow K-TRIPS Supervisors to create and maintain escrow accounts for customers which may be used to pay for permits generated by the solution. Maintenance includes making fiscal adjustments and updating all account information. Any maintenance activities will be reflected in an audit trail for the account.

M 1 2 3 4

FM05 Vendor Response: PSDC’s system allows for a single escrow account for each customer account. It also allows Supervisors to create and maintain escrow accounts.

FM06 Escrow Account Divisions

The solution shall be able to allow K-TRIPS Account Holders with escrow accounts to create and name subdivisions within the escrow accounts. The solution shall allow the K-TRIPS Account Holders to assign costs to the subdivisions. The escrow account subdivisions will be used to allow K-TRIPS Account Holder to use subdivisions to better track payments.

M/F 1 2 3 4

FM06 Vendor Response: PSDC’s system includes functionality for users to create subdivisions within their account and to assign vehicles, users, and permits to these subdivisions. The system includes reporting based on subdivision to better track payments.


The solution shall allow escrow funds to be only used for permits issued to the USDOT number registered to the account. The exception shall be the escrow accounts of Permit Services. M 1 2 3 4

FM07 Vendor Response: PSDC’s system only allows escrow funds to be used by the customer’s account.


The solution shall allow Permit Service escrow accounts to use escrow funds to pay for permits issued to any valid USDOT number. M 1 2 3 4

FM08 Vendor Response: PSDC’s system allows permit services to use their escrow funds to purchase permits issued to any customer.

FM09 Escrow Balance

The solution shall allow escrow account users to deposit escrow funds using the Electronic Payment system or by printing and submitting a Kansas specified voucher form with payment. The solution shall generate the vouchers, which shall contain the account identification to enable funds to be deposited into the correct account. (See Appendix 9.)

M/F 1 2 3 4

of 139




M/FO

Code

FM09 Vendor Response: PSDC’s system allows for users to print a voucher for submitting payment for an escrow account. PSDC will implement the voucher described in Appendix 9 of the RFP. PSDC will work with the State to develop a method to deposit funds into the escrow system using the Electronic Payment system of the State’s choosing. One of the potential issues for this is the discount charged for using credit cards. For large escrow deposits this can be substantial.

FM10 Escrow Minimum The solution shall allow KTC Supervisors to configure the minimum allowed balance for an escrow account. M/F 1 2 3 4

FM10 Vendor Response: PSDC’s system supports this capability.

FM11 Escrow Account Creation

The solution shall allow KTC Supervisors to create new escrow accounts and modify existing ones, including changing contact information and adjusting balances. M/F 1 2 3 4

FM11 Vendor Response: Supervisor users in PSDC’s permitting system have the capability to create new escrow accounts, modify existing ones, including changing contact information and adjusting balances.

FM12 Escrow Account Maintenance

The solution shall provide a means for generating deposit receipts and letters and setting automatic low balance notification thresholds. M/F 1 2 3 4

of 139




M/FO

Code

FM12 Vendor Response: PSDC’s permitting system produces deposit receipts and letters. PSDC will modify this receipt to meet the state’s requirements. A sample is included here. PSDC’s system also allows for the setting of automatic low balance notification thresholds. PSDC will work with the State to determine actions to be taken when an escrow drops below this threshold.

FM13 Payment Types The solution shall be able to record and indicate the method of payment for permits (e.g. escrow account, debit/credit cards and other forms to be determined later). M 1 2 3 4

FM13 Vendor Response: See the response to requirement FM14 for this requirement.

of 139




M/FO

Code

FM14 Multiple Payment Types

The system shall allow for the payment of permits to be made by multiple types (e.g. partial funds from an escrow account and the remainder in cash or by credit card), and shall indicate the multiple payment types.

M/F 1 2 3 4

FM14 Vendor Response: PSDC’s system has this capability. The system stores zero (for exempt customers) or more payment records for each permit. Each payment record describes the source for the payment (cash/escrow/electronic payment), timestamp, the amount of the payment, and any other additional information such as credit card number (encrypted) or check number. Reconciliation reports will list each record for the permit.

FM15 Insufficient Funds

The solution shall allow KTC Supervisors to flag an account for which payment was made with an insufficiently funded check. The flag shall automatically trigger an alert notification to the account holder. The solution shall also indicate in a carrier’s account profile if they have previously attempted to purchase a permit with an insufficiently funded check.

M/F 1 2 3 4

FM15 Vendor Response: PSDC will implement this important business functionality for the solution. This will include the ability to flag accounts, notify account holders, and maintain the flags in the account profile. This functionality will be developed to the State’s specifications.

FM16 Permit ReceiptThe solution shall generate a printable money receipt with designated data elements. The solution shall itemize each cost component of a financial transaction, show the customer how fees were calculated, the payment type and present the customer with a grand total fee amount.

M/F 1 2 3 4

of 139




M/FO

Code

FM16 Vendor Response: PSDC’s system produces a receipt for each permit. PSDC will customize this receipt to the State’s specifications. Follows is an example of a receipt produced by the system:

of 139


PD - Permit Delivery and NotificationsPermit Delivery and Notifications


MM/F

OCode

PD01 Correspondence Content

The solution shall generate documents that include, but shall not be limited to: - permits- letters- status of refunds- status of escrow applications- status of escrow deposits and balances- status of customer permit applications and issuances- customer activity and financial transaction reports

M/F 1 2 3 4

PD01 Vendor Response: PSDC will work with the K-TRIPS management team during the design phase of the project to identify formats for system generated documentation identified in section PD of this RFP. PSDC will implement functionality for the system to generate each of these types of documents. PSDC anticipates that the format of the documents will be controlled using templates that K-TRIPS Supervisors can edit. The templates will include official letterhead and may be implemented using Word or other program to be determined during design. The system will allow users to modify the documents to send ad-hoc letters.

PD02 Form Correspondence

The solution shall enable a K-TRIPS Supervisor to generate correspondence letters or e-mails to the contacts in the solution’s accounts based on pre-determined templates. M/F 1 2 3 4

PD02 Vendor Response: Please see the response to requirement PD01 for this requirement.

PD03 Form Correspondence

The solution shall have the ability to accommodate multiple correspondence designs or templates, including official letterhead. Templates shall be editable by a KTC Supervisor. M/F 1 2 3 4


PD04 Ad-hoc Letters The solution shall enable a KTC Supervisor to generate ad-hoc letters to the contacts in the solution’s accounts that contain user-entered text and use predefined messages. M/F 1 2 3 4


of 139


Permit Delivery and NotificationsRef # Requirement Description

MM/F

OCode

PD05ThresholdNotifications

The solution shall automatically generate form correspondence to notify carriers when configurable thresholds are met by the carrier (e.g. escrow account balance goes below the threshold amount, annual permit must be renewed within a threshold number of days).

M/F 1 2 3 4

PD05 Vendor Response: Automatic notifications via email to carriers when events such as those described in the requirement is a cost-effective way to notify customers of events that can affect their permit operations. PSDC will work the K-TRIPS management team to identify thresholds that when crossed, the system will notify the carrier via email of the event. PSDC will implement these recommendations.

PD06 Print, Fax and E-mail Documents

The solution shall be able to print, fax and e-mail correspondence. The solution shall automatically identify the appropriate contact fax number or e-mail address from account information, and deliver by the method preferred by the applicant, as well as allow for manual entry of contact information.

M 1 2 3 4

PD06 Vendor Response: PSDC’s permitting system has the capability to print, fax, and email correspondences. The system allows users to enter their preferred contact method and the system delivers the correspondences using that method. PSDC will implement interfaces allowing Kansas staff to manually enter contact information for any particular correspondence.

PD07 Group E-mails

The solution shall be able to send e-mails to individual users or selected groups. Groups may be:- All users associated with a single account.- All users who have issued permits for a specific range of dates.- All users who have issued permits routed on a specific roadways, for a specific range of dates.- All users who have issued specific types of permits.

M/F 1 2 3 4

PD07 Vendor Response: PSDC will implement an interface allowing users with permission to send emails to individual users or groups of users. PSDC will implement a query interface to identify users to send the correspondences to.

PD08 Portable Document Format

The solution shall be able to generate documents in Adobe Acrobat PDF for e-mailing or downloading. M 1 2 3 4

PD08 Vendor Response: PSDC’s permitting system generates documents in PDF format for emailing or downloading and creates the permits in encrypted PDF files that can also be emailed or downloaded.

PD09 Permit Delivery The solution shall be able to email and fax permits complete with any associated attachments, receipts and solution routing information. M/F 1 2 3 4

of 139



MM/F

OCode

PD09 Vendor Response: PSDC’s permitting system is designed to work with standard email and fax servers. PSDC will implement an email and fax server as part of the hosting for the solution. The system has the capability to include attachments in emails or faxes.

PD10 Permit Content and Appearance

The vendor shall work with Kansas staff to define the appearance and content of permits generated by the solution. M 1 2 3 4

PD10 Vendor Response: PSDC agrees that it will work with Kansas staff to define the appearance and content of the permit generate by PSDC’s system. Important consideration to consider for this permit include the following:

Statuary and rule requirement Permit security Continuity – ensure that as much as is reasonable the new permit matches existing permits to minimize confusion with industry, permit office personnel,

port personnel, and law enforcement personnel Intelligent implementation of the new routing and mapping capabilities Barcode and automation Other requirements identified during development of the permit

PD11 Permit Bar Coding

The solution shall deliver permits that contain barcodes which uniquely identify the permits and relate them to the permit record in the solution. The barcode shall contain sufficient information to uniquely identify it. The barcode will be read by officers to verify the permit is valid and not tampered with. The barcode shall be created to be compliant with the Bar Code Data Encoding Requirements – AAMVA International Specification – Motor Vehicle Documents AAMVA.

M/F 1 2 3 4

PD11 Vendor Response: PSDC will work with the K-TRIPS team to develop a bar code specification for Kansas permits. The bare code will be of a 2-D design following PDF417 stacked linear bar code symbol format.

PD12 Permit Attachments The solution shall be able to attach text descriptions of all requirements and notes associated with a permit, such as escort or flagging requirements. M/F 1 2 3 4

PD12 Vendor Response: PSDC’s permitting system has the capability of including requirements on permits including automated methods based on the permit type, dimensions, and route, as well as requirements and notes added by State staff.

of 139



MM/F

OCode

PD13 Map Attachment The solution shall be able to attach maps to permits that include routing instructions. The map shall depict the route that is required or recommended for the trip. M/F 1 2 3 4

PD13 Vendor Response: PSDC will work with the K-TRIPS team to develop the map to be included on the permit.

PD14 Pilot Vehicle Permits

The solution shall be able to deliver pilot vehicle service permits via e-mail to Pilot Vehicle Service Accounts in PDF format. M/F 1 2 3 4

PD14 Vendor Response: Please see the response to requirement PV01 for this requirement.

PD15 Additional Notifications

For Superload and Large Structure permits, the solution shall automatically send e-mail notification to the addresses entered by Kansas staff when the permit is issued. (see KD08) M/F 1 2 3 4

PD15 Vendor Response: Please see the response to requirement KD08 for this requirement.

PD16 Failure to Permit Notification

The solution shall notify an applicant of each permit application that could not be issued. The notification may be through the web interface during the application process and via e-mail. For batch permit applications, notification may be returned in batch process. Notifications shall include links to the user’s permit queue.

M/F 1 2 3 4

PD16 Vendor Response: PSDC’s system notifies users at the end of the application process if the permit cannot be self issued and the reason why. Please see the response to requirement for SI01 for details about the batch processing. The only required modification involves the batch processing notification for this requirement.

PD17 Revocation Notification

The solution shall notify the account holder via e-mail when a permit issued to the carrier has been revoked. M/F 1 2 3 4

PD17 Vendor Response: PSDC will add this capability to the revoked permit functionality feature. Required modifications include adding a trigger to send off the e-mail and creating a template for the text of the email.

of 139


AU - Audit TrailsAudit Trails


MM/F

OCode

AU01 Audit Trails

The solution shall maintain detailed audit trails for transactions specified by Kansas. The audit trail shall include identifying the user performing the transaction, the transaction type, relevant data, time of the transaction and permit number. The solution shall identify the user for each transaction. The solution must maintain a file of all transactions by user, time, date, and permit type.

M/F 1 2 3 4

AU01 Vendor Response: PSDC’s permitting system maintains a complete audit trail for the following data items:

Permit definitions Queue definitions User data Customer company data User permissions System support tables (Envelopes/warnings/settings/etc) Permit applications and permits Permit wizard screens

For each item, an audit trail record is created which includes user, timestamp, and data changes and is created whenever the record is changed. The system is able to recreate the data as it existed at any time in the past. PSDC will add in functionality to track changes based on permit types and will add audit trail functionality for each new item added to create the solution.

AU02 Application Audit Trail

The solution shall be able to provide an audit trail of each permit application, including all elements as described in AU01. M/F 1 2 3 4

AU02 Vendor Response: PSDC’s system creates an audit trail for each permit application as described in the response to requirement AU01.

AU03 Tracking Changes The solution shall be able to track changes made to data on the solution, the dates, and identification of the user who worked on a transaction and the data that was modified. M/F 1 2 3 4

AU03 Vendor Response: Please see the response to requirement AU01 for this requirement.

of 139


Audit TrailsRef # Requirement Description

MM/F

OCode

AU04 Error LoggingThe solution shall log all application errors. The log shall include the user that received the error, detailed error information, the time of the error, the component of the solution where the error occurred, and the machine/location where it occurred.

M/F 1 2 3 4

AU04 Vendor Response: PSDC’s system includes system error logs. The logs are generated when the software generates an exception, errors in the database, and will be modified to include hardware and OS errors. PSDC will modify the system to track such additional errors as required by the K-TRIPS management team.

AU05 User Log The solution shall have the ability to report to K-TRIPS Supervisors the employees that are using the solution at any point in time. M/F 1 2 3 4

AU05 Vendor Response: PSDC will add this important capability to the permitting system. The system will identify employees using the solution based on those state users with an active session. Note: The system will log off any user when they have been inactive for a configurable time period.

AU06 Correspondence Audit

The solution shall have the ability to log all correspondence with customers generated by the solution. The solution shall track the message sent, the delivery method (e.g. mail, e-mail or fax) and the time it was generated.

M/F 1 2 3 4

AU06 Vendor Response: PSDC will include a log of all correspondences created by its permitting system. This log will track the message, the delivery method, a timestamp it was generated, and who or what system sent the correspondence.

of 139


RQ - Reporting & QueryingReporting & Querying


MM/F

OCode

RQ01 Self-Service Reports

The solution shall provide users self-service reporting through:- Standard operational and management reports (“canned reports”).- Ad hoc reports (customizable reports in standard format).- Queries

M/F 1 2 3 4

RQ01 Vendor Response: PSDC’s permitting system includes user self-service reporting through two separate interfaces. The first interface provides access to standard operating and management reports (“Canned reports”). The following standard reports are available using this interface:

Permit counts Journal Permit details Reconciliation details Permit exception report – overrides and other matters Escrow Balance

Standard reports can be filtered by time period, customer, permit type and other parameters. See the screenshot on page Error: Reference source not found for the interface and sample reports starting on page Error: Reference source not found.

The second interface, the query interface, provides access to ad hoc reports and queries. This interface allows users to enter parameters for virtually any record in the permit database. After reviewing the results from the query, the user is able to select fields for a report. The report can be generated in any format. Sample screenshots can be found starting on page Error: Reference source not found of this response.

of 139


Reporting & QueryingRef # Requirement Description

MM/F

OCode

RQ02 Report Distribution

The solution shall provide for the distribution of reports by:- Local or remote printing- Display to web browser- XML- Download in Microsoft Excel, Word or PDF format- Flat text file- Through a formatted e-mail

M/F 1 2 3 4

RQ02 Vendor Response: PSDC’s system currently produces reports in the following formats:

PDFWeb pageXML (formatted to be used by Excel or Word)

PSDC will implement a flat text file and a formatted e-mail format to the State’s specifications. All reports are sent to the client machine and can be printed to any printer accessible by the computer including local and remote printers.

RQ03 Exception ReportsThe solution shall provide for and support reporting of errors in the system. The solution shall be consistent with the information collected in the error logs and describe the error, indicate the time, the user and the component within the system where the error occurred.

M/F 1 2 3 4

RQ03 Vendor Response: PSDC will implement an interface to create reports using the error logs within the system as described in the response to requirement AU04 of this RFP. The interface will allow the user to filter the results and to produce reports in any format described in requirement RQ02.

RQ04 Online Viewing The solution shall be able to display reports in the web browser in a structured format that dynamically supports various screen resolutions. M/F 1 2 3 4

RQ04 Vendor Response: PSDC will produce reports in formatted web pages that will dynamically support various screen resolutions.

RQ05 Tabular and Graphic Reporting

The solution shall provide for and support end user report writer capability of tabular and graphic reporting from multiple databases or tables. M/F 1 2 3 4

RQ05 Vendor Response: PSDC will implement this functionality as defined during the design phase of the project.

of 139



MM/F

OCode

RQ06 Permit Data ExtractThe solution shall be capable of extracting complete permit data tables and downloading those tables into standard SQL/Oracle database formats in an on-demand or scheduled manner. The vendor shall provide the table structures, schemas, and relationships for data.

M/F 1 2 3 4

RQ06 Vendor Response: PSDC will include this functionality in its system and will provide complete database documentation. Please see the response to requirement SD14 for potential elements in the database documentation.

RQ07 Permit Activity Reports

The solution shall have the ability to report the progression of activities and current status related to a permit application, from beginning to end, (e.g. the user’s first permit request, through review, payment, issuance and until the permit expires). Permit activity reporting would include:

Users responsible for each activity. The duration of time for each activity. Notes entered for each activity. (As applicable.)

M/F 1 2 3 4

RQ07 Vendor Response: PSDC’s permitting system produces a report summarizing the statuses, activities, and timeline for a permit including any notes. PSDC will modify this capability to meet the requirements for the K-TRIPS project as identified in the design phase of the project.

RQ08 Account Reports The solution shall indicate the activity of accounts by account type and user role. Account reports shall include listing inactive accounts. M/F 1 2 3 4

RQ08 Vendor Response: PSDC will implement reports for activity of accounts by account type and user role. These reports will be developed during the design phase of the project.

RQ09 Weight Analysis Study Reports

The solution shall be able to generate weight analysis study reports for the bridges along a route, or the bridges in the entire state given a vehicle’s dimensions. The reports shall identify each bridge in the analysis and document the outcome of the analysis. Bridges failing the analysis shall be grouped for easy reference. The vendor shall develop the bridge analysis format with KDOT BEU staff, however, it is expected to be similar to the screenshots generated from the current system. See Appendix 10.

M/F 1 2 3 4

RQ09 Vendor Response: PSDC will implement functionality to generate weight analysis study reports based on the State’s requirements.

of 139



MM/F

OCode

RQ10 Routing Reports

The solution shall have the ability to generate reports based on the routing of vehicles, including but not limited to:

- Number of permits, commodity types, commodities and weights permitted by major roadway feature such as bridge, tunnel and roadway segment.

- Total mileage, number of vehicles and weight by permit type permitted for a roadway segment or segments.

The solution shall allow the user to configure the time period for which routing reports shall be generated (e.g. specified day, week, month or year).

M/F 1 2 3 4

RQ10 Vendor Response: PSDC will develop reports as specified in this requirement. Reports generated by roadway feature or roadway segment or segments will be generated using the road segments saved with each routed permit. The format of the reports will be determined during the design phase of the project. PSDC will include a graphical map for identification of road segments. These reports can be generated for counties, cities, and districts using all of the road segments in the requested area.

RQ11 Route Restriction Reports

The solution shall report any restrictions for a specific route, county, KDOT District or KDOT Maintenance Area. The restriction report shall describe restrictions by type, location and reason for the restriction.

M/F 1 2 3 4

of 139



MM/F

OCode

RQ11 Vendor Response: PSDC’s system includes the capability to create reports for any county, district, or maintenance area. These reports list all of the information listed in this requirement. A sample of one of these reports is shown below. PSDC will add the capability for listing the restrictions on a route as described to the response to requirement AR24.

of 139



MM/F

OCode

RQ12 Trip Reports

The solution shall be able to generate trip reports from customer-entered data for any permit that required pilot vehicles. The trip report format shall be consistent with the current trip report form downloadable at http://www.ksdot.org/burTrafficEng/KTC/PDFs/EscortPostTripReport.pdf (reference UD17).

O 1 2 3 4

RQ12 Vendor Response: Please see the response to requirement UD18 for this requirement.

RQ13

K-TRIPS Account Holder and K-TRIPS Permit Service

The solution shall provide K-TRIPS Account Holders and K-TRIPS Permit Service users with a suite of reports specific to their user account. Reports to be included shall be available based on:

- all status codes or a specific status code- carrier name (service providers)- USDOT (service providers)- User ID- permit type- date range

Fields to be displayed in reports shall include, but not be limited to: - fee totals- escrow balance and recent activity- VIN- permit number- issuance date- requestor name

M/F 1 2 3 4

RQ13 Vendor Response: PSDC’s permitting system has reporting capabilities for customers. PSDC will modify this capability to meet the requirements listed above.

RQ14 Batch Application Reporting

The solution shall provide to K-TRIPS Permit Service users the ability to generate reports of the status of permit applications submitted via a batch process. The report shall contain the status of each application submitted in a batch submittal.

M/F 1 2 3 4

RQ14 Vendor Response: Please see the response to requirement for SI01 for details for this requirement.

of 139

http://www.ksdot.org/burTrafficEng/KTC/PDFs/EscortPostTripReport.pdf



MM/F

OCode

RQ15 Reprint Expired Permits

The solution shall allow only K-TRIPS Supervisors and Administrators to recall and print permits that have expired. Reprints of expired permits shall be clearly marked as expired. M/F 1 2 3 4

RQ15 Vendor Response: PSDC’s permitting system has this capability. Below is a sample of a reprinted permit that has expired:

of 139



MM/F

OCode

RQ16 Performance Reports

The solution shall have the ability to capture performance statistics based on workflow activity (or inactivity). Performance reports may include:

When a permit application has been updated by user How long applications have been in the queue by status Total processing time for permit issuance Quantity of permits issued by individual user

All performance reports shall be generated for a selectable date ranges.

M/F 1 2 3 4

RQ16 Vendor Response: PSDC’s permitting system tracks every time a State staff member performs any activity on a permit including the user, the activity, and what was done by the user. Using this information, PSDC’s system is able to produce the workflow activity reports described in this requirement.

RQ17 Other Reports

The solution shall be able to generate reports on demand for K-TRIPS Supervisors based on all status codes or a specific status code, carrier name, USDOT, User ID, permit type. Report fields shall include, but not be limited to:

- Fee totals- VIN- Permit number- Issuance date- Requestor name

The solution shall allow the user to configure the time period for which the reports shall be generated (e.g. specified day, week, month or year).

M/F 1 2 3 4

RQ17 Vendor Response: Please see the response to requirement RQ01 for this requirement.

of 139



MM/F

OCode

RQ18 Cash Reports

The solution shall be able to generate the following fiscal reports For K-TRIPS Accounting users by selectable date ranges:

- Deposit reports for each issuing location detailing permit transactions that include the totals by fund type. Used to send to Kansas fiscal deposit.

- Cash report by permit and payment type, sorted by payment type (cash, credit card and check) and then permit type. This report excludes escrow payment types, which are reported separately.

- Report by User ID detailing permits issued. - Reports by permit type for all permits issued and paid using escrow accounts.

M/F 1 2 3 4

RQ18 Vendor Response: PSDC will implement each of these reports described above in a format determined during the design phase of the K-TRIPS project.

RQ19 Permit Issuing Reporting

The solution shall be able to report to K-TRIPS Accounting Users the fund totals for all escrow account permits issued for:

- All accounts- Individual accounts and dates- Individual issuing users- Carrier Name- Escrow account number- Select by turnaround time on accounts and date - Permit numbers- Permit status- Permit type

The solution shall allow for configuring the time period for which fund distribution reports shall be generated (e.g. specified day, week, month or year).

M/F 1 2 3 4

RQ19 Vendor Response: PSDC’s permitting system creates escrow reports. PSDC will add the reports listed above, and any report identified during the design phase of the system, to its escrow reporting system.

of 139



MM/F

OCode

RQ20 Escrow Distribution Reporting

For each escrow account, the solution shall be able to report fund total for permits issued by the account to K-TRIPS Accounting Users. The solution shall allow for options to select date ranges for fund distribution reports. The solution shall also allow for generation of a fund distribution report by specific permit number.

M/F 1 2 3 4

RQ20 Vendor Response: PSDC’s permitting system produces reports providing totals and details for funds. These reports can be filtered by date and payment type. PSDC’s system also produces reconciliation reports by date and payment type to facilitate reconciliation of the accounts.

RQ21 Payment Reporting Separation

The solution shall separately report all fiscal fund transactions, daily and monthly, by escrow payments and other payment types for K-TRIPS Accounting users. Escrow payments are processed separately from all other payment types.

M/F 1 2 3 4

RQ21 Vendor Response: See the response to requirement RQ20 for this requirement.

RQ22 Security Reporting The solution shall provide reports to K-TRIPS Systems Administrators on user access, usage, and audit trails including all critical transaction inquiries or browse attempts (as defined by Kansas). M/F 1 2 3 4

RQ22 Vendor Response: PSDC will work with the K-TRIPS management team to define user access, usage, and audit trails including all critical transaction inquiries or browse attempts reports. PSDC will implement the reports as defined.

RQ23 Planning ReportsThe solution shall have Ad-hoc highway / freight planning reporting capabilities that include reports by permit type, commodity type, vehicle characteristics, road segment by direction, bridges and origins and destinations. The reports shall be generated by user-defined date range.

M/F 1 2 3 4

RQ23 Vendor Response: PSDC will work with the K-TRIPS management team to define Ad-hoc highway / freight planning reporting capabilities for the K-TRIPS project. This report will be implemented using the road segment data for routed trips stored in the permit data. PSDC will implement the reports as defined.

of 139



MM/F

OCode

RQ24 Revocation Reports

The solution shall have the ability to generate revocation reports that list permits that have been revoked and include, at least:

- Permit number- Permitted carrier- Date of revocation- Duration of revocation- Reason for revocation

The reports shall be for a selectable date range.

M/F 1 2 3 4

RQ24 Vendor Response: PSDC will include revocation reports as described in the requirement.

RQ25 Size and Weight Report

The solution shall have the ability to generate the permit summaries for FHWA size and weight reporting purposes. This includes summarizing the number and type of permits issued, by time period.

M 1 2 3 4

RQ25 Vendor Response: PSDC will create permit summary reports for FHWA reporting requirements as defined by the State. These reports will summarize the name and type of permits issued by time period.

of 139


SS - Solution SecuritySolution Security


MM/F

OCode

SS01 Restrict Access The solution shall restrict access by role to protect against fraud and error. This includes transaction and data set protection M 1 2 3 4

SS01 Vendor Response: PSDC’s system restricts access to the system based on user role as described in the UR01 section of this response. Transaction protection is protected through the use of encryption. A closed system and dataset protection is implemented by limiting access to the database through login accounts, passwords, and firewalls.

SS02 User Account Security

The solution shall require a unique username and password to be created for each account. Access to the account shall only be granted to a user that correctly enters the username and password combination. The user shall be allowed to change the password at any time from within the application.

M 1 2 3 4

SS02 Vendor Response: PSDC’s system fully implements the ‘frontline’ security requirements listed in this requirement.

SS03 Account Access The e-permitting system shall securely maintain a list of user names and passwords. Each user will be required to enter a unique username and password to have access to the system. M 1 2 3 4

SS03 Vendor Response: PSDC’s permitting system maintains passwords securely in the database using an encryption scheme of the State’s choosing. PSDC can encrypt the username as well. PSDC’s system does not allow for duplicate usernames and requires all users to access the system through a login with a password.

SS04 Create AccountsThe solution shall allow K-TRIPS System Administrators to create accounts for all roles, including additional K-TRIPS System Administrators. The solution shall allow K-TRIPS Supervisors to create accounts for all roles except K-TRIPS System Administrators and K-TRIPS Supervisor.

M 1 2 3 4

SS04 Vendor Response: PSDC’s system allows authorized users to create accounts and assign them any user role.

SS05 Suspend Accounts The solution shall allow K-TRIPS Supervisors to suspend accounts for a date range selected. M 1 2 3 4

SS05 Vendor Response: PSDC will implement the capability for Supervisors to suspend accounts for a selected date range.

SS06 Inactive Accounts The solution shall be configurable to allow K-TRIPS System Administrators to configure the time period an account is not used before it is deemed inactive. M 1 2 3 4

of 139


Solution SecurityRef # Requirement Description

MM/F

OCode

SS06 Vendor Response: PSDC will add this capability to its system. This capability will be implemented using a scheduled task running at midnight each day. The system will log all accounts deemed inactive. When inactive users attempt to login, they will be notified of their status and will be directed to contact the Agency using a screen or method as designated by the State.

SS07 Re-activate Accounts

The solution shall allow K-TRIPS Supervisors and K-TRIPS System Administrators to re-activate accounts that have been inactive. M 1 2 3 4

SS07 Vendor Response: PSDC will add this capability to its system for the State. This activity will be logged.

SS08 Account Audit Trails

The solution shall create an audit trail of account management activities, including the time of activity and user identification for who added, suspended, deleted, flagged, reactivated or changed information in an account. The solution will require users performing suspensions, deletions and re-activations to give a reason for the action.

M/F 1 2 3 4

SS08 Vendor Response: PSDC’s system maintains a log of all account management activities that is viewable by authorized users. All additional account management activity developed for the solution will be included in this audit trail.

SS09 Password Protection

The solution shall have the capability to reject passwords considered too simple or easily guessed. The solution shall have the ability to activate and enter a schedule for user passwords to be changed. The system must contain “forgot password” functionality allowing users the ability to retrieve or reset their password in an automated fashion.

M/F 1 2 3 4

SS09 Vendor Response: PSDC will implement the capability to reject a password considered too simple. This will be implemented to the State’s specifications. PSDC’s system has the capability to require users to change their password on a configurable schedule and includes the ability disallow reuse of past passwords. PSDC will modify this capability to meet the State’s requirement. PSDC’s system also has functionality for users to automatically retrieve their password using email and challenge questions.

SS10 Authentication Rules

The solution shall be able to apply different authentication rules to different users such that Kansas staff has stricter and more secure rules than the public. For example, Kansas staff may have more rigid rules regarding the characters allowed in a password, and may be required to change their passwords more frequently.

M 1 2 3 4

SS10 Vendor Response: PSDC will implement the Kansas required password requirements including length of password, inclusion of character classes, time between password changes, and reuse of passwords for State logins.

of 139



MM/F

OCode

SS11 Security Violation Logging

The solution shall keep a log of IP addresses, times and violation types for all attempted security violations, including but not limited to:

- Denial of Service (DOS) attacks- Repeated failed log-ins- Attempts to insert malicious code- Cross-scripting attempts

M 1 2 3 4

SS11 Vendor Response: PSDC’s system currently tracks failed login attempts. PSDC will expand this logging capability to include DOS attacks, attempts to insert malicious code, and cross scripting attempts. PSDC will obtain and implement software to search uploaded documents for malicious code and when such an attempt is made, it will log the attempt, not upload the document, and block the user and IP address of the user. PSDC implements contextual input/output encoding/escaping to identify/mitigate cross-scripting attacks. Note: PSDC does not believe that the operation of the system will require users to upload HTML data. Because of this, PSDC believes this will be sufficient to prevent cross-scripting attacks. When such an attempt is identified, it will log the attempt, not store the data, and block the user and IP address of the user. The firewall PSDC uses has the capability to identity some types of DOS attacks. PSDC will use the firewall logs to identify, lockout, and notify the State of any DOS attacks. PSDC will work with state personnel to identify additional necessary security capabilities for the system and implement such capabilities.

SS12 Denial of Service The solution shall automatically block IP addresses of systems violating security protocols including DOS attacks, cross-scripting, and other malicious code. M 1 2 3 4

SS12 Vendor Response: Please see the response to requirement SS11 for this requirement.

SS13Security Role-Sensitive Data Access

The solution shall support application-driven limitations on functions and data available. For example, a K-TRIPS Account Holder will only be able to see data related to their related account. M 1 2 3 4

SS13 Vendor Response: PSDC’s system limits customer reports to data related to their account. Permit agency users are able to view permits issued using their account for any customer. PSDC will work with State personnel to identify and implement other such limitations of functions and data availability.

SS14 Configuration Based on User Role

The solution shall have the ability to configure menus and window views based upon the role of the user. M 1 2 3 4

SS14 Vendor Response: PSDC’s system is designed to provide an interface based on the user’s login type and permissions. In most circumstances, the system will only display information and functionality that is available to the user based on their permissions. PSDC will configure the system to meet the State’s requirements.

of 139



MM/F

OCode

SS15 New Security RolesThe solution shall allow K-TRIPS System Administrators to create an unlimited number of user roles and configure each role in terms of the data input fields, data elements and system functions for each role.

M 1 2 3 4

SS15 Vendor Response: PSDC’s system has this capability. Please see the response to requirement UR01 for more information on this requirement.

SS16 Disconnect Users The solution shall have the ability for K-TRIPS System Administrators and K-TRIPS Supervisors to disconnect users and shut down an active session. M 1 2 3 4

SS16 Vendor Response: PSDC will implement this important functionality in its system.

SS17 User TimeoutThe solution shall allow the K-TRIPS System Administrator to set a period for timeout for a user after a predetermined period of inactivity. Inactivity is defined as no interaction with web interface. Timeout will be configurable by user role.

M 1 2 3 4

SS17 Vendor Response: PSDC will include this functionality in its system for the State of Kansas.

SS18 User ID Suspension after Failed Login

The solution shall have the ability to support the suspension of a user ID after a configurable number of failed login attempts (i.e., requires solution administrator to reset password). M/F 1 2 3 4

SS18 Vendor Response: PSDC’s system locks out a user after a configurable number of failed login attempts. Administrators have the capability to reset such passwords. All login attempts (with a valid login name) are recorded by the system.

SS19Security Authentication and Authorization

The solution shall provide security authentication and authorization mechanisms including:- An authentication framework that secures both web based access and web services.- A web service authentication utilizing same authentication scheme, but extended for web

services.

M/F 1 2 3 4

of 139



MM/F

OCode

SS19 Vendor Response: PSDC’s system requires users to login to the system using the login authentication mechanism as described in this response. All non-public pages of the system are protected through an active session mechanism. Note: Public pages include the login page and any information or other pages generally made available to the public. This active session mechanism creates a server side session when a successful login is made. Any attempts to access pages or functionality of the system without such a session will be redirected to the login page. As of the time of this writing, PSDC considers it common industry practice to include a login name and password with each web services request and that is currently how this functionality is implemented. However, it is possible to implement an active session mechanism for web services if the State so chooses. PSDC will modify its authentication and authorization mechanisms as required by the state.

SS20 Data Privacy All data shall be encrypted. M 1 2 3 4

SS20 Vendor Response: PSDC’s permitting system is designed to be run on a secure server using HTTPS and with an encryption strength of the State’s choosing. In addition, credit card number, passwords, and other data deemed to have high security requirements by the State will be encrypted on the database.

SS21 Secure FTP The solution shall have the ability to use secure methods to accommodate file transfers. M 1 2 3 4

SS21 Vendor Response: PSDC will include a secure FTP site with its implementation of the system to accommodate secure file transfers.

SS22 Active Directory Integration

The solution shall have the ability to integrate with the current state active directory structure for a single sign on application interface. O 1 2 3 4

SS22 Vendor Response: Deleted per Amendment 3.

of 139


DR - Disaster RecoveryDisaster Recovery


MM/F

OCode

DR01 Backup/Restore

Redundant backups shall occur on a nightly schedule. Backup data shall be able to be restored within 24 hours of solution availability. DB logs shall be copied more often. Backups shall be able to be executed upon demand. The solution shall be able to restore information for selected dates or time ranges.

M 1 2 3 4

DR01 Vendor Response: PSDC will work with State personnel to develop backup schedules. PSDC proposes performing two mirrored backups of the database. The first backup will be to a database server running in the primary Production site but not used by the primary system. The second backup will be to a remote site. This first backup will be used to restore service in the event the primary database server fails. The second backup will be used in the event of a disaster at the primary site to bring a disaster recovery site into production. If there is any data that is created by the system continually and not stored in the database, as similar back procedure will be performed. In addition, PSDC will perform a similar backup process on all software, binary GIS data, and other files necessary for the operation of the system as they are updated. PSDC will modify this process to meet the State’s requirements, and will ensure the capability to restore information for selected dates or time ranges.

DR02 Archiving The solution shall provide the ability to archive information for any specified time frame on demand. M 1 2 3 4

DR02 Vendor Response: PSDC will provide an archival capability to its permitting system allowing for the archival of data for any specific time period on demand. The archival will include all data stored in the database and any GIS data or other data not stored in the database.

DR03 Backup Scheduling The solution shall provide a scheduling function for automatic backup and job schedules. M/F 1 2 3 4

DR03 Vendor Response: Please see the response to requirement DR01 for information on automatic backup. PSDC’s system includes a number of scheduled jobs. PSDC’s system provides a means to schedule such jobs.

DR04 Operations Restoration

The vendor shall establish a disaster recovery plan to enable restoration of operations from the loss of processing capability within a reasonable time frame, agreed upon with KDOT. M/F 1 2 3 4

DR04 Vendor Response: Please see the response to requirement DR09 for this requirement.

DR05 Failover Redundancies

The solution shall support failover redundancies and swapping of critical solution components and critical data of all solution components. M/F 1 2 3 4

of 139


Disaster RecoveryRef # Requirement Description

MM/F

OCode

DR05 Vendor Response: PSDC shall implement failover redundancies and swapping of critical solution components and critical data of all solution components in the design and implementation of its system. PSDC anticipates this will include the following:

Redundant servers supporting the system Use of hardware with redundant systems including RAID disk system, redundant power supplies and network connections, backup power supplies Local redirectors that identify failed systems that are able to redirect requests to functioning hardware

PSDC will work with State personnel to identify and develop specifications for these capabilities.

DR06 Solution Version Control

The vendor shall provide a clearly defined version control process including development test, and production environments and full “roll back” to previous version capabilities. M/F 1 2 3 4

DR06 Vendor Response: PSDC will develop and document a version control process in conjunction with State personnel. The version control process will describe the steps to be taken to test, implement, and if necessary “roll back” any update. This will include processes during development and testing of the system as well as after implementation. PSDC anticipates the following to be key aspects of this version control process:

Separate and complete Development, Test, and Production Systems A test plan used to test updates in the Test System A signoff system using the test plans and the Test System An update plan fully describing the process to move the update to the production system A plan to backup the previous version, including a complete database backup, of all production software and data on all servers in the Production

System to ensure rapid and successful “roll backs” A role back plan implementation plan including tests to ensure a successful role back

DR07 Solution Monitoring The solution shall allow for remote monitoring of all vital system components. M/F 1 2 3 4

of 139



MM/F

OCode

DR07 Vendor Response: PSDC’s permitting system includes a remote monitoring system. The system makes periodic requests to the key components of the system. The requests are designed to identify if the component is working correctly. If the component does not respond correctly to the request, the monitoring system notifies a configurable list of contacts using email or pagers and logs the errors. The following table describes the monitoring programs:

Component queried Systems testedRouting engines System routing and restriction database

Web server Permitting functionality and permitting databaseTile server Mapping and restriction database

The monitoring system sends requests to each of servers that support each component.

DR08 Vendor Response The vendor must respond within an hour to all system outages, downtime, etc. M/F 1 2 3 4

DR08 Vendor Response: Due to the importance of this system to the State and KDOT, PSDC agrees to this requirement.

DR09 Disaster Recovery Plan

Because the solution will be a “Mission Critical” function of KDOT, the vendor shall provide KDOT—prior to implementation—a Disaster Recovery Plan that meets KDOT’s required minimum 24 hour period for the solution to fully recover from a catastrophic disaster.

M 1 2 3 4

of 139



MM/F

OCode

DR09 Vendor Response: PSDC agrees that a Disaster Recovery Plan whose implementation results in the operation of a fully working system within 24 hours after a complete loss of the primary datacenter, equipment, and data is required due to the system being “Mission Critical”. PSDC’s Disaster Recovery Plan will be based on the following fundamentals:

1. Sufficient hardware being maintained at a backup site at all times to meet minimum functional requirements2. All software at the backup site will be maintained and tested to ensure it mirrors the current production system.3. All live data including but not limited to companies, users, permits, and restrictions will be mirrored in on offsite database. See the response to

requirement RD01 for more information.4. PSDC will be able to reload the data from the offsite backup database to the backup site within the prescribed time period.5. PSDC will ensure that sufficient staff is available to perform the backup operation within the prescribed time period.6. KDOT will be able to redirect the link to the site within the prescribed time period.

PSDC will work with State personnel to develop and test this Disaster Recovery Plan.

of 139


WF - Workflow ManagementWorkflow Management


MM/F

OCode

WF01 Rule Base

Workflow rules shall be based upon the following: Tolerances Events or triggers Business rules User-defined parameters Appropriate roles, rules, and routing

M 1 2 3 4

WF01 Vendor Response: PSDC’s system has a number of features to help control workflow for the Permit Office. These features include:

Flexible permission settings for users Configurable queues – controlled by permit type, permit status, load parameters, route, and other business rules Ability to assign queues to various users Ability to control settings for State staff for permit types, queue, load envelopes, and other business rules Ability for State staff with permission to configure all of the above

PSDC will explain all existing workflow rules in the system to the State and work with State personnel to identify additional workflow rules that may be necessary for the operations of the Agencies. After identification and documentation, PSDC will implement said rules with the solution.

WF02 Approval ProcessThe solution shall have the ability to provide a flexible, hierarchical approval process with higher levels of authority to approve transactions that have not been approved by individuals with lower levels of authority.

M 1 2 3 4

of 139


Workflow ManagementRef # Requirement Description

MM/F

OCode

WF02 Vendor Response: PSDC will work with the K-TRIPS management team to identify the hierarchical approval process required to implement the workflow methods desired by the Kansas permit office. The system currently allows State staff users to be assigned permit approval based on the following:

User role By permit type By queue By envelope

For example, a user could have the authority to approve Regular OS/OW but not approve Large Structures. Alternatively, the user could have authority to approve loads in the Regular OS/OW queue but not in the Large Structure queue. In addition, the user could have authority to approve loads up to 110’ length. PSDC will implement the hierarchical approval process identified above using existing capabilities of the system or using additional capabilities as required.

WF03 Electronic Approval Tracking

The solution shall have the ability to track and report key aspects of the electronic approvals (for example, a K-TRIPS Permit Agent did not approve but a K-TRIPS Supervisor approved). M 1 2 3 4

WF03 Vendor Response: Please see the response to Requirement WF05 for this requirement.

WF04 Escalation Notification

The solution shall have the ability to provide notifications to parties involved in workflow chain when escalation is needed. M 1 2 3 4

WF04 Vendor Response: PSDC will work with the State in the system design phase to identify methods for escalating actions within the workflow. Examples of such methods may include:

The ability to mark a permit for Supervisor review Methods to automatically escalate a permit’s priority based on type, route, or time waiting in queue

PSDC will implement such methods as identified in the system design phase.

WF05 Performance Statistics

The solution shall have the ability to capture performance statistics based on workflow activity (or inactivity). M/F 1 2 3 4

of 139



MM/F

OCode

WF05 Vendor Response: PSDC’s permit system tracks virtually all actions State staff performs with regards to permits in an audit trail table. This includes the following:

Open and view permit Close permit Process permit All changes in a permit Any business rule overrides

Each action includes a timestamp along with the users ID. The system is capable of generating reports using the data in this table including the following:

Permits issued by permit type Permits issued by employee Permits issued by time Permits opened and then immediately closed (Cherry picking) Average time to process permits by type or employee

PSDC will work with State personnel to identify items to include in the audit trail and reports necessary for the operations of the Permit Office.

WF06 Solution Override The solution shall have the ability to allow defined user roles to override "normal" workflow processes. M/F 1 2 3 4

WF06 Vendor Response: PSDC’s system allows users with sufficient permissions to override virtually all activities the system performs. Such activities include:

Approving permits Working permits out of order Changing permits Assigning permits to different users

of 139



MM/F

OCode

WF07 Online Batch Processing The solution shall allow users to perform online transaction processing during batch processing. M/F 1 2 3 4

WF07 Vendor Response: PSDC anticipates the batch processing functionality to run using separate tasks with a lower priority than on-line permit application requests. This will allow users to perform transactions during batch processing and should minimize response times for these users while the batch processing is running. Please see the response to requirement for SI01 for details for the batch processing system.

WF08Work Management Notification and Triggering

The solution shall utilize a work management engine that sends notifications based on events that meet certain conditions/criteria M/F 1 2 3 4

WF08 Vendor Response: PSDC will work with the K-TRIPS management team during the design phase to define the parameters for the system to send out notifications based on certain conditions/criteria. The parameters will be based on existing workflow requirements and other workflow requirements the State wishes to implement using the solution.

WF09 Session ControlThe solution provides session control even in revision mode. If the user does not release the task then a supervisor can unlock the task from a specific user so someone else can work on the task or it can reassigned to another user.

M/F 1 2 3 4

WF09 Vendor Response: In order to ensure that a permit record is inaccessible in the event a user fails to release the record, PSDC’s system allows supervisors to unlock a record from any user allowing someone else to access it.

WF10 Workflow / Queue Accessibility

The solutions shall display all workflow information in a single window. The solution shall allow K-TRIPS Supervisor and K-TRIPS System Administrators users to view all workflow processes by date/time and username and workflow / queue status.

M/F 1 2 3 4

WF10 Vendor Response: PSDC’s permitting system includes a configurable statistics page on the user’s dashboard. PSDC will work with the K-TRIPS management team during the design task to identify workflow interface options to include in the solution. PSDC will implement the changes necessary in its system to implement these interface options.

WF11 Accountability All workflows put accountability on the user. M/F 1 2 3 4

WF11 Vendor Response: All activities within the system and changes to permits and permit applications are logged. These logs identify the user and include a timestamp. PSDC will work with the K-TRIPS management team during the design phase to identify reports and other methods to identify errors made by the users. Using these reports, the permit office can identify staff productivity and errors.

of 139



MM/F

OCode

WF12 Multiple Permit Types

The solution shall integrate the workflows for permit applications that require multiple permits to be issued for a single trip. The solution shall only collect each unique data element once and ensure that the trip meets the criteria of each permit type.

M/F 1 2 3 4

WF12 Vendor Response: PSDC’s permitting system is designed to only collect such information as is required for a permit based on that permit’s definition. Please see the response to requirement SA18 for more information on permit definition. PSDC’s system also allows users to issue multiple permits using a single application. PSDC will modify the system, and the permit definition system, to identify when multiple permits are required, see requirement SA18for an example, and to allow for the application of these multiple permits using a single application.

WF13 Group Commodities Need the ability to group and add commodity types. Need to add category (drop down list) and sub category (free form field) for permits. M/F 1 2 3 4

WF13 Vendor Response: Please see the response to requirement SA08 for this requirement.

WF14 Permit Workflows The solution shall follow the workflow and business rules specific to permit types as described in the Concept of Operations. M/F 1 2 3 4

WF14 Vendor Response: PSDC has reviewed the workflow and business rules described for the various permit types as described in the Concept of Operations in this RFP and believes its system will require only minor modification to implement this workflow and these rules. PSDC will work with the K-TRIPS management team during the design phase to identify these modifications. PSDC will implement the modifications.

WF15 Superload Permits

The solution shall follow the workflow and business rules for Superload permit application approval as described in the Concept of Operations.

1. A Superload permit application shall be managed by a Bridge Evaluation Router.2. Bridge Evaluation Router develops routing, issues requests to and receives electronic

approval from all District Coordinators for districts the trip will travel through.3. Only a Bridge Evaluation Router or Bridge Evaluation Supervisor will be able to override

the KDOT District Coordinators’ approval or allow a permit application to proceed without all KDOT District Coordinator approvals.

4. A second Bridge Evaluation Router will review a completed permit application and validate it through the solution before it can be issued.

5. K-TRIPS will issue Superload permits only after Bridge Evaluation Routers complete routing, bridge evaluation, receive all required approvals, is validated by a second Bridge Evaluation Router and give K-TRIPS approval to issue the permit.

M/F 1 2 3 4

of 139



MM/F

OCode

WF15 Vendor Response: PSDC has reviewed the workflow and business rules for the Superload permit application approval as described in the Concept of Operations in this RFP and believes its system will require only minor modification to implement this. Changes include:

Implementing a method in the permit definition requiring two Bridge Evaluation Router users to approve an application Implementing a method to require approval from each District Coordinator for the districts the permit travels through Implementing a method for Bridge Evaluation Supervisor to override the above

If other changes are identified in the design stage of the project, PSDC will implement such changes.

WF16 Large Structure Permits

The solution shall follow the workflow and business rules for large structure permit application approval as described in the Concept of Operations.

1. A large structure permit application shall be managed by the permit applicant. 2. The applicant will conduct routing using the solution’s automated routing tools.3. The solution will issue requests to and receive electronic approval from all KDOT District

Coordinators for districts the trip will travel through.4. Only a K-TRIPS Supervisor will be able to override the District Coordinators’ approval or

allow a permit application to proceed without all District Coordinator approvals.5. The solution will issue large structure permits only after all District Coordinators

approvals have been received or a K-TRIPS Supervisor has approved it for issuing.

M/F 1 2 3 4

WF16 Vendor Response: PSDC has reviewed the workflow and business rules for the large structure permit application approval as described in the Concept of Operations in this RFP and believes its system will require only minor modification to implement this. Changes include:

Implementing a method to require approval from each District Coordinator for the districts the permit travels through Implementing a method for Bridge Evaluation Supervisor to override the above


WF17 Superload and Large Structure

If a permit application qualifies as both a Superload and large structure, the solution shall use all dimensions for routing, but have the permit processed as a Superload (e.g. Bridge Evaluator manages routing, evaluation and KDOT District Coordinator approval).

M/F 1 2 3 4

of 139



MM/F

OCode

WF17 Vendor Response: PSDC has reviewed the workflow and business rules of the Superload permit application approval as described in the Concept of Operations in this RFP and believes its system will require minor modification to implement this. Changes include:

Implementing a method in the permit definition requiring two Bridge Evaluation Router users to approve an application Implementing a method to require approval from each District Coordinators for the districts the permit travels through Implementing a method for Bridge Evaluation Supervisor to override the above


of 139


TR - Testing, Training & DocumentationTesting, Training & Documentation


MM/F

OCode

TR01 Testing The vendor shall establish a comprehensive test plan covering internal testing, end-to-end interface testing and user acceptance testing. M/F 1 2 3 4

TR01 Vendor Response: Please see the response to requirement SM08 for this requirement.

TR02 TestingThe vendor shall establish and maintain a test environment to be utilized by Kansas testers. The test environment shall be utilized for all acceptance-testing prior to release of any module functionality, new features, bug fixes and enhancements.

M/F 1 2 3 4

TR02 Vendor Response: PSDC agrees to this requirement. See the response to SM07 for a description of the test environment.

TR03 Testing All functions shall be thoroughly tested by the vendor prior to releasing for acceptance testing. M/F 1 2 3 4

TR03 Vendor Response: In order to speed development and testing of the system and so that the state can efficiently utilize its resources, PSDC agrees to this requirement.

TR04 Testing All system interfaces shall be thoroughly end-to-end tested. M/F 1 2 3 4

TR04 Vendor Response: In order to speed development and testing of the system and so that the state can efficiently utilize its resources, PSDC agrees to this requirement.

TR05 TestingEach software component must have an internal test procedure completed and signed off by vendor personnel responsible for completing the test procedure. The signed internal test procedure shall be presented to the KDOT Project Manager prior to delivery to KDOT for user acceptance testing.

M 1 2 3 4

TR05 Vendor Response: Please see the response to requirement SM08 for this requirement.

TR06 Training The vendor shall develop a training plan to accomplish training for all K-TRIPS user roles and technical support staff. M/F 1 2 3 4

TR06 Vendor Response: PSDC will work with the K-TRIPS management team to develop a training plan and training materials for all K-TRIPS user roles.

of 139


Testing, Training & DocumentationRef # Requirement Description

MM/F

OCode

TR07 TrainingAll training shall be performed on-site at multiple locations including KTC, KDOT Headquarters, KDOT Ports-of-Entry and KDOT District Offices. All training shall be accomplished through the use of multiple sessions to accommodate users and technical support staff.

M/F 1 2 3 4

TR07 Vendor Response: PSDC agrees that training shall be performed on-site at multiple locations within the State. PSDC also agree that multiple sessions will be held both to accommodate the potentially large number of users and also to minimize disruptions with the Agencies operations during this time.

TR08 Training Training shall include the use of product/system support services including help-desk and on-line bug reporting tools. M/F 1 2 3 4

TR08 Vendor Response: PSDC agrees that the solution envisioned by the RFP will be a dynamic system subject to change due to changes in the highway network of the state, changes in the practices in the permit office, changes in the State’s regulatory environment, and changes found during long-term use of the project. In order to manage these system changes, regular users of the system will be supported by, and will have access to the product/support service including help-desk and on-line bug reporting tools. In order for the users to make effective use of these tools, training will be required. PSDC agrees that training for all State users will include the help-desk and the on-line bug reporting tool.

TR09 Documentation

System documentation shall be delivered in electronic formats including Microsoft editable or native editable application and PDF prior to the commencement of on-site training and shall include at a minimum:

System operations manuals for all user roles. System architecture and support. Databases (including models and data dictionaries). GIS and data migration and integration processes and tools (mapping data). Mapping Management module(s). Routing subsystem and support. Restriction Management module(s) and support. Network support. Security. Training Manuals.

Vendor shall supply hard-copy training manuals to all trainees during on-site training sessions.

M/F 1 2 3 4

of 139


Testing, Training & DocumentationRef # Requirement Description

MM/F

OCode

TR09 Vendor Response: System documents that fully and accurately reflect the system as designed, developed, implemented, and upgraded during the life of the K-TRIPS project is essential to ensure the State realizes the full potential of their project, fully understands the operations and any limitations of the system, and provides knowledge in the event the state loses confidence in its vendor. PSDC will create system documentation, using specifications developed in coordination with State personnel, and will deliver such documentation to the State using Microsoft editable formats and in PDF form prior to the commencement of on-site training. PSDC also agrees to produce hard-copy training manuals to all trainees during on-site training sessions.

SM - System MaintenanceSystem Maintenance


MM/F

OCode

SM01 Maintenance Schedules

Planned software upgrades and maintenance schedules must be coordinated with the K-TRIPS System Administrator. M/F 1 2 3 4

SM01 Vendor Response: PSDC agree to this requirement to ensure smooth operation of the State’s permitting efforts before, during, and after upgrades and maintenance.


Software upgrades shall be fully tested and coordinated with KDOT to ensure that version incompatibilities are not created. M/F 1 2 3 4

SM02 Vendor Response: PSDC agrees that all software upgrades will be fully testing using procedures developed with the K-TRIPS management team before implementation and that PSDC will coordinate with KDOT to ensure that version incompatibilities are not created and that the permitting process can continue seamlessly after software upgrades. See the response to requirement SM08 for additional information on the test plans to be utilized for upgrade testing.


The vendor shall have procedures that ensure that all potentially affected users are notified if at any point a system must be halted to provide maintenance. M/F 1 2 3 4

SM03 Vendor Response: In order to ensure effective permitting operations by the State of Kansas and the OS/OW trucking industry within the State, PSDC shall work with the K-TRIPS management team to create procedures to ensure that all potentially affected users are notified if at any point a system must be halted to provide maintenance. PSDC will implement the procedures as developed.

of 139


System MaintenanceRef # Requirement Description

MM/F

OCode

SM04 Response TimeThe vendor shall confirm and begin to address technical issues in the solution within one hour of being notified, either by Kansas staff or monitoring systems. The vendor shall document all issues and their resolutions.

M/F 1 2 3 4

SM04 Vendor Response: PSDC agrees to this requirement. The documentation will be done to specifications developed with the K-TRIPS management team.

SM05 Help Desk Help desk support shall be available via phone and e-mail during all KTC hours of operation, excluding weekends and holidays. M/F 1 2 3 4

SM05 Vendor Response: PSDC maintains a help desk staffed by knowledgeable personnel accessible via phone and e-mail during business hours. PSDC guarantees this support will be available during all KTC hours of operation.

SM06 Help Tracking The vendor shall maintain an on-line help ticket system accessible to Kansas supervisors and administrators. The ticket system shall be used to track all bugs, fixes and modification requests. M/F 1 2 3 4

SM06 Vendor Response: PSDC maintains an on-line help ticket tracking system. This system will be modified to meet the needs of the K-TRIPS project and system. PSDC will assign logins for Kansas personnel to enter and review trouble tickets and to enter enhancements. Users are able to add help tickets item to the system. After a help ticket has been added, PSDC will review the item and assign it to a developer to fix. Users are able to track the progress of their help ticket as it is fixed, verified, and submitted for closure. This system tracks the following data for each help ticket item:

Title Description User submitting the problem Date Project Category Status Scope User the problem is assigned to Complete history of the problem Resolution

Users are able to upload images and .zip files to aid in the identification and resolution of the problem. Modifications include configuring the help ticket system to the requirements of the K-TRIPS project and addressing any KDOT specific requirements. Screenshots of the help ticket tracking system can be found starting on page Error: Reference source not found of this response.

of 139



MM/F

OCode

SM07 Testing Environment

The proposed system shall have a complete and separate test environment that mirrors the production system. The test environment shall be accessible by both KTC and the vendor M/F 1 2 3 4

SM07 Vendor Response: PSDC understands and agrees that there will be a complete and separate test environment that mirrors the production system. This environment will include the following:

Database Web servers Routing servers Tile server

The test system shall have sufficient resources to be usable by at least 10 simultaneous users.

SM08 Upgrades / FixesPrior to deployment of new functionality, the vendor shall develop an acceptance test plan. The test plan shall include test procedures, suggested tests, and format for reporting test results. The test plan shall be provided to KDOT project management for review and approval.

M/F 1 2 3 4

of 139



MM/F

OCode

SM08 Vendor Response: PSDC testing personnel will work with State personnel to develop a mutually acceptable acceptance test plan. This plan will include the procedures, tests, and reports necessary to demonstrate correct working of the solution. PSDC will provide the test plan for review and approval.

PSDC proposes creating the following test plans during development of the solution:Test plan name Purpose

Unit testing Test plans will be developed for each component of the system. These tests will include sufficient scaffolding as necessary to test the individual components. The purpose of these tests is to ensure correct working of each component.

System testing Test plans will be developed for each system comprised of 2 or more components. The purpose of these tests is to ensure correct communication and operation between components.

Regression testing Regression tests will be developed throughout project development. Generally, when a problem has been identified and corrected, that problem will be added to the regression test scripts. Regression tests will be performed after every major code update during development and testing of the system to ensure the later problem fixes do not break prior fixes.

Integration testing Test plans will be developed for integration with external State systems. This will include the importing of existing data. The purpose of these tests is to ensure the correct integration with these external systems.

Performance testing Performance testing will ensure that the individual components and complete system meet all performance requirements. Early performance testing is essential to identify and correct performance problems early.

Acceptance testing Acceptance tests represent the acceptance test plan described in this requirement. This test plan will be developed from the test plans used throughout the project. The acceptance tests provide criteria to demonstrate the correct working of the solution.

PSDC will perform unit, system, performance, and regression testing throughout the development of the system. Problems will be submitted to the help ticket system for review and correcting. When the system changes, the test plans will be modified to correctly reflect the current state of the system. PSDC testers will sign off on the appropriate test plans before submitting any component, module, or system to the State for approval.

SM09 Upgrades / FixesNew functionality shall be delivered for acceptance testing, within the test environment, only after the vendor has successfully completed testing and provided documented test results to Kansas, demonstrating that the software meets the specified requirements.

M/F 1 2 3 4

of 139



MM/F

OCode

SM09 Vendor Response: PSDC agrees that new functionality shall be delivered only after successful completion of testing and after providing documented test results to Kansas.

SM10 Upgrades / Fixes A qualified vendor representative with technical knowledge of the solution shall be on-site to participate in the initial acceptance testing of the system. M/F 1 2 3 4

SM10 Vendor Response: In order to ensure a smooth start to the acceptance testing, PSDC agrees to have at least one of the following on-site at the start of the acceptance testing:

Project manager Lead developer Lead QA personnel

SM11 Interface Maintenance

Vendor will be responsible for maintaining solution system interfaces, ensuring that the solution remains compatible for all interface versions. M/F 1 2 3 4

SM11 Vendor Response: PSDC will implement a version control process and a regression testing regiment that will be used to test and implement releases of the solution. This process and these tests will be used to ensure that the system remains compatible for all interface versions.

of 139

Web viewSI03 CVIEW Interface KSCVIEW is a SQL Server database housing commercial carrier and vehicle...

Documents

Transcript of Web viewSI03 CVIEW Interface KSCVIEW is a SQL Server database housing commercial carrier and vehicle...