RFP PS20161055 Provision of Weigh Scale Management and ... · Proposal Submission , Section 11.4.1 b) Annex 3). Background information and general instructions need not be included

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System

Annex 3 - Descriptive Requirements

Annex 3 – Descriptive Requirements

This Annex 3 identifies the Requirements to which the City is seeking a solution or a response (refer to Annex 1 – Schedule of Detailed Requirements, Section 11.0 Written Proposal Submission , Section 11.4.1 b) Annex 3).

Background information and general instructions need not be included in the response; however, the format for Proposals should include all requested information, responses to questions, responses to specific requirements, completed tables, etc., in the same numbering sequence used below.

For Data Sets, Scenarios, and New Technology responses, Proponents may use Annex 3A – Response Addendum for Annex 3.

1.0 Introduction/Terminology

[Note: All text in “[Italics]” is explanatory and need not be included in the Proponent’s Proposal response (and will not be included in the final Form of Agreement, Appendix 3).

This specification (along with the Proponent’s response to same) will be incorporated into as the final Form of Agreement [Appendix 3].

This Annex 3 [Descriptive Requirements] refers to the “successful Proponent” as the “Contractor” and utilizes the same defined terms as are set out in Form of Agreement [Appendix 3].]

1.1 The City requires a Weigh Scale Management and Point of Sale Solution (“Solution”) for the Vancouver Landfill, Vancouver South Transfer Station and Kent Yards. This Annex 3 [Descriptive Requirements], in part, defines the business, functional, technical, and other requirements for the Solution. Additional information about the Solution that is not captured in the sections below may be attached by the Proponent as Proposal appendices.

2.0 General Requirements

2.1 Overall Responsibility

The Contractor will be responsible for all aspects of the supply, licensing, delivery, implementation, testing, training, support and maintenance of the Solution, and will ensure that the Solution meets all of the Requirements.

2.2 General and Functional Requirements

The Solution will be capable of performing the functions set out in the tables in Annex 2 - Detailed Requirements spreadsheet as completed by the Contractor. The Contractor confirms that the Solution meets the Requirements in the manner described by the codes and comments set out in the Annex 2 - Detailed Requirements spreadsheet.

2.3 Requirement Descriptions

The following descriptions represent current and desired functionality. In the Proposal, indicate how the Solution would address the requirement.

The requirements for the Solution are denoted in these sections:

P a g e | 1



• Data Sets

• Business Rules

• Scenarios To facilitate the City’s understanding of how certain functionality may be provided by the Proponent’s Solution, a series of Scenarios is provided.

• New Technology

The City anticipates adding new functionality at the Weigh Scale Facilities to meet objectives for reducing paper use, streamlining processes and providing digital access to its services.

Three items should be addressed in the proposal: o Mobile device access for City staff o Unattended Scales o City Web Portal Integration

The City’s goals and preferences are provided; however, the Proponent may offer alternatives with sufficient explanation of relevance, for the City’s consideration.

• Annex 2 - Detailed Requirements spreadsheet The spreadsheet has sections for

Instructions 1 - Minimum Criteria 2 – Capability Matrix 3 – Functional Requirements 4 – Technical Requirements 5 – Training, Support and Documentation 6 - Components

Instructions for responding to each set of requirements are given at the beginning of each section.

The City is working towards reducing the amount of paper used, streamlining transactions, and reducing manual data entry at the Weigh Scale facilities. To that end, the City desires the following changes to current processes:

• License Plate Recognition using infrared-based cameras • Electronic ID recognition for City vehicles • Photo evidence of licence plate and load per transaction • Deposits for rental vehicles to be processed in the POS system • Fee calculations using complex rules, and re-calculations using rules in effect

on a specific date • Offence workflows • No signature collection for account transactions; use photos as proof of entry • Optional printed tickets for inbound loads for account and hauler customers;

send receipts by email • Potential load verification at the tipping area to be done by Yard Attendants

using mobile devices • Monitoring available credit for Account customers • Automatic tallying of loads associated with Waste Assessments • Interaction with other City systems to automatically retrieve transaction

details such as Work Orders, Route labels for internal transactions

P a g e | 2



