Request for Proposal
ANPR and MIR Service Procurement (procured together or separately)
SSA-L, Appendix 1 Customer Requirements Specification
ANPR and MIR service procurement - SSA-L Appendix 1
Version log
Version Initials Date Comments/ amendments 0.9 GK 11.01.2019 Preliminary RFP 1.0 2.0 3.0
Customer Page 2 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Contents
Scope of the Agreement ...... 5 Background ...... 5
About the Customer ...... 6
Business Overview...... 7
Background ...... 7
Definitions ...... 10
Roadside ANPR ...... 10
Identification of a Transaction ...... 10
ANPR Recognition Results ...... 11
MIR Recognition Results ...... 12
Customer Interface for the ANPR Solution and MIR Module ...... 14
Specification of functional requirements ...... 15 General Requirements ...... 15
ANPR Solution Requirements ...... 16
MIR Module Requirements ...... 18
Single point of contact (Service Desk) ...... 20
User Administration and Identity Access Management ...... 20
Security ...... 22
Documentation ...... 23
Audit and Quality Assurance ...... 23
Options ...... 24
Specification of non-functional requirements ...... 25 Performance level and sizing ...... 25
Availability and performance ...... 25
Basic infrastructure and monitoring ...... 26
Test and Development - Environment, Tools and Methodology ...... 27
Specification of mir service...... 28 General Requirements ...... 28
Customer Page 3 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Competence and Language ...... 29
User Administration ...... 29
Quality Requirements...... 30
Other requirements ...... Feil! Bokmerke er ikke definert.
ANPR AND MIR SERVICES Specification of other requirementsFeil! Bokmerke er ikke definert. General Provisions on External Legal Requirements and MeasuresFeil! Bokmerke er ikke definert.
Personal Data ...... Feil! Bokmerke er ikke definert.
Electronic Communication and Processing Requirements between the Customer and the Contractor ...... Feil! Bokmerke er ikke definert.
List of Annexes to Appendix 1 ...... 32
Customer Page 4 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SCOPE OF THE AGREEMENT
BACKGROUND
Vehicles are registered by roadside equipment as they pass through a toll station. The registration is enabled either by vehicle mounted on-board equipment (OBE) or by images of the license plate, taken by one or more cameras. The roadside equipment then performs image recognition, and data for the passage is compiled with the images in a Transaction.
The 5 Regional toll companies in Norway, Vegfinans AS, Ferde AS, Vegamot AS, Bompengeselskap Nord AS and Fjellinjen, (hereafter RBPS) invites Bidders to a Competition with negotiation for procurement of an ANPR and MIR service.
The scope of the ANPR and MIR services is to procure both an ANPR service and a MIR service, herby referred to as the “Services”.
The ANPR service and MIR service can be procured together or separately. Bidders can bid on one or both contracts.
The ANPR service procurement includes a software solution for Automatic Number Plate Recognition (ANPR) and a Manual Image Review (MIR) module. The ANPR service will be a central service/solution used by the Customer (see section 1.2 below), complementary to the existing roadside ANPR.
The scope for the MIR service is operation of the MIR module which is a part of the ANPR service/solution.
Each RBPS is a service recipient. All regional toll companies are service recipients for the ANPR service. 3-4 regional toll companies will also be service recipients for the MIR service.
The ANPR service shall be implemented as part of the new system solution for toll charging in Norway. The MIR service will be implemented when the existing regional MIR service agreements expires.
Transactions with attached images and confident ANPR results from the roadside ANPR can be processed automatically by AutoPASS IP (see section 1.3.1 below). The Customer is responsible for configuring a roadside ANPR confidence threshold in AutoPASS IP, which controls whether a transaction is passed on to the Contractor’s solution or not. Note that it is likely that the Costumer configures this such that all transactions with attached images are sent through the central solution, as this is advantageous to ensure additional confidence in identification. Also, should it be the case that the Contractor’s solution feature incremental machine learning capabilities, it is important to be able to provide as much good data as possible.
AutoPASS IP provides image recognition results from the roadside ANPR (where available) for consideration by the Contractor’s solution, although the use of this information is at the Contractor’s own risk.
Images shall be stored in the Image Database managed by the Customer on the Customer’s platform. Images are never to be removed or copied by the Contractor.
Customer Page 5 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Outlook for the Future
In a long-term perspective, the ANPR solution shall lay the basis for further automation and reduced manual processing. The Customer expects to see a rise in passages. This will increase the emphasis on identification through machine vision, particularly technology beyond simple optical character recognition (OCR) to reduce vulnerability to obscured license plates. Also, a large majority of passages are performed by recurring vehicles. By using incremental machine learning, the Customer hopes to continuously improve the automatic identification rate.
ABOUT THE CUSTOMER The main actors in the Norwegian toll industry are the authorities, represented by the Norwegian Public Roads Administration (NPRA), the Toll Collectors (TC) organized in regions and known as RBPSs, the Toll service providers (TSP) and the Service users (Customer or vehicle owner).
As part of the tolling reform the responsibility for the systems used for tolling in Norway may be transferred to the five regional Toll Collectors in the future.
The five regional toll companies (RBPS) are:
Bompengeselskap Nord AS: Region north consisting of the county councils Nordland, Troms and Finnmark.
Vegamot AS: Region central consisting of the county councils Møre og Romsdal, and Trøndelag
Vegfinans AS: Region east consisting of the county councils Akershus, Østfold, Hedmark, Oppland, Buskerud, Vestfold and Telemark
Fjellinjen AS: Region Oslo consisting of the county councils Akershus and Oslo
Ferde AS: Region south west consisting of the county councils Aust-Agder, Vest-Agder, Rogaland, Hordaland and Sogn og Fjordane
With regards to this procurement, the Customer is the RBPS which will be responsible for, and enter into, the Agreement.
In addition to the RBPS, other additional toll companies (Svinesund, etc) may become service recipients in the future.
As part of the reform the responsibility for the ANPR service may be transferred to a shared service company for the regional Toll Collectors in the future.
Customer Page 6 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
BUSINESS OVERVIEW
Background
The Norwegian Electronic Toll Services
The TC is a company or other legal entity that has the authority to claim payment for road or ferry tolls for public use. The TSP has an agreement with the NPRA and the TCs which give the right to sign AutoPASS agreements with an end user,and is responsible to issue the service amount to the TC independent of the payment from the end user. The TSP will issue an OBE (on board unit) to the end user. The TCs responsible for all vehicle owners not having an AutoPASS agreement connected to their vehicle. The billable information is based on the license plate number (LPN) and the owner information is gathered through a lookup in the vehicle register.
AutoPASS is the Norwegian community for the collection of road tolls. It is owned by NPRA. All tolls stations in Norway are free flow systems, except for the Atlantic Ocean Tunnel and some ferries. With a valid AutoPASS agreement and an OBE in the vehicle, a discount is given to the end user for the use of toll roads.
The Norwegian toll industry has been through changes during the last decade, both in volume and technology. The ongoing toll reform will generate organisational changes in the Norwegian toll industry. In addition, there are ongoing changes in the European Commission through the "Europe on the Move". The aim of the modernization of European mobility and transport is to help the sector to stay competitive in a socially fair transition towards clean energy and digitalization.
Toll reform: På rett vei - reformer I veisektoren (Meld St 25 (2014-2025))
The Norwegian toll reform describes the direction and framework conditions for future organisation and operation of the toll sector in Norway. The main purpose is to increase the efficiency and usability/simplification of the toll services. The reform is changing the framework conditions of the industry, especially the actor roles and their responsibilities.
The reform is based on The European Electronic Toll Services (EETS) guide for the application of the directive on the interoperability of electronic road toll systems.
New system solutions for toll collection in Norway
Toll collection requires efficient and reliable IT-systems ensuring secure information and transaction flow. Today's system solution, called CS Norway, is leased from Q-Free ASA. This is a central system used by all toll companies in Norway.
During the first half of 2016, the NPRA conducted a conceptual study to explore different alternatives for future system solutions for toll collection in Norway. The study was conducted in cooperation with resources from NPRA and the service companies (the future RBPS), both in the project and the steering committee. The process resulted in a unified recommendation to choose the solutions that this procurement must interact with. The chosen concept was considered the one that best met defined needs, goals and requirements.
The new solutions, HUB and IP, have been procured, and they form an important basis for this procurement, with the expectation that it is operationalised by September 2019.
Customer Page 7 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Overview of current systems and vendors:
Table 1: Overview of current systems and vendors.
Systems Description Vendors
Tecsidel The roadside equipment is of differing Q-Free technologies and age. There are Roadside approximately 300 toll stations and 600 Kapsch collection lanes in Norway EFKON
AutoPASS HUB NPRA procurement, ready for implementation. Systor
AutoPASS IP NPRA procurement, ready for implementation. COWI
AutoPASS Operational NPRA procurement, ready for implementation. Systor Platform Service (OPS)
Two different solutions are in production for the EVRY different RBPS. UBW for Fjellinjen and AutoPASS TC Vegfinans. Own developed solution for Ferde, Ferde Vegamot and Bompengeselskap Nord.
Centralized solution included in the NPRA’s ANPR Q-Free CS-Norge system solution.
Runway
MIR Different service per RBPS. Q-Free
Escandino Service
The illustration in Figure 1 shows the value chain from Roadside through AutoPASS IP to the toll collector and toll service provider, with the AutoPASS HUB ensuring interoperability between the components and the integration with EasyGo and new commercial TSP's.
Customer Page 8 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Figure 1: An illustration of the new system solutions for toll collection in Norway..
A brief description of the functionality of the different components in Figure 1 are as follows:
• AutoPASS HUB will be the component ensuring interoperability between the different components and the wider community, both during and after all new systems are established and all current companies using the Central System have migrated to the new system solutions. The AutoPASS community consist of many actors, and these actors interact technically through exchanging messages and files. AutoPASS HUB is a transport infrastructure with the ability to send defined messages and files based on information given in the messages and files. AutoPASS HUB is mandatory for all actors in the AutoPASS payment collaboration and the defined data formats. • AutoPASS IP includes the common parts of the value chain for the toll collection; identifying passages based on information of agreements coming from the Toll service provider (TSPs), and pricing of passages based on the information in the agreement and the price rules and logic managed in the AutoPASS IP. AutoPASS IP further has the needed business logic to address the correct Toll collector (TC) or TSP, which should enforce the priced transaction. AutoPASS IP will also manage all configuration such as toll stations and lanes, prices, status and codes. AutoPASS IP is mandatory for all actors in the AutoPASS community. • Image recognition service is the Identification Module that abstracts away the identification requests from AutoPASS IP, and requests ANPR/MIR accordingly. It also hanles all images arriving from the RSE. • ANPR & MIR is the services that is the scope of this procurement. • Toll Collector (TC) contains the functionality needed for a TC to operate in the AutoPASS community. This includes, but is not limited to configuration, invoice basis,
Customer Page 9 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
reconciliation, invoicing, payments, debt collection, interfaces to banks, debt collection, invoice distribution, external accounting and reporting. • Toll Service Provider (TSP) contains the functionality needed for a TSP to operate in the AutoPASS community. This includes, but is not limited to reconciliation, invoicing, debt collection, OBU logistics, customer and agreements, self-service, case handling, interfaces to banks, debt collection, invoice distribution, external accounting and reporting. The AutoPASS TSP solutions will be established, procured and implemented in parallel with all other components. • The EasyGo HUB is the HUB ensuring interoperability to and from all companies within the EasyGo community. The EasyGo HUB will remain and have the same function as today. • The roadside equipment (RSE) varies in age and is owned and managed by each TC. Depending on the local setup, the roadside equipment will send passages continuously, on an hourly or daily basis. All roadside equipment stores passages for at least 3 days. The roadside will remain and have the same function as today. Today, there is no automatic verification of passages sent from roadside or that they are correctly received by the current Central System. Passages registered on the roadside are sent to the AutoPASS IP via the AutoPASS HUB.
DEFINITIONS
Roadside ANPR
The roadside detects and tracks passing vehicles subjected to toll by partly using image processing technology. Therefore, it takes images from passing vehicles (rear and front). These images are processed with the roadside ANPR. For vehicle passages also having an OBU transaction, the roadside ANPR result is checked against the LPN in the corresponding OBU Statuslist. If the LPNs are the same, all associated images are deleted immediately.
Today there are four different contractors that deliver roadside solutions. Some of the roadside equipment is about 15 years old, and some have just recently been installed. Hence, the images may be of varying quality, depending on the technology used. The same can be said about the ANPR technology installed roadside, some have higher reading accuracy than others.
Identification of a Transaction
Note that every request is in terms of a transaction, i.e. a passage with a front and/or rear image of the vehicle, among other metadata. It is imperative that both the ANPR and MIR solution utilize the correlation between images belonging to the same transaction, as opposed to simply processing images individually. For example, assuming the ANPR service uses a multi-engine setup, it is possible to achieve much more statistically confident results when considering consistency (front and rear image through same engine) and consensus (same image through different engines) in the results, as illustrated in Figure 2.
Customer Page 10 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Figure 2: Consistency and consensus in ANPR multi-engine transaction results.
ANPR Recognition Results
In the following sub-sections, the different parameters for evaluating ANPR results and the method of determining them are specified.
Recognition Rate
[1] The total number of transactions identified by ANPR.
[2] The total number of Identifiable transactions processed by ANPR, which can be established by:
a. [1] + transactions ANPR fail to identify, but mark as Identifiable.
b. A manual control of a test data set.
c. Transactions identified by ANPR + those not identified by ANPR, but identified by MIR.
[3] The ANPR Recognition Rate is defined as: 100 * [1] / [2].
The ANPR Recognition Rate (RR) measures how well the ANPR manages to identify transactions, but without penalisation for bad input data.
False Positive
[4] False Positives are transactions identified by ANPR where the result turn out to be incorrect (wrong LPN and/or wrong Nation Code). This can be established by: a. A manual control of reprocessed transactions (same Transaction ID).
Customer Page 11 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
b. A manual control of a test data set.
[5] The ANPR False Positive rate is defined as: 100 * [4] / [1].
The implication of a ANPR False Positive (FP) can be that the wrong vehicle owner is billed, which leads to complaints and additional costs for handling the transactions. It is therefore very important that this error rate is low.
False Negative
[6] False Negatives are transactions that ANPR incorrectly mark as Not Identifiable. This can be established by:
a. A manual control of transactions marked Not Identifiable by ANPR.
b. A manual control of a test data set.
[7] The ANPR False Negative rate is defined as: 100 * [6] / [2].
The implication of ANPR False Negatives (FN) is that transactions are incorrectly categorized as Not Identifiable. This does not have any direct consequence for the Customer, as the Identification Module decides (based on process rule from AutoPASS IP) whether or not to call MIR on a transaction that ANPR fail to identify. However, if the FN rate is high, it will give an artificially high RR, masking poor performance.
MIR Recognition Results
In the following sub-sections, the different parameters for evaluating MIR results and the method of determining them are specified.
False Positive
[8] The total number of transactions identified by MIR.
[9] False Positives are transactions identified by MIR where the result turn out to be incorrect (wrong LPN and/or wrong Nation Code). This can be established by:
a. A manual control of reprocessed transactions (same Transaction ID).
b. A manual control of a test data set.
[10] The MIR False Positive rate is defined as: 100 * [9] / [8]
The implication of MIR False Positives (FP) can be that the wrong vehicle owner is billed, which leads to complaints and additional costs for handling the transactions. It is therefore very important that this error rate is low.
Customer Page 12 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
False Negative
:
[11] The total number of Identifiable transactions processed by the MIR service. This can be established by:
a. A manual control of a test data set.
[12] False Negatives are transactions that MIR service incorrectly delete/discard. This can be established by:
a. A manual control of transactions deleted/discarded by MIR.
b. A manual control of a test data set.
[13] The MIR False Negative rate is defined as: 100 * [12] / [11].
The implication of MIR False Negatives (FN) is that transactions liable to toll are incorrectly deleted/discarded, which results in lost income for the Customer.
Customer Page 13 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
CUSTOMER INTERFACE FOR THE ANPR SOLUTION AND MIR MODULE
To abstract away the ANPR and MIR interfaces, AutoPASS IP sends requests for the identification of a transaction through an Identification Module, as illustrated in Figure 3. This module is responsible for requesting ANPR and/or MIR, based on a process rule in the request from AutoPASS IP. Note that this means that ANPR and MIR are called and treated separately, although this does not prevent the ANPR and MIR solutions from communicating between themselves.
Figure 3: Interface hierarchy overview. The red dashed ring indicates the scope of this procurement.
The interface to the Identification Module is specified in Appendix 1 Annex 4, while the Image Database and its REST API are described in Appendix 1 Annex 6 and 5, respectively.
The Customer’s Technical Platform is described in Appendix 1 Annex 1.
Customer Page 14 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SPECIFICATION OF FUNCTIONAL REQUIREMENTS
The focus of the procurement is the following:
• Stable and efficient solution • Flexible and scalable solution • Data control and information security • Features that continuously improve ANPR identification rates and lowers the need for MIR
GENERAL REQUIREMENTS
General requirements that are common for the ANPR solution and the MIR module.
Table 2: General requirements.
ID Description
The ANPR service should be based on a modern ANPR solution. The solution should have technology and functionality for best possible recognition result. 2.1.1 Norway have challenging climate, some old roadside equipment, etc.
Correct identification of a transaction requires that the License Plate (LP) is correctly identified. This includes both the License Plate Number (LPN) and 2.1.2 Country Code.
The images shall always reside on the Customer platform. Metadata added by the 2.1.3 Contractor may require installation and this shall be described.
2.1.4 Images shall never be removed or copied by this Contractor.
The Service shall run on the Customers technical platform, as described in 2.1.5 Appendix 1 Annex 1. Operating the Service is the responsibility of the Contractor.
The Service shall interface the Identification Module, as described in Appendix 1 2.1.6 Annex 4.
The Service shall interface the Image Database, as described Appendix 1 Annex 2.1.7 5.
2.1.8 It shall be possible to extract reports in excel and pdf format.
Customer Page 15 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
It shall be possible to manually and automatically forward reports to the email 2.1.9 address or mobile number of intended recipients.
It shall be possible to configure automatic reporting based on chosen parameters 2.1.10 and within a desired interval.
The Contractor shall carry out testing of the service and describe how this is done, 2.1.11 together with a report concluding the results.
2.1.12 The Contractor shall carry out stress testing (load) of the service.
ANPR SOLUTION REQUIREMENTS Table 3: Requirements specific for the ANPR solution.
ID Description
Transactions that ANPR fail to identify shall be marked as either Identifiable or Not Identifiable, and the Contractor shall describe their use of reasons of 2.2.1 rejection.
Transactions marked Not Identifiable should as a minimum be given the following labels (or similar):
• No Visible LP
2.2.2 • Object not Liable to Toll
The Contractor shall describe its standard interface to the image database and 2.2.3 procedures for setting up the ANPR solution within the Customer’s Infrastructure.
The ANPR solution shall store results from transactions for a period of minimum 1 year to ensure that reprocessing of the same transaction never produce the same 2.2.4 result.
The Contractor shall describe a possible mechanism to prevent that the same 2.2.5 vehicle is wrongly identified multiple times.
Customer Page 16 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
The ANPR solution shall be able to identify LPs from different countries as specified in Appendix 1 Annex 7. The Contractor can suggest additional countries than those listed, as long as this does not diminish the Recognition Rate for those already 2.2.6 listed.
The Contractor shall describe their solution regarding LPs from countries with 2.2.7 nearly similar LPs (e.g. Lithuania/Sweden).
The contractor shall provide an API for exporting all data (e.g. LPN, LPN Confidence, Country Code, Country Code Confidence, ANPR results from roadside (LPN, Country Code and Confidence), LPN identified/not identified/ wrongly identified, Country Code identified/not identified/wrongly identified, identification rule used, time and place).
The Contractor shall also describe their standard reporting system regarding all of 2.2.8 the above.
The Contractor shall have a solution that allows each RBPS to check transactions 2.2.9 marked as “Vehicle liable to toll, no LP visible” or “object not liable to toll”.
2.2.10 The ANPR software should have a minimum Recognition Rate of 98 %.
The use of reporting functionality shall not influence the performance of the solution 2.2.11 with respect to identifying transactions.
The ANPR solution shall be scalable such that it can be quickly and flexibly 2.2.12 expanded/reduced as needed to accommodate variations in transactions.
2.2.13 The error rate on False Positives should be equal to or less than 0.015 %.
2.2.14 The error rate on False Negatives should be equal or less than 0.01 %.
2.2.15 Transactions that ANPR fail to identify shall be described and reported upon.
Customer Page 17 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
MIR MODULE REQUIREMENTS Table 4: Requirements specific for the MIR module.
ID Description
2.3.1 The MIR Module should be web based.
2.3.2 The MIR Module should be compatible with the Google Chrome web browser.
The MIR Module should be compatible with the following web browsers:
2.3.3 Safari, Mozilla Firefox and Opera.
2.3.4 The MIR Module shall have HTTPS encryption.
2.3.5 The MIR Module should have role based security access.
The MIR Module shall be multi-tenant, with one tenant for each of the 5 RBPS. 2.3.6 Each RBPS shall only have access to their own data.
It shall be possible to handle transactions from different Toll Projects separately, which can be filtered by the Operator Code in the Transaction ID from each 2.3.7 request, as described in Appendix 1 Annex 4.
The MIR Module shall have parameter tables for Operator Codes, and it shall be 2.3.8 possible for each RBPS to maintain their own codes.
The MIR Module shall have an administrator functionality where an administrator is able to add new users, enable/disable users, add/remove roles to users and 2.3.9 assign Toll Projects to the users.
There should be multiple image queues, in order to handle the manual images in the most efficient way (e.g. normal images, conflicts, rare countries). Access to one or several of the queues should be role based. The Contractor shall describe their MIR Module solution and how their solution supports an efficient 2.3.10 way of handling manual images.
2.3.11 The images shown in the MIR Module should be optimized for an efficient manual handling, e.g. automatic gamma correction. It should also be possible
Customer Page 18 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
for a user to add effects manually (e.g. zoom, gamma, contrast, brightness and negative) to the picture.
The MIR Module shall have short keys for all manual operations (e.g. go to next 2.3.12 transaction, setting different Deletion Codes and Country Codes).
The MIR Module should have parameter tables for Deletion Codes, and it should 2.3.13 be possible for each RBPS to maintain their own codes.
The MIR Module should have parameter tables for Country Codes, and it should be possible for each RBPS to maintain which countries they want to enable in 2.3.14 the solution.
2.3.15 It shall be possible for multiple users to work at the same time.
There shall be no noticeable delay when committing data and fetching new images on the web-based solution. The Contractor shall describe how this is 2.3.16 achieved.
There shall be an API for exporting all raw data. In addition, there shall be standard reports containing at least:
• Number of processed images by each user per day/week/month/year/Project/Toll Plaza/Lane for the different image handler queues.
• Number of images deleted by Deletion Codes for each user per day/week/month/year/Project/Toll Plaza/Lane.
• Number of Images in queue to be processed, broken down on 2.3.17 day/week/month/year/Project.
The Contractor shall describe its standard interface to the image database and 2.3.18 procedures for setting up the MIR module within the Customer’s Infrastructure.
Customer Page 19 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SINGLE POINT OF CONTACT (SERVICE DESK)
The Contractor must have first-line support covering the scope of this Agreement. This means that all inquiries and errors about the solution must be reported in a user support system.
Table 5: Single Point of Contact requirements.
ID Description
The contractor shall describe how the Single Point of Contact will be established 2.4.1 and managed.
2.4.2 Single Point of Contact shall be staffed by competent personnel.
Only Customer System Administrators or Super Users (RBPS) may report errors 2.4.3 to the Contractor’s Service Desk.
The total number of users that will contact the SPOC will likely be below 12. The SPOC should be scalable and adapt to increase or decrease in the number of 2.4.4 users.
USER ADMINISTRATION AND IDENTITY ACCESS MANAGEMENT
User management cover all aspects of users, this includes users which are used by APIs, services, servers and databases etc.
User management must handle and fulfil requirements in a safe way:
• Confidentiality: The information is protected against unwanted access. Only authorized users with legitimate needs have access to the information through the operating platform
• Integrity: Measures have been taken to ensure the accuracy of information and traceability mechanisms in order to help detect unjustified changes.
• Availability: Information is available for authorized users according to the image database uptime requirements.
Customer Page 20 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Table 6: Requirements to user administration and identity access management.
ID Description
2.5.1 It shall be possible to define authenticated users, both domestic and from abroad.
2.5.2 It shall be possible to set access control levels and distinguish between users with read only access and those that can edit content
2.5.3 User rights administration shall be role based, allowing the adding or removal of users from specific role groups
2.5.4 There shall be no limit to the number of authenticated users that can be created
2.5.5 All security breach and unauthorized access shall be logged
2.5.6 The Contractor shall describe the standard service for identity access management (IAM) that will be used to control, manage and define access for the Contractors individuals, servers, databases, and data.
2.5.7 The Contractor shall describe his user and access control for its own personnel against the service to be delivered; Including authentication, authorization, password policy, log routines, etc.
2.5.8 The Contractor shall have a system for creating, updating, disabling and enabling user accounts, removing access from employees who leave and reset forgotten, lost or stolen usernames and passwords.
2.5.9 Every user shall have a distinct account. This applies to the Contractors applications, servers, databases, API etc.
2.5.10 The Contractor is responsible for operating and managing IAM. The Contractor shall describe how this is done
Customer Page 21 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SECURITY Table 7: Security requirements.
ID Security
2.6.1 Risk and vulnerability of the solution shall be assessed for all changes.
2.6.2 The contractor shall describe how information security of the solution complies with industry standards such as: ISO/IEC 27001, ISO/IEC 27002 and ISO/IEC 27005.
The Contractor shall describe the design of the service with its security 2.6.3 mechanisms and describe how the Customer’s platform and image database shall be protected.
2.6.4 The solution should not change the contents of the files or messages received.
The Customer shall approve all changes to the Contractor security architecture in 2.6.5 writing before any changes are implemented.
In addition to logging of user activity, authorized and unauthorized access attempts, as well as information security events, according to GDPR, the Contractor shall 2.6.6 control and log all access to personal information.
2.6.7 Access to the solution shall support and use the https encryption protocol.
System messages shall be generated and sent as alarms if any part of the service 2.6.8 is unavailable.
2.6.9 All security breach and unauthorized access shall be logged.
2.6.10 Necessary software updates shall not result in data loss.
2.6.11 The solution shall be protected from attack by viruses and other malicious software.
2.6.12 Security penetration testing shall be performed on the solution by the Contractor.
Customer Page 22 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
DOCUMENTATION
Customer’s documentation requirements beyond the minimum requirements in the Agreement:
Table 8: Documentation requirements.
ID Documentation
The Contractor shall develop a complete documentation and security documentation in English, while test plans, test scripts, documentation of test results, role descriptions, operational documentation and process documentation, 2.7.1 may be in Norwegian.
The Contractor shall in a separate deliverable within the establishment project document safety/security elements and recommended actions to mitigate security risks. This shall be done in different dimensions; for example, (non-exhaustive) 2.7.2 from a user perspective, in operation, in connection with master data etc.
The Contractor’s standard procedures and descriptions of how error situations shall be handled, shall be described and must set for different types of groupings of 2.7.3 fault/error sources.
AUDIT AND QUALITY ASSURANCE
Table 9: Audit and quality assurance requirements.
ID Audit and Quality Assurance
The Contractor shall describe its quality system and quality assurance methods, including procedures, templates, standards, reports and tools for project implementation, and describe how this shall be implemented in connection with the Deliverables. The description should also include the frequency and how quality assurance shall be a part of the delivery. ISAE3402-II and ISO27001 audits may be conducted and the Contractor should know these standards and 2.8.1 prepare for participation in them.
The Contractor shall describe its system for compliance with ISO 27001 and ISO 9001. ISO 27001 deals with information security while ISO 9001 deals with quality of the product/service. Nevertheless, there are many requirements and 2.8.2 procedures common between the two standards, for example:
Customer Page 23 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
• Define goals and track that they have been achieved • Document management • Management review • Conducting internal audits • Taking corrective actions • Control of non-conformance • Continuous improvement
2.8.3 The Contractor shall describe the need for separate GDPR audits.
OPTIONS
Category Identified possible new functionality
Service – TC Possibility to integrate other Toll Collectors (e.g. Svinesund) to the service.
Purpose - New political demands, wishes and Any change due to political reason. needs
New/changed relevant legislation Any change due to legislative reason.
Customer Page 24 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SPECIFICATION OF NON-FUNCTIONAL REQUIREMENTS
PERFORMANCE LEVEL AND SIZING
Key metrics for sizing of standard software and technical platform.
The operating platform shall have capacity to handle the following estimated volumes for the Service:
Table 10: Estimated transaction and image metrics for the Service.
Metric Estimated volume (2019)
No of transactions with attached images per year 250 000 000
No of transactions with attached images per hour (peak) 150 000
Avg image size 0.4 – 1 MB
Avg time from ANPR identification request to response 1 – 5 seconds
Table 10 above shows the estimated transaction and image metrics. On average, there is 1.8 images for every transaction with attached images.
For the MIR module, it could be approximately 10-50 users working simultaneously across the different RBPS.
AVAILABILITY AND PERFORMANCE Table 11: Availability and performance requirements.
ID Description
The Contractor shall describe hardware capacities requirements (sizing) for 3.2.1 test, training and future production environment.
The Contractor shall describe how the Service is optimised for the Customer 3.2.2 during the contract period.
Customer Page 25 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
The Contractor shall describe how performance is handled in the Service, and 3.2.3 how performance can be monitored and reported on when in regular operation.
The contractor shall carry out performance testing of the Service, and describe 3.2.4 how this is done together with report concluding the results.
3.2.5 The contractor shall carry out stress testing (load) of the Service.
The Contractor shall describe the data volumes the Service shall manage based on the customer's descriptions of current and expected volumes. The requirement shall be seen in a lifecycle perspective. The contractor shall 3.2.6 describe how requirements can be met as volumes increase.
BASIC INFRASTRUCTURE AND MONITORING
Table 12: Basic infrastructure requirements.
ID Description
The contractor shall define the need for monitoring of the Service deployed on the operational platform. This work shall begin as part of detailed design and shall be tested as for all other functionality. Monitoring shall, as a minimum be done on processes, services, interfaces and cover measurements of resources, response times and availability. Monitoring shall cover both active and inactive 3.3.1 use of the application and resources.
The system documentation shall clearly define the processes, resources and services which shall be monitored. It shall also state if the Service or process can and shall be automatically restarted, or any other necessary steps before a 3.3.2 restart is performed.
The system documentation shall clearly define the processes, resources and 3.3.3 services included in the Service.
Customer Page 26 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
TEST AND DEVELOPMENT - ENVIRONMENT, TOOLS AND METHODOLOGY
Table 13: Test and development requirements.
ID Description For proposed amendments based on the Customer’s business processes, the 3.4.1 Contractor shall base these on reference models and software standard process models. The Contractor shall describe the used models. The Contractor shall describe how the different items in the Service shall be documented and integrated. The description shall at least include (this list is not exhaustive) • Document types • Document templates • Placement in solution and project management tools • Procedures and guidelines for use • Roles and permissions 3.4.2 • Standards; templates, naming etc • Structure
Customer Page 27 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
SPECIFICATION OF MIR SERVICE
The focus of the procurement is the following:
• Stable and efficient service • Flexible and scalable service • Data control and information security • Features that continuously improve MIR identification rates.
GENERAL REQUIREMENTS
The images will contain data that is protected by the Personal Data Act and that can be misused. There is a need for processes that ensure security and privacy.
Table 14: General requirements for the MIR service.
ID Description
The MIR service shall be based on the new ANPR solution and interface included 4.1.1. in ANPR service.
4.1.2 The MIR service Contractor shall optimalize the service.
The Contractor should in the establishment phase develop a image processing instruction (together with ANPR contractor). These instructions shall always be followed by the Contractor's image processors (operators). Changes in instructions or working methods shall be communicated in writing to the Contractor's contact person immediately when such changes occur. The contact person is responsible for ensuring that translated instructions are kept up-to-date and the image processors are informed of changes. Instructions for image processing will be delivered by the ANPR service provider.
Today’s ANPR system solution will be changed and a new ANPR system solution will be implemented. Requirements for this is described in section 1-3.
Upon confirmation of this requirement point, the Contractor has confirmed that the content of the instruction has been reviewed, will be followed and will be 4.1.3 updated according to new system solution.
The Contractor shall at the end of each week receive a report containing an overview of the week's image processing and non-conpliance, delays and quality 4.1.4 problems.
Customer Page 28 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
The Contractor shall at the end of each month receive a report containing an overview of the month's image processing and non-conpliance, delays and 4.1.5 quality problems.
The Contractor shall use data similar to today’s "report 112" as the invoice basis for work performed. The report shall show the number of processed images per image processor on the different image processing services. Refer to Annex 8 4.1.6 for an example report.
COMPETENCE AND LANGUAGE Table 14: Competence and language requirements for the MIR service.
ID Description
Documents are made in English or Norwegian. English or Norwegian will also be used in the implementation of the contract. The Contractor is responsible for 4.2.1 translating instructions etc.
The Contractor's image processors shall be able to distinguish between Norwegian and non-Norwegian number plate types. In addition, knowledge of different Norwegian and non-Norwegian number plate types is required; old and 4.2.2 new, military signs, test signs, import signs mm
The MIR service shall be able to process all Norwegian and non-Norwegian 4.2.3 number plates manually.
USER ADMINISTRATION Table 15: User administration requirements for the MIR service.
ID Description
The Contractor shall make sure that only authorized users with legitimate needs 4.3.1 are given access to the operating platform, i.e. the MIR module.
Customer Page 29 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
QUALITY REQUIREMENTS Table 16: Quality requirements for the MIR module.
ID Description
The MIR should be a maximum of 5 working days in delay (queue) compared to the passage date. The Customer shall get access to a report showing pictures 4.4.1 in queue per day.
4.4.2 Images sent for re-processing should be handled within 5 working days.
The Contractor shall ensure that images that lead to invoicing are correctly 4.4.3 registered with the correct letters, numbers and country.
4.4.4 The error rate on False Negatives should be equal or less than 0.01 %.
4.4.5 The error rate on False Positives should be equal to or less than 0.015 %.
The Contractor shall develop a training plan. The training plan shall be delivered 4.4.6 during the Establishment phase.
The contractor should ensure that images with LPs from the countries mentioned 4.4.7 in Appendix 1 Annex 7 are identified correctly.
ANPR AND MIR SERVICES SPECIFICATION OF OTHER REQUIREMENTS
GENERAL PROVISIONS ON EXTERNAL LEGAL REQUIREMENTS AND MEASURES
Legal or party-specific requirements that are relevant to the execution and performance of the Agreement. The Supplier shall conform to the following rules and regulations in the latest updated version:
Customer Page 30 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
Table 17: Legal requirements.
ID Description
The Personal Data Act. 5.1.1 https://lovdata.no/dokument/NL/lov/2016-06-17-73?q=offentlige
Regulations on the processing of personal data (Personal data regulations). 5.1.2 http://lovdata.no/dokument/SF/forskrift/2000-12-15-1265
PERSONAL DATA Table 18: Customer’s requirements to the processing of personal data.
ID Description
The Supplier shall sign a Data processor agreement with the Customer (SSA-L 5.2.1 Appendix 11).
Data protection by design and by default
5.2.2 The Supplier shall describe how the requirements regarding data protection by design and by default set down in the GDPR article 25 are accounted for through the ANPR solution and MIR module.
Handling of incidents and data breaches
5.2.3 The Supplier shall implement and operate an incident response plan, in order to comply with the requirements on assistance to the Customer set down in the Data processor agreement.
ELECTRONIC COMMUNICATION AND PROCESSING REQUIREMENTS BETWEEN THE CUSTOMER AND THE SUPPLIER Table 19: Electronic communication or processing requirements.
ID Description
All communication containing confidential information shall be executed through encrypted channels, and with strong authentication.
5.3.1 Confidential information includes:
Customer Page 31 of 32
Sign. Customer Sign. Contractor ANPR and MIR service procurement - SSA-L Appendix 1
• Information included in statutory and contractual confidentiality: o Sensitive personal Information from the Personal Data Act o Confidentiality Clauses; information of a sensitive nature where unauthorized access to the information can cause significant damage to individuals, the Customer, the contract party or their interests
The Supplier shall not download, distribute or use information obtained from the 5.3.2 Customer, without explicit consent from the Customer in each individual case.
LIST OF ANNEXES TO APPENDIX 1 Table 20: Annexes to Appendix 1.
Annexes Attached
Annex 1 - Customer’s Technical Platform X
Annex 2 – Systor Platform Documentation
Annex 3 - Definitions and Abbreviations X
Annex 4 - AutoPASS Identification Module X
Annex 5 - AutoPASS ImageDB RESTAPI X
Annex 6 - Image Database X
Annex 7 – Countries to be Handled by ANPR service X
Annex 8 – MIR Service Example Report
Customer Page 32 of 32
Sign. Customer Sign. Contractor