MESTAcontrol Red Light and Speed Violation Processing System
Solution description
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR. Version 1-00 2019-11-11
Reproduction and Disclosure Prohibited
About IDEMIA
IDEMIA is the name of the group that combines the two great companies – Oberthur Technologies and Safran Identity & Security – that have joined forces to form the new leader in trusted identities for an increasingly digital world. IDEMIA places the client, consumer or citizen at the heart of everything it does, combining security, convenience, the human factor and continuity within a single proposition. This capability for integration is what we call the “magic combination”. In a world which has gone “phygital”, IDEMIA conceives security in a global way, upstream of technological developments, by factoring in the customer’s environment and how they specifically use technology. In a world of ever-increasing exchanges, security primarily means protecting identities. This is why IDEMIA places Augmented Identity at the heart of its actions. Our world is constantly changing due to the advent of big and small data, large-scale economic upheaval caused by the digitalization of transactions, and new security risks to deal with. In the face of these challenges, we have assumed a position of leadership. Indeed, IDEMIA was born out of the coming together of two unique and perfectly complementary DNAs. It is the result of our talents, of the women and men who anticipate, think, design, develop, protect and market our security solutions of today and tomorrow: 13,000 employees working for a safer world. Identify and protect, contribute to progress in our society, provide every individual with a recognizable and secure identity. Create trust at every level: a country, a firm, an IT system or just a smartphone. These are our commitments at IDEMIA. * * *
We promise to create secure environments using traffic law enforcement systems that ensure safer roads.
Expanding cities and rising individual mobility have greatly affected traffic conditions. Maintaining security on roads is a top priority and a financial challenge for governments. According to the World Health Organization, traffic accidents cost nearly 3% of GDP and by 2030, road-related accidents are forecasted to be the 5th leading cause of death. IDEMIA provides sophisticated traffic law enforcement systems that prevent reckless driving and significantly reduce road accidents. We have the latest technologies needed for advanced behavior monitoring. What’s more, our solutions operate perfectly well in all conditions.
For more information, visit www.idemia.com / Follow @IdemiaGroup on Twitter
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR About IDEMIA Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 2/63
Reproduction and Disclosure Prohibited
About this Document
Proprietary Rights The information in this document is IDEMIA Identity & Security France (IDEMIA) Information and is Confidential. It is the property of IDEMIA and shall not be used, disclosed to others, or reproduced without the express written consent of IDEMIA.
Export Control Clause The information contained in this document may be subject to export control laws and regulations. As a consequence, the client shall comply with all applicable laws and regulations, including export laws and regulations of the United States. This means, in particular, that the client will not, without the prior authorization of the appropriate governmental authority, in any form export or re-export, through direct or indirect means, any item or technical data or direct or indirect products sold or otherwise furnished.
Trademarks All trademarks acknowledged.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR About this Document Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 3/63
Reproduction and Disclosure Prohibited
Contents of this Document
Table of Contents About IDEMIA 2 About this Document 3 Contents of this Document 4 Abbreviations 8
1 / Solution description 11 1.1 > General presentation of MESTAcontrol 11 1.2 > MESTAcontrol module details 11 Violation processing 13 Equipment statistics 24 Dashboard 24 Message collection 25 Equipment monitoring 25 Equipment administration 27 Control centre settings 27 Localisation 27 1.3 > MESTAcontrol open architecture 28 Third party equipment integration 28 Third party database integration 32 MESTAcontrol API 32 Violation export 33 1.4 > Scalable and redundant architecture 33 Logical architecture 33 Technical frameworks 34 Operations and monitoring 35 Backup and restore 36 1.5 > MESTAcontrol security 36 Users and rights management 36 Auditing and traceability 38 Security by design 38
2 / Unified platform for violation processing offer 39 2.1 > Technical offer 39 Deliverables 39 Requirements and assumptions 39
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Contents of this Document Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 4/63
Reproduction and Disclosure Prohibited
2.2 > Services 40 Training 40 Professional services 40 Support and maintenance 41 2.3 > Project 43 IDEMIA references 43 Project organization 44 Quality Management 51 Risk Management 57 Project plan 60
3 / Compliance matrix 61
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Contents of this Document Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 5/63
Reproduction and Disclosure Prohibited
List of Figures Figure 1 MESTAcontrol functional overview 11 Figure 6 Preset violation lifecycle 14 Figure 7 MESTAcontrol workspace 15 Figure 8 Violation evidences editing tools 16 Figure 9 Picture edition to hide part of a picture 16 Figure 10 Plate number validation and violation status update interface 17 Figure 11 PDF export 20 Figure 12 PDF output of a violation 20 Figure 13 KPI and statistics (i.e. equipment efficiency) 21 Figure 14 KPI and statistics (i.e. User efficiency) 22 Figure 15 Operational equipment efficiency 22 Figure 16 Export into *.csv format 23 Figure 17 Generated table in CSV format 23 Figure 18 Traffic insight per equipment 24 Figure 19 Dashboard overview 25 Figure 20 Equipment monitoring dashboard overview 26 Figure 21 Equipment configuration details 27 Figure 22 MESTAcontrol customised in Arabic 28 Figure 2 MESTAcontrol supports traffic enforcement units from third party vendors 29 Figure 3 Scalable architecture 34 Figure 4 IDEMIA service monitoring example 35 Figure 5 IDEMIA service monitoring example 36 Figure 23 New User form 37 Figure 24 First connection or reset password 37 Figure 25 Reset password 38 Figure 26. IDEMIA’s QSCR missions 51 Figure 27. Quality Information Structure 52
List of Tables Table 2. MESTAcontrol modules 12 Table 1 MESTAcontrol generic loader file format 31 Table 3 Example of Bill Of Material - Dell Servers (to be checked for equivalence) 39
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Contents of this Document Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 6/63
Reproduction and Disclosure Prohibited
Table 4. Classification of incidents 41 Table 5. Definitions 42 Table 6. Maintenance Timing 42 Table 7. Overview of Unified platform Project Risks 59
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Contents of this Document Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 7/63
Reproduction and Disclosure Prohibited
Abbreviations
Term Definition AD Active directory ANPR Automatic number plate reading API Application program interface BOM Bill of material CCTV Closed-circuit TV COTS Component off the shelf CSV Comma separated value DB Database DMZ Demilitarized zone GB Gigabyte HTTP Hypertext transfer protocol JSON JavaScript object notation KPI Key performance indicator MB Megabyte OCR Optical character reading OS Operating system P2P Point-to-point PDF Portable document format PHP PHP: hypertext pre-processor RAID Redundant array of independent disks RBAC Role based access control REST Representational state transfer SADD Software architecture definition document SAML Security assertion markup language SLA Service level agreement SODD System overview design document SW Software TCP Transport control protocol
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Abbreviations Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 8/63
Reproduction and Disclosure Prohibited
TLS Transport layer security VM Virtual machine
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Abbreviations Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 9/63
Reproduction and Disclosure Prohibited
Page intentionally blank.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Abbreviations Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 10/63
Reproduction and Disclosure Prohibited
1 / Solution description
1.1 > General presentation of MESTAcontrol MESTAcontrol is a complete software suite dedicated to road safety-related use cases. When dealing with road safety, authorities have little or no interaction between the different applications used to manage law enforcement, traffic management and security on the roads.
Figure 1 MESTAcontrol functional overview
MESTAcontrol offers the ability to address all these use cases through a complete set of functions. On a common platform, MESTAcontrol manages roadside units including CCTV cameras, but also ANPR cameras, for average speed violation detection or public security applications. Each use case is bundled in separate packages and thus can be activated depending on the objectives to fulfil. This document describes the Speed and Red Light systems use case.
1.2 > MESTAcontrol module details MESTAcontrol is a unique platform that operates many different modules in the same interface. MESTAcontrol comes in various configurations, depending on the use case. The following three different use cases are covered: Point to Point systems; Public security; Violation processing.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 11/63
Reproduction and Disclosure Prohibited
For each use case, application modules are either included, optional or not applicable (N/A), as shown in Table 1.
Table 1. MESTAcontrol modules
Application Description Point to Point Public Speed & Red module Systems Security Light Systems Dashboard Charts on violations and equipment Included Included Included data Message Receive and decrypt messages from Included Included Included collection deployed equipments Violation Violation browser, proof of violation Optional N/A Included processing management, validation of violations and associated statistics Equipment Enroll new equipments into solution Included Included Included administration and associated settings management Control center MESTAcontrol administration and user Included Included Included settings management Intelligent plate Plate number search, hotlist… N/A Included N/A analysis Average speed P2P sections management, data Included N/A N/A processing for average speed calculation and average speed violation proof generation Equipment Proposes traffic statistics issued by Optional Optional Included statistics data from equipments Equipment Live status of deployed equipment and Optional Optional Included monitoring technical statistics for maintenance
This document focuses on a Speed and Red Light systems use case. Please refer to alternate dedicated technical descriptions for Public Security and Point to Point use cases.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 12/63
Reproduction and Disclosure Prohibited
The Speed and Red Light systems use case is based on the following modules: Violation processing – optional; Equipment statistics – optional; Equipment monitoring – optional; Dashboard; Message collection; Equipment administration; Control centre settings. The next sections detail the modules included in Speed and Red Light systems.
Violation processing The Violation Processing module allows mainly to: Manually import violations; Search for violations; Qualify and filter violations;
Edit violation evidences; Perform statistics and analysis; See violation history.
1.2.1.1 > Violation lifecycle management Commented [HV1]: Review, for generic offer Operators need to take several actions to check evidence quality before forwarding the violations to a ticketing system. MESTAcontrol provides a preset lifecycle where operators can make decisions based on pictures, videos and metadata. Any newly received violations will have a ‘NEW’ status. At that stage, an operator can use the browsing and editing tools of MESTAcontrol to check if the violation is well documented and to check that the plate number is right and to correct it in case of OCR error. Should the evidence and plate number be good, the violation moves to ‘ACCEPTED’ status. At that stage, MESTAcontrol may query an external database for registered vehicle information associated with the given plate number. Should the evidence and registered vehicle information match (brand, colour, model of the vehicle are the same as on the picture) the violation moves to the ‘VALIDATED’ status and is exported to a third party ticketing system.
NOTE: EXTERNAL DATABASE INTEGRATION - This stage may be optional, in which case MESTAcontrol can move the violation to its final status automatically once the operator confirms plate number and evidence quality.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 13/63
Reproduction and Disclosure Prohibited
If an operator triggers an exception, the violation moves to ‘REJECTED’ or ‘INCONSISTENT’ status. A privileged operator or supervisor can then review the violation and decide to move the violation to a ‘CONFIRMED’ rejection or inconsistency status.
Figure 2. Preset violation lifecycle
1.2.1.2 > Violation import MESTAfusion fleet and third party roadside equipment send violations to MESTAcontrol either on the fly or on a regular basis. MESTAcontrol then automatically loads the violations into its database. However, manual import of violations is available. No matter how MESTAcontrol loads violations, the same process applies. MESTAcontrol offers a very simple web page to drag and drop violation files.
1.2.1.3 > Violation search engine MESTAcontrol offers the capability to filter based on various criteria: violation (violation number, type, status, date); equipment (serial number, model, location on a map); Vehicle (plate number, country of origin or vehicle type).
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 14/63
Reproduction and Disclosure Prohibited
Figure 3 MESTAcontrol workspace Commented [GE2]: Image Qatar a changer
1.2.1.4 > Workload management and violation assignment When working with a large number of roadside units or violations, it may be necessary to have a means to organise work among various teams of operators. MESTAcontrol offers different solutions to meet this requirement. Operators can work on a distinct set of violations using the advanced search feature of MESTAcontrol. Every combination of search criteria is available, either radar based, violation status based or time based. More than that, a privileged operator or supervisor can tag violations meeting a given set of search criteria. This tagging feature gives a very simple way for operators to find violations based on tags to which they were assigned. Alternatively, an operator can tag a specific violation should it need to be reviewed by another operator or supervisor. Tagging a violation does not affect the violation lifecycle.
1.2.1.5 > Violation editing Once the violation to be processed has been selected, the user has access to all proofs of violation, for example: context pictures, cropped pictures, video clips. From this data the user can then extract relevant aspects (i.e. plate number). If needed, pictures can be zoomed in to a specific zone and an image can be adapted to ease reading of the number plate. To help improve effectiveness with image correction, some filters can be saved and be applied easily.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 15/63
Reproduction and Disclosure Prohibited
Figure 4 Violation evidences editing tools
Picture enhancement tools
Save this adjustment preset
Picture crop
Record of changes
Operators also have the capability to hide part of an image (face, another plate, etc.) using the ‘Edit’ feature. The user can select fill and line colours and the form (rectangle or polygon) of the shape to draw on the picture.
Figure 5 Picture edition to hide part of a picture
Edit
Apart from brightness, contrast and image sharpness in connection with the plate number, the user can include additional information related to violations such as:
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 16/63
Reproduction and Disclosure Prohibited
Vehicle data (stolen car, unauthorised car, etc.); Driver data (name, address, etc.); Any relevant comment.
1.2.1.6 > Violation validation or rejection Once sufficient proof is in place, the violation status can be loaded into the system.
Figure 6 Plate number validation and violation status update interface
Field for plate number manual correction
Violation status update
Whenever a violation is rejected on the first revision, it has to be for a specific reason, defined previously in the settings. This could be, for example, an exemption for an ambulance or for a police car. It can also be because the plate can’t be read. If the Operator decides to reject a violation, he will select the associated cause from a pre- defined list.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 17/63
Reproduction and Disclosure Prohibited
Figure 6 Rejection cause
A user with the appropriate rights, can modify the rejection causes list. Then, when rejecting a violation, the operator can pick a rejection cause from the list.
Figure 6 Rejection cause management
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 18/63
Reproduction and Disclosure Prohibited
1.2.1.7 > Violation history For each violation, you can see who and when the state in the lifecycle of the violation changed.
Figure 6 Violation change history
1.2.1.8 > Logbook Logbook is used to see all status/lifecycle changes within the violations part of the system Logbook offers a way to filter and focus on specific violations.
Figure 7 Logbook filtered on an User
1.2.1.9 > Generate and print report With MESTAcontrol, operators and supervisors can effortlessly generate reports, in PDF format, on statistics and violations, using a dedicated button on the graphic interface.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 19/63
Reproduction and Disclosure Prohibited
Figure 7 PDF export
The PDF includes details of the violation and a comment section. PDF layout and graphics can be tailored to specific needs.
Figure 8 PDF output of a violation Commented [GE3]: PDF d’infraction Qatar a changer
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 20/63
Reproduction and Disclosure Prohibited
1.2.1.10 > Operational Statistics To analyse the overall violation management process, this module offers statistics to analyse: Quantity of violations received: number of violations generated by all units (with violation type info); Equipment efficiency: number of violations generated per equipment (with violation type info); Conversion rate: Validated violation rate; Rejection details: Ratio of causes for the rejected violations; User efficiency: Violation change state done by each User on a selected period.
Figure 9 KPI and statistics (i.e. equipment efficiency)
Date covered by statistics
Number of violations in the period
Equipment
Simply select an area to zoom in
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 21/63
Reproduction and Disclosure Prohibited
Figure 10 KPI and statistics (i.e. User efficiency)
Figure 11 Operational equipment efficiency
1.2.1.11 > Data report MESTAcontrol offers, to supervisors and operators with sufficient permissions, two ways to make reports: 1. Directly from the advance search feature. After setting its criteria, such as time period and violation type, the operator can export a .CSV file containing information about all the violations resulting from its
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 22/63
Reproduction and Disclosure Prohibited
search. This CSV file can then be imported easily into spreadsheet software such as Microsoft Excel, where advanced graphs and analytics can be done.
Figure 12 Export into *.csv format Commented [GE4]: MIF Qatar dans la recherche
Generated CSV
Figure 13 Generated table in CSV format Commented [GE5]: Equipements ESHHAR
2. Accessible from the Operational Statistics feature; from here, the operator can export graphs to a PDF format, after selecting the time period he wants statistics from.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 23/63
Reproduction and Disclosure Prohibited
Equipment statistics The MESTAcontrol equipment statistics module facilitates the following interactive charts for all kinds of operational data for each installed MESTAfusion: Number of vehicles detected; Classification of vehicles detected; Lane of vehicles detected; Number of violation messages per type of vehicle.
Figure 14 Traffic insight per equipment
Breakdown per vehicle class
Breakdown per lane
Hourly traffic
Dashboard MESTAcontrol dashboard module provides: Easy-to-read, real-time user interface; Graphical presentation status of the system; Widget display for key performance indicators;
Quick access to selected pages. A variety of widgets are available and can be added to the dashboard effortlessly. The page can be updated automatically and displayed on a video wall. The video wall solution would be provided by a third party vendor.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 24/63
Reproduction and Disclosure Prohibited
Figure 15 Dashboard overview
Disk space
Violations to be processed
Map view
Message collection The message collection module allows interconnection between devices and MESTAcontrol. It mainly ensures secure collection and deciphering of violation data.
ABOUT DECIPHERING: - MESTAcontrol supports MESTAfusion ciphered violation packages. - Refer to the data encryption section of the MESTAfusion description for further technical details.
Equipment monitoring MESTAfusion integrates embedded software that is able to detect any major failure of the main hardware component and transmits alarms if a problem is detected. The use of the open source software Nagios and NRPE, integrated into MESTAcontrol, allows a MESTAfusion fleet to connect easily and interact with a central monitoring unit. For example, the following components are monitored: Autotest; Battery status; Connection with central server; Compact flash access;
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 25/63
Reproduction and Disclosure Prohibited
Connection with digital camera; Connection with Doppler; Physical intrusion into the system; Hard disk space utilisation; Health of software and hardware components; Temperatures. For each equipment part, an instant overall coloured status is displayed close to the identifier, in order for the user to identify potential problems quickly. The MESTAcontrol equipment monitoring module allows: Advanced monitoring of field devices; Alarm notification (GUI); Geographical/map device monitoring status.
ABOUT THIRD PARTY EQUIPMENT: - Roadside equipment other than MESTAfusion may not be compatible out of the box with the monitoring system, or have any kind of remote monitoring at all. - MESTAcontrol can still check if a connected equipment sent violations recently, and trigger an alarm if the equipment didn’t send any violation for the past 24 hours, reporting a potential issue.
Figure 16 Equipment monitoring dashboard overview
Active equipment
Probe live status
Map view
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 26/63
Reproduction and Disclosure Prohibited
Equipment administration The MESTAcontrol device administration module allows the creation and modification of roadside units. Other speed, red Light and ANPR systems can be linked to the device database, if their infraction format is compatible.
Figure 17 Equipment configuration details Commented [GE6]: Equipment Eshhar
Equipment enrolment
Equipment settings
Equipment configuration
Equipment list
Control centre settings MESTAcontrol settings module allows: User and profile management Create user profile with specific rights and create/manage users (see ‘User and Rights management’ section for detailed info). Manage Rejection Causes Create new rejection causes, allowing a better comprehension of why a violation has been rejected, thereby, generating more precise reports (see ‘Violation editing’ section for detailed info).
Localisation MESTAcontrol interface is available in several languages: Arabic, French, English.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 27/63
Reproduction and Disclosure Prohibited
MESTAcontrol can be extended with new localisations (subject to additional services). The workspace and user interface layout changes when switching languages from left-to-right to right-to-left reading.
Figure 18 MESTAcontrol customised in Arabic Commented [GE7]: MIF eshhar
1.3 > MESTAcontrol open architecture MESTAcontrol connects with multiple equipment brands and models and integrates various formats and metadata structures. Supporting a new model or data format requires the description of the violation package files and structure for IDEMIA to add the appropriate loader module. Alternatively, MESTAcontrol supports any third party integration with a low coupling mechanism. In addition, the software architecture allows connection of external third party data providers to improve the process’s efficiency or extend the process’s scope beyond violation processing.
Third party equipment integration Adding third party equipment requires the use of a loader module that periodically crawls a reception server directory and downloads violation packages. The loader module parses the violation package, extracts media files (pictures and video evidence of the infringement) and import metadata (description of the violation captured by the equipment) to the database. Upon package processing, the loader can transcode media files to a MESTAcontrol- compatible media format and run OCR algorithms to read vehicle plate numbers. Supported media formats are: Video formats: MPEG4, H264;
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 28/63
Reproduction and Disclosure Prohibited
Video containers: MP4, WEBM; Pictures: JPEG.
ABOUT THE OCR - The OCR algorithm runs against the cropped image of the infraction if the roadside unit generates it. - Should there be no cropped picture, the OCR algorithm runs against the first violation picture.
- Should there be more than one plate in the picture, the OCR result will be empty so as not to generate a false identification. - Should a plate be damaged, hardly visible, partially masked or shadowed, the OCR output may be null. - Plate pan angle influences OCR efficiency. Higher pan angles may result in lower reading efficiency.
NOTE ON MULTIPLE OCR INTEGRATION: - MESTAcontrol can use two OCR algorithms to improve reading results. - When outputs are inconsistent, MESTAcontrol does not automatically fill in the plate number.
Figure 19 MESTAcontrol supports traffic enforcement units from third party vendors
MESTAcontrol ships with a generic loader that imports any violation package that conforms to IDEMIA standard violation format. Third party vendors can thus process and transcode their proprietary format on the reception server and copy the files to the IMPORT directory that the generic loader crawls. MESTAcontrol requires a minimum set of data to be able to process a violation:
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 29/63
Reproduction and Disclosure Prohibited
a picture showing the offending vehicle; timestamp of the violation; the roadside unit identifier (e.g. a serial number); Unique Identifier of the violation associated to the radar; Vehicle class, vehicle speed and lane identifier; Violation details describing the violation: o Violation type (speed, red light, speed on red, forbidden trajectory, etc., o Speed: legal speed, sanction speed, etc., o Red light: red time, amber time, etc.; Location information (mandatory for a mobile unit). The following third party equipment brands were tested and meet these minimum requirements: Redflex; Sensys Gatso.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 30/63
Reproduction and Disclosure Prohibited
Table 2 MESTAcontrol generic loader file format
IDEMIA standard violation format example
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 31/63
Reproduction and Disclosure Prohibited
NOTE: CIPHER AND SIGNATURE - Roadside units may generate signed and/or ciphered packages prior to transmission to the backend. The generic loader processes deciphered packages only. - Signatures are imported into MESTAcontrol for traceability and audit purposes. - Deciphering and signature control should be performed while processing the vendor format.
Third party database integration Violation processing aims to qualify the quality of the evidence and minimise ticket disputes. A common good practice is to check the consistency between the offending vehicle’s pictures against the registered information based on the plate number. Should the registered vehicle brand or colour be different to the one of the vehicle in the evidence picture, the violation may be rejected. MESTAcontrol can lookup third party services for this information and display it to the operator for validation purposes. MESTAcontrol sends the plate number information in a JSON encapsulation and expects to receive brand, model and colour of the corresponding vehicle in a JSON encapsulation. External services should be available over REST API or Web Services.
MESTAcontrol API MESTAcontrol is a key building block within a larger business process, hence it provides interfaces to third party system components. Two types of API are available: Read-only API:
º Search and list violations; º Retrieve violation details and attached media (using a violation ID retrieve from the ‘Search and List violation’ API) Write API: Import a violation based on generic violation description xml file; The read-only API is a HTTP REST interface, data is JSON format. The write API is file based so as to offer easily low coupling and high media volume transfers. This endpoint accepts two kinds of files: either a single request with multiple files for a single violation (e.g., a data file and two pictures), or a TAR archive file containing multiple data sets for multiple violations. Note that the import process can take a while; the API will respond with a 200 status code when the file has been completely uploaded to MESTAcontrol, but the response will be sent before the import process starts.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 32/63
Reproduction and Disclosure Prohibited
NOTE: EXTENDED WRITE API - Some system integration patterns may require extended write access to violation data or status. By default, these are not enabled in MESTAfusion since violation integrity is critical.
Violation export Once a violation reaches its final approved status, MESTAcontrol exports evidence files and associated metadata to a third party ticketing system. MESTAcontrol will then send these exported violations to an external endpoint using a file transfer protocol. Export to the third party ticketing system and archive system can use Web Services. Alternatively it may be file based so as to offer easily low coupling and high media volume transfers.
1.4 > Scalable and redundant architecture Several factors influence a violation processing centre activity: Traffic; seasons and weather impact driver behaviour so they are more or less prone to violation generation; number of active roadside equipment; network disruption, etc. Hence, MESTAcontrol must scale up or down to support the varying number of violations to be processed or concurrent operators needed to do so. Moreover, evidence processing requires a guarantee that no data can be lost at any time.
NOTE: SINGLE MACHINE DEPLOYMENT - MESTAcontrol architecture scales up to the most demanding processing volumes. However, small scale deployment can be achieved with a single server configuration. - Single server configurations can manage up to 300,000 violations of up to 20 MBytes each.
Logical architecture MESTAcontrol’s design enables high availability, 24/7 operations, scalability and data integrity with a redundant architecture. Each level of the 3-tier architecture can be horizontally redundant and independently sized: Communication servers centralise all external communications to secure data access; Application servers execute the business processes of violation handling; Database servers store and replicate the metadata and media files.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 33/63
Reproduction and Disclosure Prohibited
For instance, a roadside equipment fleet size change can be handled by changing the number of communication servers. A steep increase in the number of concurrent operators may lead to the addition of application servers. A change in data retention policy or average violation size may lead to the addition of database servers.
Figure 20 Scalable architecture
Each server is either a physical server or a virtual machine.
Technical frameworks In addition to its functional architecture, MESTAcontrol relies on proven technical frameworks and guarantees the absence of single point of failure. Applications run on top of Apache2 web server either in a Java Runtime environment or Laravel/PHP environment. These frameworks are proven enterprise-grade solutions that IDEMIA uses in its most demanding programmes. HAProxy offers load balancing and proxying of TCP and HTTP-based applications. HAProxy supports active/passive setup. A PostgreSql database stores violations metadata. Log shipping techniques enable data replication and service continuity. MESTAcontrol stores media files on Apache Cassandra storage. It is a distributed, wide- column store, NoSQL database management system designed to handle large amounts of data across many commodity servers, providing high availability with no single point of
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 34/63
Reproduction and Disclosure Prohibited
failure. It offers robust support for clusters spanning multiple datacentres, with asynchronous master-less replication, allowing low latency operations. As a consequence, the most demanding SLA can be enforced with MESTAcontrol. All services/applications/databases are deployed in Docker containers. Docker simplifies deployment and scalability by easily adding additional containers in case the systems need more resources (e.g. database size, processing workload, etc.). Docker engine comes with OS Ubuntu v18.04, tuned and customised by IDEMIA to be hardened. MESTAcontrol uses other technical frameworks such as Nagios for MESTAfusion monitoring and Python for services monitoring.
NOTE: HIGH AVAILABILITY AND MULTIPLE DATACENTRES - MESTAcontrol architecture enables deployment across multiple datacentres for the most demanding use cases. But in most business use cases, a single datacentre, single server configuration is satisfactory. - Multiple datacentre deployments require configuration and specific professional services.
Operations and monitoring MESTAcontrol components are deployed across multiple servers and instances. IDEMIA can offer an optional external component to monitor the health status of every component and server.
Figure 21 IDEMIA service monitoring example
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 35/63
Reproduction and Disclosure Prohibited
Figure 22 IDEMIA service monitoring example
Backup and restore On top of the strong, reliable architecture and technical frameworks, MESTAcontrol includes a backup applied on long term data (profiles, users, roadside unit lists and configurations, monitoring history, statistic data history, etc.) stored in a PostgreSQL database. The backup/restore of long term data comes in addition to redundant storage of PostgreSQL database and can be used for disaster recovery plans. Media file backup is unnecessary since Apache Cassandra already provides reliable, redundant storage.
1.5 > MESTAcontrol security
Users and rights management MESTAcontrol uses role based access control (RBAC), meaning that for a specific module or function, several permissions can be set to a profile; for example, a profile can add a profile, and another one cannot. By default, MESTAcontrol comes with a pre-defined set of profiles Admin_User to create users; Operator_L1 to review violations and create/edit equipment; Operator_L2 comes with Operator_L1 rights plus capability to review violations in ‘REJECTED’ or ‘INCONSISTENT’ states. When adding a user, the administrator will select the profile to assign to this new user. When creating a new User, the Admin_User shall define a password valid only for the first connection.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 36/63
Reproduction and Disclosure Prohibited
Figure 23 New User form
Upon first successful connection, the system prompts the user to define their password.
Figure 24 First connection or reset password
Admin_User can reset the password of a User (in case of loss or to force change).
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 37/63
Reproduction and Disclosure Prohibited
Figure 25 Reset password
Auditing and traceability MESTAcontrol offers various means for audit and traceability. Logbook enables high level control of a violation processing history. (See Sections 1.2.1.7 >Violation history and 1.2.1.8 >Logbook). MESTAcontrol generates AT logs (business case oriented logs) and technical logs to be used by third party log analysis solutions. Retention time is configurable.
Security by design MESTAcontrol 3-tier architecture enables the use of security best practices where each tier can be hosted in separate subnetworks and DMZ. Communications between each tier can be controlled by dedicated solutions (proxies, firewalls, etc.). Each inter-component communications use TLS to guarantee confidentiality and integrity of data. Communication flows are limited by the use of tailored iptables rules. Our deployment strategy uses a hardened Linux OS (tuned and configured by IDEMIA) and runs every component on dedicated technical system users with the lowest privileges necessary. As an experienced player in secured environments and sensitive applications, IDEMIA constructs its security policies on solid ground. MESTAcontrol, as a backoffice tool for law enforcement, benefits from IDEMIA’s best practices and experience. MESTAcontrol development is based on IDEMIA’s security guidelines.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Solution description Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 38/63
Reproduction and Disclosure Prohibited
2 / Unified platform for violation processing offer
2.1 > Technical offer
Deliverables IDEMIA will provide the following deliverables within the scope of this project. Documentation: Blablabla Software: Blablablabis
Requirements and assumptions
2.1.2.1 > Assumptions The following hosting requirements are based on the following sizing assumptions: blablabla This technical offer is made under the following assumptions: bliblibli .
2.1.2.2 > Network integration constraints
2.1.2.3 > Hardware hosting constraints
Table 3 Example of Bill Of Material - Dell Servers (to be checked for equivalence)
Item Brand, Detail Specification Part Number Quantity Model Your brand Your server spec Server SKU XX model Your item Your spec your sku XX
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 39/63 offer
Reproduction and Disclosure Prohibited
2.1.2.4 > Software Bill of Material
Item Brand, Detail Specification Licensing Quantity Model Virtualisation Vmware Vcenter v6 Yes 1 VMWARE Virtualisation Vmware Vsphere Enterprise Edition v6 Yes 3 VMWARE
2.2 > Services
TO BE COMPLETED / MODIFIED ACCORDINGLY TO THE OFFER
Training The following training plan is offered with this technical offer. Training session will be in Doha. Local logistics and room bookings is not included.
Training sessions Training content End users training MESTAcontrol Violation Processing Proceed to violation analysis and IDEMIA MESTAfusion monitoring for operators Duration: 1 day Number of sessions: 1 Number of trainees: 10 Administrator training MESTAcontrol installation Installation of the MESTAcontrol and first administration Duration: 2 days Number of sessions: 1 Number of trainees: 10 MESTAcontrol maintenance Administration, preventive maintenance, restore & back-up procedures Duration: 2 days Number of sessions: 1 Number of trainees: 10
Professional services IDEMIA will provide installation and hardening services and security services.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 40/63 offer
Reproduction and Disclosure Prohibited
Support and maintenance The proposed warranty services cover all the specific software version delivered by IDEMIA within the frame of the contract, starting from System Acceptance. The Service Level Agreement (SLA) is described in the next section.
2.2.3.1 > Maintenance scope The following items is under IDEMIA support and maintenance responsibility: Level 3 support Hotline: SW Level 3 (telephone assistance, investigation of the important incidents, that require highest level of expertise and or generate a change either configuration or software,). Provides a workaround or solution for the complex problems); Level 3 Software Corrective Maintenance: 3rd Level Support is typically located in IDEMIA premises. It includes bug analysis and fixes, and investigation that require high level of expertise, high knowledge of IDEMIA products, IT technologies, etc. The aim is to fix the problem through corrective maintenance (bug fix or workaround) to be compliant with the SLA; The Hardware Maintenance (level 1 to 3, spares, etc.) is out of IDEMIA scope.
2.2.3.2 > Service Level Agreement The following tables describe the Support and Maintenance services provided for the duration of this project. The Service Level Agreement (SLA) outlined in this proposal covers the Operating Hours as well as the Response and Resolution Time.
2.2.3.3 > Classification of incidents IDEMIA proposes the following classification of incidents:
Table 4. Classification of incidents
Description Severity level MESTAcontrol is not available and cannot process any violation analysis. No output is Critical produced MESTAcontrol capacity in feature or capacity is significantly reduced (<50%). Some key Major functions or workstations are unavailable. A non-essential function is affected, minority of users are affected. MESTAcontrol Minor capacity is decreased but remains above 50%.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 41/63 offer
Reproduction and Disclosure Prohibited
2.2.3.4 > Definitions
Table 5. Definitions
Time Definition Beginning event Ending event Response time Time required by IDEMIA to XX_Partner call IDEMIA message respond to the call and take into describing the problem indicating that the problem account the problem is being taken into account Resolution time Time required to solve a problem. IDEMIA message IDEMIA message Resolution time does not include indicating that the indicating that the problem the time required by the IDEMIA problem is taken into is solved and that the for problem analysis (checking account. system is working properly. trace files, getting information on the request etc.
Maintenance period hours 9:00 am to 5:00 pm (Central European Time) every French working day (not available on Saturday, Sunday and on French public holidays)
Time computing formula All the times are computed as a number of maintenance period hours. Periods that belong to non-maintenance period hours are not included into the time computing. For example, if a problem is declared at 4:00pm on Monday, and is solved at 10:00am on Tuesday, the downtime is of 2 hours: the time elapsed between Monday 5:00pm and Tuesday 09:00am is not included.
Service level The service level is the complement of the downtime. The downtime is used to compute the time during which the system is not available. Service level and downtime are valid only for severity 3 problems. No downtime is computed for severity1 and 2 problems and scheduled downtime required for maintenance work.
Maintenance Timing
Table 6. Maintenance Timing
Severity Response time Resolution time Critical 2 hours during maintenance period hours. One (1) French working day Major 4 hours during maintenance period hours. Two (2) French working days
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 42/63 offer
Reproduction and Disclosure Prohibited
Severity Response time Resolution time Minor 6 hours during maintenance period hours. IDEMIA will do all the efforts to solve problem as early as possible
2.3 > Project
IDEMIA references
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 43/63 offer
Reproduction and Disclosure Prohibited
Project organization IDEMIA has an extensive experience in the management of very large scale and complex projects, similar or bigger in terms of size and duration to the Unified platform for traffic radar violation processing solution proposed to XX_client_XX. As an example, we have successfully implemented similar solutions for the French governments (please see more details about the references in Section 8 /). IDEMIA is also ISO 9000 certified in over 50 sites covering all worldwide regions, and we employ over 250 people with professional project management training (IDEMIA Project Management Process, PMI or Prince 2). In this sub-Section we will first describe the overall methodology used by IDEMIA to manage such large and complex projects, ensuring the high-quality and timely implementation of the proposed solution. In Section 2.3.2.2 >, the detailed project plan with all main activities and deliverables are presented. The remaining sub-sections address our proposal for project organization with all
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 44/63 offer
Reproduction and Disclosure Prohibited
the key roles, communication and project governance, and for change, configuration, quality and risk management.
2.3.2.1 > Methodology – IDEMIA DRIVE To ensure expert management for the implementation of complex and high technology projects, IDEMIA has defined and standardised across the whole organisation a methodology called DRIVE (which is also ISO 9000 compliant). DRIVE defines the set of disciplines for programme and project management, covering all the stages - from the presales phase, through the implementation of the final delivery to the lifetime service operations. It enforces standard guidelines and best practices and brings together expertise, personnel and technology appropriate to a project's needs. Through DRIVE, programme / project management and control are always up to the minute, even when numerous stakeholders are involved such as: Customer representatives; Other external representatives selected by the Customer; Engineering and specialized technical teams; Other specialists in specific fields; Suppliers involved in the Contract; Other potential stakeholders. A programme is a set of projects and services related to a specific domain (such as but not limited to Road Safety, Civil Identity, Criminal Justice,…) and related to a single customer. The projects, which are part of the overall programme, are defined so they cover the needed activities for the defined unique deliverables (such as a complete system, additional features set, etc.). This means that large programmes such as the unified platform for traffic radar violation processing system for the XX_CLIENT_XX, will be split into different smaller projects to ensure more efficient management of the overall programme. Please note that all the implementation approaches covered in this section apply to both programmes and its projects, even though we will not always replicate the terms programme and project for the ease of reading. For the lifetime of the programme / project, the DRIVE methodology ensures the main principles are respected, with a focus on the following approaches: Customer-oriented approach; Common Language and Practices; Programme Monitoring and Control; Performance Reporting; Teamwork; Effective Communication; Risk Management;
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 45/63 offer
Reproduction and Disclosure Prohibited
Efficient Partnerships. The DRIVE methodology has defined 5 Golden Rules for the effective management of a programme / project (also in accordance with ISO 9001), ensuring all the objectives are achieved to a total satisfaction of the customers: GR#1 - Plan & Organise Defining and updating the Programme Management Plan (PMP) during the life of the programme, setting up the management of the Programme Team (PT), ensuring programme communications and the requirements for management and archiving of programme documentation. GR#2 - Requirements Management Defining and mastering the programme scope and content, through the management of requirements and the programme work breakdown structure, and ensuring that all tasks strictly meet the needs of internal and external stakeholders. GR#3 - Gate Management Defining the rules of sequencing a programme by identifying programme phases and milestones, consistent with programme delivery planning, organising reviews to pass the gates, and the associated criteria for success. GR#4 - Monitor Performance Managing programme performance through the implementation of the programme dashboard that contains programme performance indicators, and the definition of programme governance rules (monthly reviews). GR#5 - Risk Management Identifying, estimating and mapping the risks, to define and execute the corresponding mitigation plans, through the process of Risk management.
Project Management Plan as a cornerstone of DRIVE methodology The cornerstone of DRIVE is the establishment of the PMP (Project Management Plan), which ensures everyone’s full focus on meeting the requirements. The result of PMP is a thorough understanding of the processes, activities and participants required to meet the requirements and a reference document that drives the project. Every stakeholder can refer to it at any time during the project as it contains all the information necessary to control and measure progress, manage all project resources, updated as soon as any change is made. The PMP organises the project’s activities, and the various teams will know their exact scope of work within the project. It provides every team member with the information needed to achieve success in their own domain and to cooperate with the rest of the team. The expectations are clearly defined so that every member can focus his efforts on delivering the desired result. The PMP also serves as a baseline when moving from one project phase to the next. At each step, it is clear if the project’s fundamentals are being adhered to, notably if:
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 46/63 offer
Reproduction and Disclosure Prohibited
The client’s requirements are met; Coordination between projects is fluid; Risks are anticipated. The PMP ensures that the project is under full control and that progress to date, in all aspects, permits progression to the next phase of the project by covering: Project basic references Subsidiary management plans Project change management plan We use automatic tools to control and monitor all project tasks, milestones, quality management, training and documentation and merge them with existing standards, best practices, lessons learned from current deployments and an in-depth knowledge and understanding of XX_CLIENT_XX’s requirements. The Programme / Project Manager is responsible for delivering regular updates to allow the project to pass from one phase to another.
Knowledge and tools to support the robust method To successfully execute the powerful DRIVE methodology, IDEMIA’s programme and project managers have in-depth understanding of project management disciplines, including: Project Integration Management; Project Scope Management; Project Time Management; Project Cost Management; Project Quality Management; Project Human Resource Management; Project Communications Management; Project Risk Management; Project Procurement Management. To meet and exceed customers’ expectations, best practices are followed in: Tracing customers’ requirements and their progress Requirements Traceability Matrix; Setting up the project for success by identifying the right team and the scope. We determine the relationship between the project and its alignment with the organisation’s overall charter; Assigning the project team and distributing information to ensure the proper activities are undertaken. This process also includes ensuring that quality procedures are in place to address change management, organisational updates, possible changes to the plan;
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 47/63 offer
Reproduction and Disclosure Prohibited
Managing stakeholder relationships and requirements; Anticipation of and the management of risks; Developing the relevant resources, timelines and milestones, and mapping project delivery to business priorities (such as risk management, communications, duration and sequencing, quality, cost/budgeting and external dependencies). In addition to the above mentioned knowledge and best practices, IDEMIA uses also the following 5 tools to record, store, manage and display information concerning all aspects of a programme (and the corresponding projects), throughout its life cycle. Programme Dashboard Top-level reporting incorporating visual performance indicators Programme Management Plan Full details of the Programme including responsibilities, objectives, resources and timing Programme Risk Management Plan The activities concerned with identifying, analysing, and responding to programme risk Programme Gate Management Plan Gates define, monitor and control progress of a programme, throughout its life cycle. Every programme has defined gates and every gate enforces disciplines that are vital to programme success Requirements Traceability Matrix It enables to describe and follow the life of a requirement. The matrix is regularly updated to provide an up-to-date picture of requirements, their objectives and their status.
2.3.2.2 > Project Plan with activities and deliverables Before presenting in this section the detailed phased planning with the key activities and all the main deliverables, we start this section by describing the stages that IDEMIA proposes to follow during the implementation of the project.
Description of the project implementation stages The following proposed stages are described more in details in this section: Project kick-off stage; Requirements definition stage; Detailed design stage; Procurement stage; Customisation stage System installation stage (for both test and production environments);
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 48/63 offer
Reproduction and Disclosure Prohibited
Customer training stage; Acceptance and Go Live stage; Support and maintenance stage.
Project kick-off stage The purpose of this stage is to detail and agree the Project Management Plan together with other project management tools to be used (please see Section 2.3.2.2 >). During this stage, IDEMIA and XX_CLIENT_XX will also agree the final project organisation and governance processes to be used throughout this project.
Requirements definition stage The purpose of this stage is to detail and fine-tune the requirements, through the analysis of the technical and business needs, and to allow further detailing of the solution. This is composed of a set of critical activities for the final definition of the detailed solution such as: Defining the requirement collection processes and tools to be used. Defining the profiles needed for the requirement analysis and validation process from all stakeholders. These profiles could be technology experts as well as process owners. Understanding the current project operational business process. Generating the Requirements Definition Document (RDD) that consolidates the complete list of requirements:
º containing the functional as well as the non-functional requirements; º addressing the business processes and their impact on the other requirements; º addressing the integration requirements to identify the interfaces with other systems and processes. Confirm the captured requirements with XX_CLIENT_XX prior to releasing the Requirement definition document. The process detailed below is a proposal for standardising the way the requirements are collected and agreed on: The process is kicked off with a workshop with XX_CLIENT_XX; IDEMIA performs internal study to validate the feasibility and collect the clarifications needed to finalize the requirement definition; In case of minor comments, IDEMIA communicates the enquiries by mail; In case of major comments, IDEMIA agrees with XX_CLIENT_XX on a complementary meeting to discuss and clarify the gaps identified; Once all gaps are cleared, IDEMIA will release the list of requirements for XX_CLIENT_XX approval.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 49/63 offer
Reproduction and Disclosure Prohibited
Detailed design stage The purpose of this stage is to study the requirements and design the most suitable solution in terms of software, hardware, network, other COTS, and configurations. As an output of this stage, a set of detailed design documents are generated which describe in detail the solution to be implemented, covering architecture and design, the interfaces and data flows, GUI mock-ups, sizing, security, system availability including high availability and disaster recovery plans, and data replication.
Customisation stage (for XX_CLIENT_XX’s specific requirements) This stage covers the customisation needs, meaning the customisation of the features required as part of this project. . This stage also includes the needed integrations and tests for these customised features. Please see the Section 2.3.3.4 > for more details about the tests to be performed in this customisation stage.
System installation stage This stage includes setting up the test and production environments with the system software and components. For the stage, XX_CLIENT_XX is expected to provide all the needed capabilities for IDEMIA to proceed with the installation and tests. The needed configurations are also done in this stage, as well as the functional and non- functional tests executed by IDEMIA prior to the acceptance tests to be performed by XX_CLIENT_XX. The test plans to be used for both functional and non-functional acceptance tests will be provided by IDEMIA to XX_CLIENT_XX for its approval. For more details about the IDEMIA’s testing approach and methodology, please refer to the Section 2.3.3.4 >. In case it is required, site preparation shall be performed prior to installation. In order to have a smooth deployment, the system installation will be phased out as per the detailed planning presented in the Section Project plan2.3.5 >
Customer training stage Before the “Go Live” of the production environment, IDEMIA will provide the agreed training: User groups: the end-users to efficiently use the system on a daily basis for all the needed functionalities, technical staff (system administrators and supervisors) to be able to install, administer, manage and support the system in an autonomous way, and to the management The personnel to be trained is expected to have the needed knowledge of the technologies used etc. Please see section 2.2.1 >.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 50/63 offer
Reproduction and Disclosure Prohibited
Acceptance and Go Live stage In this stage, XX_CLIENT_XX is expected to perform the acceptance tests for both test and production environments – as per the agreed acceptance test plan. More details about the tests to be performed in this stage are provided in Section 2.3.3.4 > The outcome of this stage is the signed acceptance report by XX_CLIENT_XX, and in case of production environment, move into a live production environment (Go Live).
Support and Maintenance Stage During go-live preparation of the production environment, a formal transition is performed between the project manager and the support and maintenance project manager. Once the system is declared operational, the support and maintenance project team will be fully in charge of all needed activities during both the warranty period and the annual maintenance periods. XX_CLIENT_XX will be in charge of the administration and monitoring of the system, with specific support provided by IDEMIA for the first month of the live production system (please note that the duration of this specific support period by IDEMIA will be agreed during the project).
Quality Management Quality policy is part of a global Quality, Security & Corporate social Responsibility Charter (QSCR) that is in line with IDEMIA’s strategy and objectives. QSCR policies are deployed and applied within IDEMIA and they flow through all processes and organisations.
Figure 26. IDEMIA’s QSCR missions
Foster IDEMIA Promote performance customer & & compliance, stakeholder deploying voice through standards & the company policies
Deploy Stimulate innovative & continuous simple Quality, improvement Security & CSR systems
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 51/63 offer
Reproduction and Disclosure Prohibited
2.3.3.1 > Quality management system
Quality Information Structure To support IDEMIA’s activities worldwide, the Quality Department has established a global information structure outlined in the figure below.
Figure 27. Quality Information Structure
Global Quality Process Operationnal Quality Manual Process Mapping Policy Description Procedures
Process reviews
Process owners, with support of quality KE-HOLD STA ERS staff, annually review their processes to ensure: GOVERN Continued suitability; Adequacy; Support Sell Effectiveness; Deliver Systems Develop
Efficiency; M p
a a n CUSTOMERS Risk assessment and mitigation; m a g d e Supply a Personalize o Continuous improvement. P Chain R r o t g c r Manufacture u a d m o r Management review P
The Company Management reviews the
Global QSCR Management system at Human Purchasing least once a year to ensure its suitability, Ressources adequacy and effectiveness. Inputs for Information Technologies Management reviews include all QSCR scope and process reviews. The CEO chairs the review.
Audits A 3-year internal audit programme is defined to assess the effectiveness of the QSCR Management System. IDEMIA QSCR Management System is ISO 9001 and IATF 16949 certified and is audited yearly.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 52/63 offer
Reproduction and Disclosure Prohibited
2.3.3.2 > Operational Quality Management
Programme Quality Management Quality is managed by the following three processes: 3. Quality planning:
º Identify which quality standards are relevant to the programme º Determine how to satisfy them 4. Quality assurance (please see Section 2.3.3.3 > for more details):
º Evaluate overall project performance on a regular basis, º Ensure that the project will satisfy the relevant quality standards; 5. Quality control (please see the Section 2.3.3.4 > for more details):
º Monitor specific project results, º Determine if they comply with relevant quality standards, º Identify how to eliminate causes of unsatisfactory performance. These three processes interact with each other and with processes elsewhere. Each process may involve effort from one or more individuals or groups, based on the needs of the project. Each process generally occurs at least once in every project phase. Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here.
Responsibilities The Programme Manager is responsible for Quality as part of his normal programme management function. The Programme Manager will focus on: The three processes of Quality Management Involving others in Quality Management (experts, specialists, participants in other, similar work, etc.) Assigning specific processes to those individuals who are best qualified to deal with them The Programme Manager retains final authority over quality issues and the strategies to be adopted in their management and ensures the programme quality throughout its life cycle. This includes the quality of: Programme management; Development of the agreed customisations. The Programme Quality Manager stops any process/action or deliveries that would have unacceptable quality consequences on the products and services delivered to the customer, while consulting their hierarchy. He provides methodological support to the Programme Team:
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 53/63 offer
Reproduction and Disclosure Prohibited
Causal analysis Project management Continuous improvement He has a watchman’s role, detects eventual problem/issues and defines and implements the progress plans with operational personnel to improve quality performance.
2.3.3.3 > Continuous improvement for Quality Assurance IDEMIA’s quality assurance framework focuses on three key imperatives: 1. Alignment of business activities toward strategic priorities 2. Shared and balanced outcomes across Customer, Financial, Employee, and Process simplification results 3. Supporting a passionate, innovative Team to create and sustain improvements every day. It includes ongoing development and deployment of common tools, employee training and best practices to ensure business commitments are delivered. Results are supported by proven Lean-Sigma, Quality and strategic alignment approaches that are tailored for each scope of IDEMIA’s business activities. The improvement initiatives all share a common ambition to deliver business improvements that are sustained by simple, standard processes. Scope and approach of activities are broad and include, but are not limited to:
º Empowering employees to participate in decision-making and improvement activities appropriate to their levels in the organisation
º Implementing corrective actions to restore a level of performance aligned with customer expectations
º Completing structured projects to deliver measurable improvements over a defined timeline
º Fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in key performance measures such as quality, cost, customer satisfaction and speed.
2.3.3.4 > IDEMIA’s approach for Quality Control IDEMIA is committed to deliver a high quality solution as proposed to XX_CLIENT_XX. The project quality control is based on the Test Strategy document and the Master Test Plan, which are described below. This section provides also the details of the different test stages IDEMIA proposes to follow for the system to be delivered to XX_CLIENT_XX.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 54/63 offer
Reproduction and Disclosure Prohibited
Test Strategy document This document conforms to ISO29119-3 and defines the elements for the structured approach for the customisation, integration/validation and qualification of the system. The key focal points to design the test strategy are: Compliance to the Solution and Performance Requirements; Reduce the risk of failures and the consequences; Increase confidence on the system by detection of defects; Comply with contractual, legal or standard-based requirements. The document will cover: Testing Scope: Details of the test items and features in and out of scope; Testing and Process Control:
º Test Documentation, º Test selection and prioritisation, º Requirements traceability, º Issue Criticality assessment, º Test Metrics, º Test entry and test exit reviews, º Configuration management: - Documents control, - Software Source Code Management, - Test artefacts Management;
º Incident Management Process, º Re-testing & Regression testing, º Suspension & Resumption criteria, º Project Authority in assurance & witnessing, º Mock services/simulators, º Test management tools, º Approach to test automation, º Static testing techniques; Testing lifecycle: Describes the management process of the testing:
º Test approach, º Test phase overview schedule, º Test preparation phase, º Integration & Qualification test phase,
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 55/63 offer
Reproduction and Disclosure Prohibited
º Factory acceptance test phase, º System integration support, º Acceptance test phase; Risk and Issue Management: Describes the process of risk management that will be used.
Master Test Plan The master test plan details the related test cases for each Step, together with the test scenario, environment, datasets, scripts and tools used, as well as the test schedule.
Test stages proposed for this project The following test stages are proposed for this project, covering the tests to be conducted in the relevant project implementation stages – Customisation stage, System Installation stage and Acceptance and Go Live stage (please see the Section Project plan2.3.5 > for more details about each implementation stage proposed). Please note that we do not address the internal tests conducted on standard products, but focus on the specific tests applicable to FRS with XX_CLIENT_XX. Software customisation testing at the unit level (software feature testing basic functionality); Once our development team and QA staff have verified that the release requirements have been met, the core software is made available for the project teams for configuration. This activity is part of the “Customisation stage”. Factory testing
º Once the customised released is available, the software will be configured to meet the XX_CLIENT_XX’s specific requirements, and the following tests will be performed by IDEMIA: - Integration Testing: All workflows will be tested at a basic functional level (for example, a Hit or a No Hit scenario) and interfaces will be tested using simulators. - Qualification Testing: Each workflow will be tested in all outcome modes, such as Hit, No Hit, and error. Interfaces will be tested by using simulators. The Certification Engineer will provide the Lead Engineer with a list of issues (JIRA Tickets) that have been assigned a severity level and logged in a database for tracking and resolution.
º After the above tests, the Factory Acceptance Testing (FAT) will take place: IDEMIA test engineers will work with XX_CLIENT_XX to execute the approved test plans. For each test, XX_CLIENT_XX will either verify and sign off that the system met the requirements (Passed) or specify what requirement was not met.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 56/63 offer
Reproduction and Disclosure Prohibited
This activity is also part of the “Customisation stage”. Site Testing The main purpose is the final system testing, including functional and performance verification, and reliability assurance:
º Once the system has been installed, IDEMIA will perform qualification testing to ensure operational functioning prior to the Acceptance tests to be performed by XX_CLIENT_XX. These tests are performed as part of the “System installation stage”,
º After these qualification tests, XX_CLIENT_XX will conduct the agreed Acceptance Tests. For each test, XX_CLIENT_XX will either verify and sign off that the system meets the requirements (Passed) or specify what requirement has not been met (Failed). At the conclusion of the Acceptance Test, our Project Manager will issue an Acceptance Test Report, As a result of the successfully completed Acceptance tests, the deployment is validated ensuring the correct functioning of the system and that all performance levels are achieved as agreed. This activity is part of the “Acceptance and Go Live Stage”. During each test phase: The test results are compared with the corresponding requirement. The test case is linked to the corresponding requirements and describes the expected results; The required remediation measures are taken to fix the issue, as described in software maintenance in Section 2.2.3 >.
Risk Management The Programme Manager ensures the setup of an efficient risk management process that enables the identification, assessment and control of risks that could significantly deteriorate the performance levels of the programme. The measures taken by the Programme Manager and the team, in terms of the management of risks, are built around: Identifying, evaluating and mapping of risks; Designing and executing risk management action plans; Reporting on progress. Risk management is conducted in a methodical manner following the process summarised below: Identification of programme risks; Assessment and mapping of programme risks; Definition, cost assessment and acceptance of risk mitigation plans; Tracking and progress review of risk mitigation plans and analysis of their efficiency;
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 57/63 offer
Reproduction and Disclosure Prohibited
Detection and integration of new risks; Lessons learned. Each programme team member consolidates the risks for his/her function and participates (as required) in the identification, planning, assessing and management of the risks. Reports are provided in a systematic and prompt fashion to the relevant management teams about any perceived new risks or failures of existing control measures.
Risk reviews The of programme risk management is performed through risk reviews. The reviews involve: The programme manager; All programme team members; Experts identified as required; If needed, customer representatives, partners and/or suppliers. The risk reviews occur at regular intervals defined and scheduled by the programme manager: The frequency of these reviews is monthly, under normal circumstances. It may, however, be adapted according to the criticality of the risks identified or the stage reached in the programme life cycle. However, a programme risk review is held before each implementation stage, (during which the remaining risk level is reviewed and the main risk processing actions are presented for validation), if necessary. A typical programme risk review agenda will include: Status of existing risks, Progress and effectiveness of action plans, Decision on alternate solutions to adopt, Identification and agreement to address new risks, Validation/authorisation of risk closure.
Risk identification Risk identification is an ongoing activity in the risk management process. The identification is made systematically to ensure that all the major programme activities have been listed and that all the risks attached to these activities have been identified. At the beginning of the programme activities, a first risk review is held by the programme manager to identify, as exhaustively as possible, all of the risks for not achieving programme objectives.
Assessing risks Risks are assessed under the authority of the programme manager.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 58/63 offer
Reproduction and Disclosure Prohibited
Each risk is assigned a risk owner in charge of assessing its level of risk. Risks are assessed in terms of: Impact Likelihood Ability to control them
Processing risks For each risk identified, the risk owner assesses and determines the optimum approach for processing the risk (Accept, Avoid, Suppress, Reduce, Share or transfer). Depending on the processing option chosen, the risk owner will define an appropriate action plan, and evaluate its impact on both schedule and resources.
2.3.4.2 > Programme Risk dashboard Risk reviews are based on a standardised representation of the risks, of their initial criticality and of the progress in their mitigation, in the form of a risk dashboard. This dashboard enables all members of the risk review to get a summarised, stable, effective and recurring vision of the programme risk level and to track its progress. The programme risk dashboard is updated under the programme manager’s authority and includes: The information characterising programme risk management, as defined in the programme performance management plan and reported in the programme dashboard; A summary of risks formally addressed, their criticality, their owner and the actions implemented to process them; A presentation of the risks, classified by decreasing level of risk; A presentation of the status of action progress.
2.3.4.3 > Summary of main risks
Table 7. Overview of Unified platform Project Risks
Risk Gravity Probability Comments Manufacturers do not High Low Idemia proposes a generic interface format with a low provide support nor coupling interface which reduces the dependency and documentation to allow 3rd party to develop the interface if necessary. integrate violation Also this solution ensures to be future proof by packages proposing a standard format for new devices.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 59/63 offer
Reproduction and Disclosure Prohibited
Risk Gravity Probability Comments IDEMIA has already deployed systems in other countries and is used to adapting its solutions to local constraints. Different type of High Very Low MESTAcontrol architecture ensures to add more violation packages XX_CLIENT_XX users than required without impacts could lead to a heavier and seamlessly. verification workload The workload organization allows to separate work tasks between specialized teamset to absorb peak load
The sizing assumptions High Very Low MESTAcontrol system is based on a scalable of the radar production architecture which ensure future proof capability to may be under/over XX_CLIENT_XX. evaluated Assumptions taken are based on high hypothesis of violation packages production and size and the BOM could be adjusted upward and downward according to XX_CLIENT_XX input.
Project plan BlablablaPlanning
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Unified platform for violation processing Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 60/63 offer
Reproduction and Disclosure Prohibited
3 / Compliance matrix
NO COMPLIANCE MATRIX Complia Page and Explanatory notes nce Section no. in the proposal
XX
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Compliance matrix Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 61/63
Reproduction and Disclosure Prohibited
Page intentionally blank.
Document Ref: QA (Eshhar) TR Sys/Svc MCC CR Compliance matrix Doc.Ref#IIS/TP/19-190801-01 V1.0: Page 62/63