• Dynamic lane configuration for direction changes and unattended mode • Unattended Scale access for Account customers; with pre-set billing and

transaction details, entered by the Customer • Remote operation of unattended scale lanes • Options for alternate input methods, e.g. touch screens or optical code

scanners • Integration with a City web portal for Account customers, allowing them to

maintain their vehicle list and billing assignments, and view transactions • Automated entry of fee total to payment card system

P a g e | 3



3. Data Sets The City seeks a Solution to represent these items in Weigh Scale operations: Transaction Objects Transactions Vehicles Billing Assignments Offences Waste Assessments Default Destinations

Customer Setup Account Customers Customer Type Profiles Business Rules Fee Calculations Offence Processing Code grouping

Supporting Lists Material Types Offence Types Vehicle Types Origin Destination Payment Types Facility

This section describes the purpose and data fields expected for each item. Actual field names may vary from those listed in this section. Instructions for Data Sets Describe how the Proponent’s solution represents the data sets: Proponents’ Scenario responses should describe functionality. The response must be no more than one (1) page for each data set. Proponents may respond by using Annex 3A – Response Addendum for Annex 3. 3.1. Transactions Minimum fields to record per transaction Data Field

Single/ Multiple

Valid Values

Manual Entry Allowed

Automated Entry Source

Transaction ID Single Unique ID no System Generated Vehicle ID Single Vehicle yes License Plate Reader or RFID

Lookup Vehicle Type Single Vehicle Types list yes Vehicle ID Lookup Trailer ID [opt] Single Vehicle yes License Plate Reader or RFID

Lookup Customer Type Single Customer Types list yes Vehicle ID Lookup Origin Single Origin list yes Billing Lookup Destination Single Destination list yes Default Destination Lookup Material Type [opt unit quantities]

Multiple Material Types list yes Billing Lookup

Payment method Multiple Payment Methods list

yes Billing Lookup

Hauler [opt] Single Hauler Accounts list yes Billing Lookup Account [opt] Single Billing Accounts list yes Billing Lookup Waste Assessment ID [opt]

Single Waste Assessment list

yes Waste Assessment Lookup

Notes [opt] Single - freeform input yes Facility Single no Lane Configuration

P a g e | 4


Annex 3 - Descriptive Requirements Data Field

Single/ Multiple

Valid Values

Manual Entry Allowed

Automated Entry Source

Direction Single yes Lane Configuration Time In Single no System clock Time Out Single no System clock Lane In Single Yes Lane Configuration Lane Out Single Yes Lane Configuration Weighmaster ID In Single No Operator Lookup Weighmaster ID Out Single No Operator Lookup License Plate Photo Single No Camera Load Photo Single No Camera Gross Weight Single* No Scale (Lane Configuration) Tare Weight Single* No Scale (Lane Configuration) Net Weight Single No Calculation Fees - Itemized Multiple No Fee Calculation Total fee Single No Calculation *Gross and Tare Weights – may be Multiple for a mixed load of weighed materials In addition to the minimum fields shown above, for specific customer types, up to three (3) more items are captured for each transaction. The current extra fields are described below. Over time, the fields and labels change; the City would prefer to set the field names in a Customer Type Profile. Additional Data Fields By Customer Type

Default Validation Automated Entry Source

City Engineering Work Order alpha Web Service Lookup Regex Hansen (Infor) CoV Transfers Driver ID alpha VSTS – Login ID City Waste Zone alpha Web Service Lookup Regex [2017] SOMAS

replacement Beat alpha Web Service Lookup Regex [2017] SOMAS

replacement Municipal Waste Route alpha Billing Lookup Account Customers Project Number alpha Billing Lookup Residential Customers Voucher Type alpha Voucher Serial No. alpha

P a g e | 5


Annex 3 - Descriptive Requirements 3.2. Vehicles

Vehicles are to be identified by their License Plate. City and some commercial vehicles may carry electronic ID tags; the ID tag number should reference a stored Vehicle ID. City vehicles are also assigned an alphanumeric Fleet ID, which is used as a reference on Work Orders.

For stored Vehicle information the expected minimum is:

1. Vehicle ID – License Plate 2. Vehicle Type 3. Vehicle Owner Account 4. Customer Type 5. Email address for e-ticket [opt] 6. GVW [opt] 7. Vehicle Tare [opt] 8. Tare Updated Date [opt] 9. Trailer ID – License Plate [opt] 10. Trailer Tare [opt] 11. Trailer Tare Updated Date [opt] 12. Electronic ID tag [opt] 13. Fleet ID [opt] 14. Status: Active / Inactive / Disposed

3.3. Billing Assignments

Daily changes for Billing Assignments are to be recorded and used to populate transaction data fields, and to manage cross-billing from hauler companies to billing account customers.

At least one “Additional Data Field” must be included in the record; it would be helpful to have more than one, and to be able to specify how to map the additional fields to transaction fields.

1. Assignment ID – system generated 2. Vehicle ID 3. Hauler Account – lookup Vehicle Owner Account 4. Account – billing account 5. Start Date/time 6. End Date/time 7. Origin 8. Material type 9. Additional Data Field [opt] – e.g. Project Number, Route Name 10. Waste Assessment ID [opt] – associated Waste Assessment 11. Status : Active / Inactive

3.4. Offences

Offences must be recorded against the vehicle with a status field to assist staff responding to it. Ideally logic can be associated with categories of offences, e.g. for a “Truck Over

P a g e | 6



GVW” offence, categorized as “Immediate Supervisor Notification”, a notification can be dispatched. Other types of offences may require more complex processing which could be handled outside the Solution, but will need to be initiated by a web service call.

1. OffenceID – system generated 2. VehicleID 3. Date/time 4. Transaction ID 5. OffenceType – from list 6. Offence Category – from list 7. Notes 8. Offence Status: New / Open / In Progress (external workflow) / Closed

3.5. Waste Assessments

There are operational and regulatory reasons for requiring pre-approval for specific waste types (e.g. clean fill or asbestos waste).

Customers submit a Waste Assessment form, which is processed through an internal workflow where the material, quantity and dates are rejected or approved. Upon approval, the customer is advised of the acceptable delivery date(s).

The City wishes to include accounting for loads against approved allocations in the Solution. The allocations apply to a customer, and may be used by multiple vehicles.

1. WasteAssessmentID – System-generated 2. Facility ID 3. CustomerID – AccountID for commercial customer; VehicleID for non-Account customer 4. Material Type 5. Approved Allocation 6. Quantity Type : Total Tonnage / Loads per day 7. Start Date 8. End Date 9. Status : Open / Closed 10. Manifest Required 11. Remaining Allocation 12. Notes

P a g e | 7


Annex 3 - Descriptive Requirements 3.6. Default Destinations

For each facility, the default destination for a material type should be set. For the Vancouver South Transfer Station and Kent Yards, the destinations are unlikely to change often. For the Vancouver Landfill, certain material type destinations can change a few times daily.

Weighmasters should be able to adjust the defaults for the facility. 1. FacilityID 2. Material type 3. Default Destination

CUSTOMER SETUP 3.7. Account Customers and Hauler Customers

Account Customers are a business with a City billing account, with invoicing details maintained in a separate financial system (Tempest or SAP). Hauler customers have no billing privileges; their vehicles are authorized by account customers to cross-bill.

Within the Solution, the City wishes to capture the following: 1. AccountID 2. Customer Type e.g. Commercial, Hauler, City Engineering, Charity 3. Business Name 4. Credit limit 5. Available credit 6. Billing system : Tempest, SAP 7. Billing system Account ID 8. Status : Active, Inactive, Closed 9. Contact – Name, Phone, Email 10. E-ticket Email 11. Notification Email 12. Notes

3.8. Customer Type Profiles

Data fields, default values, business rules for processing and fee calculations depend on the customer type.

The Solution should address the functionality listed below.

1. Specify whether the customer type is

a. Service vehicle – no transaction, just open the gate b. Cash customer c. Account customer - Billing or Hauler

2. Specify the input fields active for a transaction 3. Specify the data labels for extra data fields 4. Specify validation criteria for extra data fields 5. Provide default values for each field using the data or method specified, e.g. recall last

value, use last value from transaction within X number of days, use a specific value, retrieve a value from an external system (web service call with parameters)

P a g e | 8



6. Determine the billing account using a method (e.g. owner account, lookup vehicle assignment)

A list of typical Customer Types is included in Appendix 1-D.

SUPPORTING LISTS

All Facilities will use the same Supporting Lists: for some lists, the Solution must limit the display on pick lists to items relevant for the Facility.

3.9. Material Types

Limit the items displayed on a pick list to those relevant to the Facility.

1. Material code or abbreviation 2. Material type label 3. Fee type – by weight, per unit, flat fee 4. Relevant facilities

3.10. Offence Types

1. Offence code or abbreviation 2. Offence type label 3. Offence Category

3.11. Vehicle Types

1. Vehicle Type code or abbreviation 2. Vehicle type label

3.12. Origin

1. Origin code or abbreviation 2. Origin label

P a g e | 9


Annex 3 - Descriptive Requirements 3.13. Destination

Limit the items displayed on a pick list to those relevant to the Facility.

1. Destination code or abbreviation 2. Destination label 3. Relevant Facilities

3.14. Payment Types

1. Payment Type code or abbreviation 2. Payment Type label

3.15. Facilities

1. Facility code or abbreviation 2. Facility label

P a g e | 10


Annex 3 - Descriptive Requirements 4. BUSINESS RULES

Instructions for Business Rules Describe how the Proponent’s Solution executes the business rules; use the Scenario responses to describe functionality. The response must be no more than one (1) page for each business rule set.

4.1. Fee Calculations

Fee calculations are becoming increasingly complex. All of the following are used in transaction fee calculations:

a) Facility b) Time of day c) Origin d) Customer type e) Material type(s) f) Sliding scale rates by material type g) Material type surcharges by weight and/or per unit h) Fines i) Minimum fees j) Service Charges k) Multiple taxes l) Chained transactions – only one Service Charge m) Campaigns – e.g. discounted rates for Vancouver’s “Keep Vancouver Spectacular”

campaign

The City must be able to specify the fee calculation logic and make periodic changes to the rules (i.e. not hard-coded). The Start date and End date for a rule must be tracked, and obsolete rules must be preserved such that fees can be recalculated for a specific date.

The Proponent should demonstrate the Solution can perform the fee calculations as currently listed on the Vancouver.Ca website: http://vancouver.ca/home-property-development/landfill-fees-and-charges.aspx Note to Proponents: The City fee calculations are coordinated with Metro Vancouver’s bylaws. Additional information is available on the Metro Vancouver website: http://www.metrovancouver.org/services/solid-waste/bylaws-regulations/tipping-fee/Pages/default.aspx

4.2. Offence Processing

For each category of offence the Solution should initially do one of the following: • Send a web service call to an external system to start a workflow; e.g. Supervisor

notification and investigation; set the Status to “In Process”; • Set a Dump Lock on the Vehicle; set the Status to “Open”; or • Set the Status to “Open”.

As the offence is dealt, with the status field may be updated, eventually becoming “Closed”. The status field will be used to filter offences displayed on the Weighmaster’s screen (e.g. only non-Closed offences).

P a g e | 11

http://vancouver.ca/home-property-development/landfill-fees-and-charges.aspx

http://www.metrovancouver.org/services/solid-waste/bylaws-regulations/tipping-fee/Pages/default.aspx

http://www.metrovancouver.org/services/solid-waste/bylaws-regulations/tipping-fee/Pages/default.aspx


Annex 3 - Descriptive Requirements 4.3. Code Grouping

For consistent reporting it is desirable to specify often-used grouping criteria such as: • the list of material types may be grouped into 5 general types • a set of customers hauling demolition waste defined by their Account IDs • customer types may be grouped to combine all City customers, Metro municipal

customers, commercial customers (+/- account) and residential • charity customers by origin

For each group 1. Grouping Set Name 2. Variable(s) for grouping 3. Per Group entry

a. Group label b. Criteria for inclusion in the group

4. Default Group 5. Include/Exclude Default Group

P a g e | 12


Annex 3 - Descriptive Requirements 5. Scenarios

5.1. To facilitate the Proponent’s comprehension of the City’s requirements, a series of Scenarios is provided in this section.

The scenarios represent a subset of the Requirements, which are provided in detail in Annex 2 – Detailed Requirements spreadsheet.

5.2. Instructions for Scenarios

Explain how the Proponent’s Solution provides the functionality, with extra attention to the items referenced in each scenario’s “Please highlight” section. The explanation for each scenario should include no more than two (2) pages of text, totalling a maximum of four (4) pages of text and graphics combined.

Proponents may respond by using Annex 3A – Response Addendum for Annex 3.

5.3. List of Scenarios

A. Customer with Rental Vehicle B. Commercial Customer – Cross-Billing to a Different Account C. Waste Assessment Loads to VLF D. Fee calculation rule change – Spring cleanup for Vancouver E. Power outages

P a g e | 13


Annex 3 - Descriptive Requirements Scenario A - Customer with Rental Vehicle It is City policy to collect a deposit (cash or credit) from inbound customers in rental vehicles, vehicles with out-of-province License Plates, or temporary Licenses (no valid plate). Offences cannot be registered against these vehicle IDs since they are not likely to be driven by the same customer on a subsequent visit. The number of rental vehicles using the Facilities is increasing due to the popularity of car-share services in the Vancouver area (e.g. Modo, Evo, Car2Go, ZipCar). ----- Start of Scenario ----- Inbound: A resident using a Rent-a-Wreck van arrives at the scale with a load of household garbage. Weighmaster Bill assesses the load and requests a $20 deposit. The resident pays the deposit with cash. Outbound: The total fee comes to $85. The resident asks Carl, the outbound Weighmaster, to charge the whole fee to his credit card. ----- End of Scenario ----- Please highlight the following:

- How would a deposit be registered on an inbound transaction? - For a cash deposit/cash payment situation, how does the system present the net

payment required at the outbound scale? - Where the driver wishes to change payment type, as in this scenario: from cash to

credit, how is the cash refund handled? - If the resident wanted to leave his $20 cash deposit, and just pay the remaining $65

($85 - $20) on his credit card, what steps does Carl take? - For credit deposits, the Weighmasters’ preferred method of handling payment is to

refund the credit deposit, then bill the full fee in a new credit card transaction, resulting in a single transaction on the customer’s credit card statement. Please show the steps to do this and comment on how this process is reflected in Bill’s and Carl’s close-out records.

- Does the end-of-shift cash balance procedure for a Weighmaster list and balance deposits?

- Does the facility reconciliation balance deposits and deposit refunds?

P a g e | 14


Annex 3 - Descriptive Requirements Scenario B - Commercial Customer – Cross-Billing to a Different Account

A commercial hauler customer may be bringing loads to a Facility on behalf of a different account customer. The account customer must provide authorization for a hauler’s vehicles to bill loads to the account customer; the authorization must include the vehicle ID(s), origin, material type, and range of dates. On recognizing the Vehicle ID, the Solution must populate the transaction fields with default values, including the billing account, according to one of the following:

- If there is a current cross-billing authorization in Billing Assignments, use the corresponding account;

- If the vehicle is registered to a billing account, use the billing account; OR - Prepare a non-account transaction.

----- Start of Scenario ----- Joe Trucker has contracted his services and truck to Huge Hauling. The truck is registered in the vehicles table with Huge Hauling as the vehicle owner account, and the vehicle entry includes Joe’s email address for copies of e-tickets. Busy Boys Site Preparation is a billing account holder; they have contracted Huge Hauling to augment their fleet for Project 5544 that will last from February 15 to February 22, hauling loads of material type Demo Waste. Inbound: It’s February 16. Joe arrives at the inbound scale; the Solution matches his vehicle ID to the active billing assignment and displays the billing information to Eko, the Weighmaster, and populates the extra data field with the Project number. Eko checks the load material type matches the authorized type. There is a valid stored tare for Joe’s vehicle so the transaction can be completed at the inbound scale. Joe is advised where to drop his load, and to use the unattended lane (gated) to exit. Upon completion of the transaction, dispatch tickets via email to:

- the billing account holder – Busy Boys Site Preparation - the hauler company – Huge Hauling - optional contacts listed with the vehicle – Joe Trucker

Provide paper tickets, if required, to the driver. The available credit value for Busy Boys Site Preparation account is decremented by the cost of the load. If the available credit value drops below the defined threshold an alert is sent to the account contact. If the available credit value drops below zero, a Charge Lock is placed on the account and alerts are sent to the Account contact and the City’s Account Administrator. ----- End of Scenario ----- Please highlight the following:

- Comment on the accuracy and reliability of License Plate Readers; is it different for trucks vs. cars?

- Describe the steps to enter Billing Assignments (authorization) for a single vehicle, or for a subset of a hauler company’s vehicles.

- How are changes to Billing Assignments logged? - If there is more than one active Billing Assignment, how is the Weighmaster alerted and

shown the possible selections? What logic would be used in an automated situation? - Can corrections be made by the Weighmaster if necessary, and the reason for an

override added to the transaction Notes e.g. when a vehicle is being used for one project in the morning and a different one in the afternoon?

P a g e | 15



- Describe the outbound process, from the driver’s point of view. - In case of a dispute over authorization, how can the steps be traced? - If there are offences registered against the vehicle ID how is the Weighmaster alerted? - If a Charge Lock exists for an account, how is it displayed to the Weighmaster?

P a g e | 16


Annex 3 - Descriptive Requirements Scenario C - Waste Assessment Loads to VLF Seymour Excavations has an approved Waste Assessment to bring 6 loads per day of Clean Fill to the Landfill, for the month of March. They have 4 vehicles assigned to the project: two of their own vehicles and two Hauler vehicles. ----- Start of Scenario ----- One of the Hauler’s authorized vehicles arrives at the Landfill with a load of clean fill. Fred, the Weighmaster, is alerted to both the Billing Assignment (cross-billing authorization) and the active Waste Assessment available for this vehicle. The Waste Assessment alert displays the approved material type and remaining allocation; at this time 2 loads have already been processed today, so the remaining allocation is 4 loads. After checking the material type Fred processes the transaction against the Waste Assessment, ensuring the Waste Assessment’s remaining allocation is docked for this load. Later in the day, the vehicle returns. This time the remaining allocation is 0 loads, since other vehicles have been bringing loads associated with the same Waste Assessment. Fred makes a call to the Supervisor, who OKs the extra load. Fred processes the transaction and the remaining allocation is docked (now a negative number). He advises the driver no further clean fill loads from Seymour Excavations will be accepted today. The vehicle returns again, this time with a load of Demo Waste. Fred sets the material type, clears the Waste Assessment reference from the transaction and processes it as a normal cross-billed load to Seymour Excavations. At the end of the business day “per day” Waste Assessments have their Remaining Allocation reset to the maximum approved quantity. “Total Tonnage” Waste Assessments are not reset. The Status flag is modified for expired Waste Assessments. Supervisors are provided reports showing the previous day’s Waste Assessment transactions, with highlighted overages. Another report is provided showing the total approved Waste Assessment material quantities by type for the next 10 days at their facility. ----- End of Scenario ----- Please highlight the following:

- what the steps are to enter the details for an approved Waste Assessment - how an Active Waste Assessment could be increased in quantity or extended over a

longer time period - how the mix of vehicles associated with a Waste Assessment can be changed over time;

and how the changes are logged - if additional vehicles arrive, the Weighmaster must be able to exercise discretion in

accepting them or turning them away: the Solution must simply track the loads - How would the Solution alert the Weighmaster to Billing Assignment, Waste

Assessment, and credit limit issues? - Is there a mechanism to send out reports for account customers, with multi-day Waste

Assessments, showing daily load totals and remaining allocation (total tonnage type) weekly?

P a g e | 17


Annex 3 - Descriptive Requirements Scenario D – Fee rule change – Spring Cleanup Campaign for Vancouver Ralph is an Administrative User, responsible for setting the rules for Fee Calculations. ----- Start of Scenario ----- Vancouver runs a spring cleanup campaign, encouraging citizens to recycle reusable items and bring garbage to the Landfill. The campaign provides citizens with free tipping of a moderate amount of waste, with reduced rates applying to quantities over the limit. Ralph needs to add rules to reflect the following:

a) The campaign dates are from April 15 to April 30 b) The rules apply to Residential customers (Customer Type) from Vancouver (Origin) c) There is no charge for the first 300 kg of waste – material types: garbage, wood waste,

green waste, recyclables (drywall is not included) d) For quantities over 300 kg and under 500 kg, there is a 20% reduction on regular rates;

for quantities over 500 kg, regular rates apply. e) The resident receives the discounts on only one load per day, per vehicle.

Before the rules are placed into the production system, Ralph wants to test them. He has created a set of example data to run against the rules, to check that the fee calculation is operating correctly. ----- End of Scenario ----- Please highlight the following:

- How does Ralph set up the fee calculations for the campaign? - Are the changes to the rules in the production system logged? - If Weighmaster Mary tries to change the rules, is a security event raised, and is a

notification sent? - How would the fee calculation be tested, using Ralph’s example data?

P a g e | 18


Annex 3 - Descriptive Requirements Scenario E – Power Outages Each Weigh Scale facility is equipped with emergency power, sufficient for at least one (1) hour operation of two scales including the application server, network and two workstations. There are UPS units for the local server. City Hall’s central server for the Solution is not on an Emergency Power circuit, and would be unavailable if power failed there. In the Disaster Recovery Plan, the central server for the Solution is ranked at the third level down of criticality, thus a delay of several days would be expected for recovery. ----- Start of Scenario ----- At the Landfill, a wind storm causes a tree branch to strike a transformer causing a power outage. Within one minute the emergency generator starts and staff continue to run all the scales normally for 30 minutes. Then the old generator fails. After 45 minutes the UPS units are almost exhausted and the decision is made to operate manually, creating paper tickets and records, cash or account only. ----- End of Scenario ----- Please highlight the following:

- For the Landfill situation, is it possible to verify that there is no data loss as the systems switch over to UPS power?

- When power becomes available at the Landfill again, how are the manual transactions (paper records) entered into the Solution?

----- Start of Scenario ----- On a different occasion, an explosion occurs in an electrical vault near City Hall. Power will be out for 10-12 days, while repairs are made. The City’s IT group puts their Disaster Recovery plan into operation, and informs staff the central Solution server will be available at a temporary location in 3 days. ----- End of Scenario ----- Please highlight the following:

- How would the Solution deal with the unavailable central server? - What steps are necessary to direct data traffic to the temporary central server? - Given that the temporary server would be a backup restored from a specific date and

time, how would the Solution ensure intervening transactions are replicated to the temporary central server?

P a g e | 19


Annex 3 - Descriptive Requirements 6. New Technology

The City anticipates adding new functionality at the Weigh Scale Facilities to meet objectives for reducing paper use, streamlining processes and providing digital access to its services.

Three items should be addressed in the proposal: • Mobile device access for City staff • Unattended Scales • City Web Portal Integration

6.1. Instructions for New Technology

Describe how the Proponent’s Solution provides the functionality required, and provide recommendations on how to successfully achieve the goals. Multiple options may be provided. The response must be no more than 6 pages for each new technology.

Proponents may respond by using Annex 3A – Response Addendum for Annex 3.

6.2. New Technology – Mobile device access for City staff The City’s goals and preferences are given below. It is understood the Proponent may have other recommendations, or a preferred method of delivering the functionality. Alternatives may be given consideration by the City. There are several situations where access from a mobile device would be advantageous:

- At the entrance to the residential Drop-Off, where the Yard Attendant reviews the load - Within the residential Drop-Off, where a roving Yard Attendant verifies surcharged

items and adjusts material types - At the tipping area, where an Inspector reviews commercial loads and adds fines and

surcharges - At the Transfer Station, when Lanes 1, 3 or 4 are to be used as Attended Scales in the

reverse direction (note: space constraints preclude permanent kiosks) - At Kent Yards, for the Aggregate Loader Operator to verify if the truck driver is picking

up the correct material A range of devices could be used depending on the complexity of the task: a device the size of a smartphone or mini-tablet would be suitable for verification tasks; however, a full-size tablet (e.g. iPad), would be appropriate for inbound check-in tasks. Assumption: the devices will connect to the City network via Wi-fi, and secure login. The devices will likely be restricted to internal City networks only (i.e. no public Internet access). For an application using web technology, Responsive Web Design principles should be used for maximum flexibility across devices. Screens for tasks away from the scalehouse (e.g. Yard, tipping area), should be designed for the operating conditions and staff needs (e.g. large buttons, simple screens, potential for using a stylus instead of (gloved) fingers in the winter).

P a g e | 20


Annex 3 - Descriptive Requirements 6.3. New Technology - Unattended Scales The City’s goals and preferences are given below. It is understood the Proponent may have other recommendations or a preferred method of delivering the functionality. Alternatives may be given consideration by the City. To efficiently process internal and Account customers, the City intends to provide Unattended Scales at VLF and VSTS. The data to be collected is the same as at the Attended Scales, namely: Vehicle ID; Facility; Lane; Time In/Out; Weights; photos; and metadata. Default data for the transaction shall be drawn from the database, including billing account authorization. The driver must correct and confirm the data before the inbound gate will open. There should be as few physical components as possible, to reduce support needs. To serve that goal and Vancouver’s Greenest City objective, there may be no printers in the terminals, subject to compliance with Canada Weights & Measures Act. Tickets will be distributed via email. Outbound terminals may be simplified to a display screen and intercom. The City is averse to distributing swipe cards to commercial and internal customers. The City prefers to obtain Vehicle ID by either License Plate Recognition or vehicle-mounted RFID. Due to space constraints and safety concerns, the City prefers a setup in which drivers do not exit their vehicles. There are a wide variety of driver window heights to be accommodated, as well as both left-hand and right-hand drive vehicles. To handle problems, a Weighmaster in the scalehouse must be able to: communicate with the driver over an intercom; remotely run the transaction; and operate the gate.

- Please provide a diagrammatic layout for an Unattended Scale, indicating the type and position of the physical components, under three scenarios:

o inbound o outbound o reversible

- Comment on the reliability and costs of license plate recognition and vehicle-mounted RFID, detailing the necessary equipment.

- Describe the inbound process from the driver’s point of view. - Describe the outbound process from the driver’s point of view. - If a driver has an issue at a terminal, describe how the Weighmaster in the scalehouse

can assist with the transaction. - If a web app is part of the process:

o Provide screen shots of the steps for driver o Describe the web architecture to support the process, including security o Indicate what web-related logging is done

P a g e | 21


Annex 3 - Descriptive Requirements 6.4. New Technology – City Web Portal Integration The City’s goals and preferences are given below. If the Proponent has other recommendations or a preferred method of delivering the functionality, the City may give consideration to alternative recommendations or methods. Two of the City’s corporate objectives are related to the web portal: 1) provide Digital Access to services; and 2) use technology to streamline tasks. There are several sets of capabilities planned for the City web portals in the near future, at three levels: public; account customers; and internal customers. New portal functions include forms and report submissions, communications and workflows. For example, Waste Assessment application forms will be submitted through the public portal. The Proponent is asked to provide information on how the Solution would integrate the following into the City Web Portal: Self-serve maintenance for Account customers (Secure Access)

- Manage vehicle list - Manage vehicle load description defaults - Manage billing assignments, i.e. cross-billing authorization (Billing customers only) - Review transactions - View Available Credit

Unattended Scale – may have mobile access to a web page or app for confirmation of metadata and billing information Note: The City will not consider a third-party portal for the following reasons: potential security concerns; potential interoperability with other City systems; potential auditing issues; potential lack of extensibility; and branding concerns. Please highlight the following:

- Is the functionality provided via API, web service calls, or configurable web components?

- What authentication methods are supported? - If the Solution uses web components, can the web components be styled to match City

branding? - Does the Solution allow updates to groups of records (e.g. selecting a group of vehicles

and updating them all with the same billing assignment)? - Describe the items logged, at the portal, for changes. - Can there be multiple login accounts with privileges to update a single account

customer?

P a g e | 22

Documents

RFP PS20161055 Provision of Weigh Scale Management and ... · Proposal Submission , Section 11.4.1 b) Annex 3). Background information and general instructions need not be included