Draft SOW Costa Rica VMS.docx

Contents

1.

BACKGROUND

Costa Rica’s location, vast maritime territory, and limited security forces make it an attractive transit, warehousing, and logistics hub for South American cocaine and marijuana trafficking enroute to the United States and Europe. The estimated flow of cocaine arriving on Costa Rica’s shores has fallen since FY2022, thanks in part to U.S.-Costa Rica cooperation on interdiction efforts. However, narcotrafficking has driven a surge in transnational crime in Costa Rica. The expanding influence of transnational criminal organizations has led to rising violence and to corruption within Costa Rica’s security services and the broader public sector. The vital tourism industry and foreign direct investment rely on Costa Rica maintaining its reputation as a safe place to visit and a stable business climate. Costa Rica ended 2024 with 880 homicides, just under the 904 documented in 2023, a record-setting year. According to the Judicial Investigative Police (OIJ), these murders were linked to contract killings and disputes among criminal organizations. After years of underinvestment, rising violence prompted an eight percent budget increase for the Ministry of Public Security in 2024.

The International Narcotics and Law Enforcement Bureau (INL), along with the Ministry of Public Security and several municipalities, is implementing four regional monitoring centers, which will integrate the local video surveillance systems from several municipalities encompassing the interconnexion and interoperatiblity of 5,000 cameras. These regional monitoring centers will be located in San José, Alajuela, Montes de Oca and Heredia municipal police buildings. Additionally, the Ministry of Public Security will have a mirror of San José´s regional monitoring center in their Command-and-Control Center. To the end of developing this project, INL will be purchasing a Video Management System (VMS) software with several capabilities that will be stated further on in this statement of work (SOW).

Due to this, the Ministry of Public Security is working on a collaborative security model with the country’s 90 municipalities, in which the municipalities finance the video surveillance systems and make them available to the country’s various police bodies.

INL, in an effort to integrate all these initiatives and counter PRC malign influence in the country, is executing a project to integrate video surveillance images from four regional monitoring centers located in San José, Montes de Oca, Heredia, and Alajuela, with the goal of integrating more centers in the future.

As stated before, these four regional monitoring centers will share video surveillance footage with the Command and Control Center located at the Ministry of Public Security.

This project aims to procure a comprehensive VMS technological solution to enhance the capabilities of the regional monitoring centers and the Command-and-Control Center.

The four regional monitoring centers will be equipped with a VMS that enables interconnection and interoperability among the various municipal video surveillance centers across the country. Currently, there are 45 municipal monitoring centers that will have interoperability and interconnectivity with the VMS. This corresponds to 5,000 cameras of different technologies in the first phase, distributed across various locations nationwide. It is important to note that the administration and governance of the video surveillance systems are exclusively managed by the municipalities, either through third-party contracts or directly. This project does not involve the purchase of cameras; instead, it aims to integrate the existing cameras currently operated by the municipalities. The number of cameras is continuously growing; however, for this phase of the project, the VMS must be capable of administering 5,000 cameras.

In this project, of the 5,000 cameras, 30% must include analytics capabilities, distributed as follows:

· License plate recognition – 20%

· Tracking kit – 20%

· Special analytics, such as “hands up” detection and “fallen person” recognition – 20%

· Sound analytics – 10% For this project, the vendor must provide perpetual licenses for VMS solution. The annual maintenance and support cost must not exceed 5% of the total solution cost.

Considerations for the Integral VMS Solution:

· The integral solution provided by the vendor must comply with the following international protocols and standards: ONVIF, NENA 911, and APCO. Additionally, it must incorporate cybersecurity environments across the entire functional and operational architecture with the appropriate certifications.

· Data storage must be housed in physical data centers with alternate switches for the entire VMS solution; these data centers will be provided by the Government of Costa Rica.

· The VMS solution must facilitate interconnection and data management with governmental databases and other alternative solutions. In this first phase, the databases of the Ministry of Public Security will be integrated, leaving the possibility of integrating additional databases in the future.

· In Costa Rica, the 911 system is managed by a different public entity separate from the Ministry of Public Security, which means the solution must enable interconnection and interoperability in accordance with the current technological and legal framework of the 911 system.

· The vendor must provide three years of training and support, covering the implementation, execution, and operational phases of the project. Training must be offered to personnel managing the comprehensive VMS solution as well as staff from the four regional video surveillance centers.

2. Scope This project encompasses the procurement, installation, implementation, and deployment of a fully integrated technological solution of a Video Management System (VMS).

2.1. General

The Video Management System (VMS) will be a centralized facility that allows for the supervision, coordination and direction of critical missions for Public Safety and Citizen Security, which will be developed through the integration of advanced technology and communication:

· Administration, supervision and management of technological resources, information and equipment

· Effective communication between police forces and law enforcement agencies, for the secure exchange of information.

· Data Analysis: Collects and processes operational information to provide effective intelligence products for the mitigation of drug trafficking and illegal migration in the region.

· 24/7 Operations: It operates continuously with trained personnel, guaranteeing immediate response to situations and threats that arise.

· Use of various AI technologies for the anticipation of events and phenomena that threaten regional public safety.

· In summary, the scope of The Video Surveillance System (VSS) center lies in its ability to integrate advanced technology, facilitate communication and improve decision making in critical situations.

2.2. Functional Architecture

The designated space for the monitoring center will manage video and information from neighboring municipalities, where three regional video surveillance centers will be deployed.

In the space designed for the main monitoring center (main site) to be installed in the city of San José, it must integrate cameras from the neighboring municipalities, with the capacity to manage and analyze the video from these cameras.

The main site must be equipped with firewalls to prevent cyberattacks, which must remain updated. These firewalls must be capable of handling all video traffic from the surrounding municipalities (directly connected video) and receiving alerts from the regional sites.

The main site must be equipped with all necessary devices for the proper operation of the video surveillance solution and for receiving alerts generated by the regional centers.

At the regional sites, video from neighboring municipalities will be managed, and alarms will be sent to the main site. The regional sites will be installed in the cities of Heredia, Alajuela, and Montes de Oca.

The regional sites must be equipped with all necessary devices for the proper operation of the video surveillance solution. These must interact with the main site to send alerts generated by the VMS analytics for reporting purposes, as well as to report alerts generated at each peripheral site.

The regional sites must be equipped with firewalls for video connection from neighboring municipalities and for sending generated alerts to the main site.

All sites must be interconnected through a WLAN network with a minimum capacity of 10 gigabytes per second, depending on traffic. It should be defined whether this network must have QoS protocols to prioritize specific types of traffic.

Currently, municipalities have surveillance cameras from various brands and technologies (IP and analog). A technical feasibility study must be conducted on the existing cameras to be integrated into the video surveillance solution. The details of these cameras must be delivered and updated for proper project sizing and development, and the necessary infrastructure for video storage should be considered.

The system must be able to integrate existing cameras via ONVIF, if they are IP and support this protocol, as well as via RTCP, using either H.264 or H.265 codecs as applicable.

Video storage must cover 90 days for all cameras in the designated monitoring centers, with a maximum resolution of 2MP at 12fps, or according to the capabilities of the cameras if lower. Cloud storage solutions will not be accepted.

Regarding the analytics required for the solution, the following criteria must be considered:

· Analysis and identification of locations, time frequencies, population density, and vehicle density.

· Image analysis to identify vehicles, objects, events, and behaviors in real time.

· Automatic pattern and situation recognition that may require security responses.

· Some municipalities already have proprietary analytics programs for their devices; however, independent analytic processing must be considered to ensure a unified database and compatibility, integrating video from these cameras into the new system regardless of the brand of cameras or analytics used. The contractor must specify the characteristics of the cameras to be used in different analytics modules to ensure proper functionality, along with the considerations to be taken into account.

Licenses for the video surveillance solution must be perpetual, and the project scope must include three years of technical support, maintenance, and updates following the system's operational launch.

The IP connectivity of municipal cameras will be the responsibility of each municipality, considering fiber optic or data links for interconnection to the assigned monitoring center via public IP (Firewall), using the necessary security measures to ensure proper functionality and data protection.

The solution must be scalable, allowing for the expansion of the cameras at the four detailed monitoring centers and the addition of more regional sites as future phases are defined.

All cabling, accessories, and necessary components must be included for the proper functionality of the video surveillance solution.

2.3. Data Protection Policies

a. This data and information protection center will establish an Information Security Management System (ISMS) aligned with ISO 27001 and ISO 31000 standards. This approach aims to ensure the three fundamental pillars of security: confidentiality, integrity, and availability of information, as well as effectively managing associated risks.

b. Cybersecurity and Data Protection Measures: advanced tools such as firewalls, intrusion detection systems, and encryption protocols will be utilized to safeguard information. International cybersecurity standards and protocols such as ONVIF, APCO, and NENA will be adopted to prevent, mitigate, and counter unauthorized access or cyber-attacks.

c. Secure Information Exchange: Protocols and agreements will be established to ensure the secure transmission of data between institutions. Information sharing must comply with the applicable legal regulations in the country.

d. Interoperability and Communication Standards: Video protection systems will be integrated using the ONVIF protocol, ensuring interoperability between devices from different manufacturers. Compliance with international standards adopted by the International Electrotechnical Commission (IEC) will be ensured for the secure management of electronic access. Technologies aligned with the Internet of Things (IoT) standards will be incorporated to enhance connectivity and efficiency in public security systems.

3. Description of the Video Protection Surveillance System

3.1. General Aspects of Video Analytics

a) The system must be a scalable and modular software solution designed for safe cities.

b) The system must have an open architecture, supporting integration with third-party applications. Open architecture also means that the system must not restrict the institution to using specific proprietary hardware for any function, such as servers, NVRs, storage, or cameras from specific brands. This lack of hardware restriction must be verified for the system's overall functionality and for any of its modules, such as video analytics modules, third-party integrations, etc. Offers that restrict hardware support based on current or future hardware, commercial considerations, or manufacturer policies unrelated to the institution will not be accepted.

c) The system must be based on a 64-bit architecture to minimize the amount of hardware required for operation.

d) The system must be capable of integrating existing IP cameras, at least at the ONVIF open standard level, assuming the existing IP cameras support this standard.

e) The system must have the capacity to integrate and configure an unlimited number of unified video servers within a network, along with workstations, cameras, and user accounts, all managed through a single user interface (GUI). Each server must be capable of communicating with other servers, and video streams and events must be visible across servers.

f) The system must support PostgreSQL or similar open-source databases. The purpose of this requirement is to prevent the institution from being forced to pay additional licensing fees for database usage. This condition also applies to future system expansions.

g) The system must allow an unlimited number of sites and cameras to be viewed as a single site by the end user.

h) The system must have the capability to record and directly display analog cameras (incorporating encoders) and IP cameras.

i) System licenses must not be tied to the MAC address of IP cameras, ensuring that if camera replacements are needed due to maintenance or other reasons, the institution will not incur additional licensing costs.

j) The provided system licenses must not have a time limit or periodic renewal fees and must include updates to new versions for a minimum of four years.

k) The system must allow a distributed database architecture. Each server/NVR and administration station must be able to store an active, real-time updatable copy of the entire system configuration, enabling full recovery if at least one machine survives an incident. This aims to maximize system resilience against server failures and eliminate single points of failure.

l) The system must provide a "Fail Over" solution for video servers, allowing automatic takeover by the Fail Over server in case of operational failure. This includes transferring all configuration settings related to cameras, recordings, event logs, and databases. Upon recovery, it must not be necessary to search for video in separate disk locations. This functionality must be native to the platform, independent of third-party solutions, and capable of switching services between servers in less than two minutes. Additionally, it must be compatible with both physical and virtual servers.

m) The system must include a native event management solution. This solution must be able to map the client's security processes within the system, allowing operators to follow a set of configurable workflows and/or business rules based on events occurring in the system's daily operations. It must also be able to receive information and trigger actions across both native and third-party integrated modules within the platform.

n) The system must provide the option of proprietary video analytics modules and not solely rely on the integration of analytics modules from third-party companies. However, it must be capable of integrating third-party video analytics to ensure that the institution is not restricted to a single video analytics provider. This requirement aims to minimize the likelihood of service interruptions or system malfunctions due to version incompatibility between the system manufacturer and the manufacturers of video analytics modules.

o) The system must have the ability to activate/deactivate proprietary analytics modules on any IP camera within the system, presenting a pool of analytics module licenses that can be activated at any time on any IP camera depending on daily operational needs.

p) The system must include the option to add a package of situational analytics (line crossing, loitering, crowd detection, motion detection, object counting) that can be activated on any camera based on the contextual requirements where the analytics would be applied.

q) The system must include the option for integration with forensic video analytics systems based on parameters such as color, number of people or objects in the scene, etc. Likewise, the system must have its own forensic video search system (not third-party) based on the same previously described parameters.

r) The system must include a GIS (Geographic Information System) tool that can operate without requiring constant internet connection. This tool must be capable of georeferencing the various cameras and objects connected to the system, providing the operator with situational analysis capabilities based on geographic maps. These maps must be extractable and installable locally within the system. The addition of new maps to the platform in the future must not incur additional costs for the institution.

s) Local support must be provided by specialized personnel with expertise in both the platform and its customization to the institution’s current and future third-party system environment.

3.2. System Configuration

a) The system must allow the incorporation of Administrator and/or Operator stations in an unlimited manner, without this resulting in additional licensing costs for the institution. This applies to any future expansion of workstations.

b) The system must not require a dedicated main administration or configuration server, and this role can be assumed by any video server or administration station. Additionally, it must allow configuration changes to be made from any Video Server or Administration Station.

c) The system must provide an automatic camera detection tool on the network, allowing cameras to be added to the system directly.

d) The system must have the ability to individually configure each object within the system (video capture devices, cameras, sensors, relays, desks, monitors, etc.).

e) The system must allow backup of the entire system configuration in a single file (JSON or SQL).

f) The servers must have the capability to work alongside servers from different sites, and these multiple sites must be displayed to the user as a single site. Operators must be able to switch between different sites without needing to change the IP address, configuration, or repeat the login process.

g) The system must provide a tool for extracting logs, databases, and other necessary information for support purposes without requiring the application to be shut down.

h) The system must provide an internal failover tool for system redundancy, without the need to incorporate third-party virtualization tools. The failover tool must support the automatic or manual transfer of operational services from one host to another backup host with the same characteristics within the network, ensuring a service switching time of less than one minute so that the recording of cameras assigned to this host is interrupted for the shortest possible time.

i) The system must include a video server configuration tool that allows live migration of VMS video servers to different hosts in case of system maintenance, with minimal impact on operations. This functionality is essential given that the system operates in a 24/7 critical environment, requiring the capability to perform preventive maintenance tasks without disrupting live operations.

3.3. System Characteristics

3.3.1. General Support

a) The system must support most globally recognized IP camera manufacturers.

b) The system must support major compression formats: Wavelet, MJPEG, MPEG4, H.264, H.265, and MxPEG.

c) The system must support cameras that are compatible with ONVIF and must support the RTSP protocol to receive video streams from cameras using RTSP. Additionally, it must support HTTP drivers to obtain video from any device that uses the HTTP protocol.

d) The system must provide an RTSP and ONVIF video server capable of supplying live and recorded video streams to external third-party systems, such as VMSs or CADs. The RTSP and ONVIF video server must have the ability to allow external systems to view and control (PTZ) cameras managed by the system. This capability is required to ensure that the institution is not restricted to a single video platform for future system expansions to additional buildings and/or facilities.

e) The system must incorporate functionalities for monitoring the health of connected cameras and servers, ensuring that real-time graphical alerts are generated in case of disconnection or malfunction of cameras and/or servers.

f) The system must incorporate the capability to issue alarms using the SNMP protocol (MIB Traps) for connection to centralized monitoring systems based on this protocol.

g) The system must provide secure connections to IP cameras using the HTTPS protocol. The same secure connection must be maintained when retrieving information from the cameras' SD cards (edge storage).

h) The system must be capable of storing presets and camera tours in the VMS to avoid saving this information at the edge (camera).

i) Camera control via PTZ must be configured based on priority levels among user profiles and sites (Monitoring Center and Remote Sites). Additionally, the platform must allow users to request permission to manipulate a camera that is currently being used by another user.

j) The VMS operator must be able to generate reports on events detected by the cameras for third-party emergency processing systems. Reports must be created from the VMS operator interface and must include at a minimum the address, time, and type of incident, as well as operator comments. The list of available incident types must be editable by the institution.

k) The VMS must have the capability to notify the operator using a PTZ camera when control of the camera has been taken by an operator with a higher priority.

l) The VMS must include a tool that enables monitoring of camera performance according to the defined throughput design. This tool must have the capability to set design parameters for the cameras (MP, frames per second, etc.) and generate alarms when connected cameras operate outside the defined parameters.

3.3.2. Video Recording

a) The system must support video streams directly from IP cameras and analog cameras connected to IP encoders.

b) The system must have the capability to configure recording in continuous mode, motion-triggered mode, scheduled mode, or event-based mode.

c) Each camera’s resolution, frame rate, and bandwidth must be configurable independently, and these changes must not affect the recording or display settings of other cameras.

d) The system must support multiple models and brands of IP cameras/devices.

e) The system must have the capability to protect each camera's recording with a password.

f) The system must be able to record at least 400 video channels or 1.3Gbps of video per server, based on server capacity. This feature must be available for servers of any brand, provided they meet the technical specifications indicated by the VMS manufacturer. The purpose of this requirement is to ensure that the institution is not restricted to a single brand of servers and storage. The provider must specify in their offer the technical characteristics required for the servers to support this functionality.

g) The system must have the capability to record at a different frame rate than the transmission rate.

h) The system must include a button in the camera display interface to easily start/stop recording of a specific camera.

i) The system must provide an option to configure the minimum and maximum retention period for video storage per camera.

j) The system must support pre- and post-alarm recordings at full frame rate.

k) The system must maintain sufficient disk space for video operation without requiring human intervention for space management.

l) The system must allow recording at one frame rate when there is no movement and a different frame rate when movement is detected, optimizing disk space usage.

m) The system must have the capability to display pre-recorded video as if it were a camera in the system. The video format must be native and AVI.

n) The system must be able to record with a reduced frame rate compared to the one sent by the camera. This functionality must be programmable via software, allowing configuration for recording at a certain resolution during an initial time period, followed by a lower resolution recording for an additional time period. This recording must be possible on backup systems different from the original storage medium. The purpose of this functionality is to maintain recordings for a longer period without incurring high costs.

o) The system must have the capability to export video in its native format and provide an application for remote viewing. The exported video must be password-protectable.

p) The system must allow the use of non-proprietary storage hardware, enabling’future upgrades to recording capacity.

q) The system must support long-term storage on media separate from those directly connected to the servers.

3.3.3. Video Display

a) The system must provide the ability to view camera images locally on the video server, administration station, operator station, and via a web browser.

b) The system must be capable of using standard computing equipment in workstations with compatible processor architectures, without requiring high-cost equipment. This requirement aims to allow the institution to avoid excessive expenses for workstation setups.

c) The system must be able to decompress video in H.264 or H.265 using the capacity of graphics cards as well as the Intel HD Graphics capabilities present in processors.

d) The system must not exhibit delays between video streams viewed on an Operator or Administrator Workstation and those displayed on the Video Wall.

e) The system must allow the addition of text overlays on video as watermarks, originating from any internal system or external applications, without being limited to timestamps, dates, or camera names. The system must be sufficiently flexible to support text overlays from any existing or future applications, provided that the application provider/developer does not restrict text delivery to the system.

3.3.4. Playback / Video File Search

a) The system must provide the ability to play back and review recorded videos on a Video Server, either locally, from workstations, or via a web browser.

b) The system must be capable of displaying an event alarm timeline across all channels. The timeline must support simultaneous playback of at least 32 cameras without affecting system performance, while clearly differentiating recordings based on motion detection from those recorded without motion detection.

c) The system must provide a calendar-based search feature for easy retrieval of recorded videos.

d) The system must have the capability to mask non-essential areas of video and perform searches only within areas of interest ("smart searches").

e) From the VMS video system interface, users must be able to play back recorded video streams (24/7) from the last few minutes of recording. The playback duration must be configurable, ranging from 15 seconds to 10 minutes.

3.3.5. Video Export

a) The system must have the capability to export multiple videos simultaneously from different cameras.

b) The system must provide the option to secure exported files with password protection.

c) The system must support exporting synchronized video and audio into a single file. These files must be playable on any computer, even if the VMS client is not preinstalled.

d) The system must have the capacity to export the video in its native format and provide an application for remote viewing. The exported video must have the option to be password-protected and to have a watermark overlay.

3.3.6. Audio

a) The system must support live audio recording and playback from IP devices with this capability, not being restricted to camera audio only. Audio recording must be able to be activated by programmable events within the platform.

b) The system must support live audio from each individual IP audio device. The supported audio must be full duplex (intercoms) and unidirectional (speakers).

c) The system must support synchronized recordings between camera audio or independent microphones and video, with the capability to export these synchronized audio and video recordings into a single file for event review by institutional personnel. These files must be playable on any computer, even if the VMS client is not preinstalled.

d) The system must support synchronized audio and video playback from the same video viewing interface.

3.3.7. Movement Detection / Movement Zones

a) The system must incorporate motion detection capability on all cameras managed by it, optimizing the storage required for recording. This functionality must be included in the system acquisition cost, regardless of future camera connections.

b) The system must support multiple motion zones per camera.

c) Each zone must be uniquely addressable and have the ability to configure customized reactions based on the alarm generated.

d) Each zone must have the option to be armed or disarmed individually.

e) Each zone must have the option to apply a privacy mask.

f) Each zone must have the ability to individually configure the frame rate, video quality, and memory frames for motion detection.

g) The system must display the motion zone in a different color when movement is detected.

4. Audit

a) To audit the activities of system operators and administrators in internal investigations within the institution, the VMS must include an Audit Module that records the actions performed by operators and administrators.

b) The minimum list of supported actions must include:

c) System Administrator:

· Created objects, modified configurations, and deleted objects

· Altered user permissions

· Enabled or disabled objects

d) System Operator:

· Authorized operator access

· Viewed cameras and consulted recorded videos

· Activated and deactivated video recordings

· Activated and deactivated motion detection

· Exported video

· Created, edited, or removed camera presets and tours

· Activated PTZ camera control, called presets, and executed tours

· Adjusted camera zoom or focus, activated wiper or washer functions

e) The audit module interface must support viewing, filtering, reporting with dashboards, and exporting results. Additionally, it must include a dedicated API for integrating the audit module with third-party systems that require access to the recorded information.

5. Integration Characteristics

a) The system must have the capability to support external alarm devices, sensors, and relays through I/O input and output capabilities.

b) The system must be able to invoke external applications directly from the same interface.

c) The system must have the ability to send alarm notifications to specific system clients.

d) The system must have the capability to provide audible alarm notifications.

e) The system must support macro programming.

f) The system must have the capability to create programmable scripts based on languages such as C/C++, JavaScript, or VBScript.

g) The system must provide an option to create time zones for scheduling events/reactions within the system.

h) The system must be able to notify the administrator if a camera fails, is blinded, is out of focus, or encounters connectivity issues with the server. The percentage of the blinded or out-of-focus area that triggers an alarm must be configurable to minimize false alarms. This functionality must be available for all current and future cameras, without incurring additional costs for the institution.

i) The system must support the creation of custom HTML5 forms integrated into the VMS user interface, ensuring that the VMS platform functions as a single interface for the various systems within the institution.

5.1. Remote Functions

a) The system must support remote administration for all functionalities and management tools, including both proprietary and third-party analytics.

b) The system must provide the ability to remotely enable/disable or modify user account access rights without requiring an operator to be physically present at the site or company.

c) The system must allow remote enabling/disabling or modification of camera settings without requiring an operator to be physically present at the site or company.

d) The system must support real-time remote storage.

e) The system must provide multiple remote clients and administrators as needed, without incurring additional licensing costs for the institution.

f) The system must have the capability to efficiently manage bandwidth using TCP/IP.

g) The system must include a centralization (Federation) solution to consolidate cameras from multiple sites into a single central location. This solution must also support the centralization of audio, maps, and video analytics from remote sites. Additionally, the centralization solution must allow a supervisor at the central site to take control of PTZ cameras at a remote site, with higher permissions than those of a local operator at the remote site.

h) The centralization solution must incorporate bandwidth optimization features to prevent multiple operators accessing remote cameras from overwhelming the available bandwidth between the central site and remote sites. It must restrict video streaming to only one video stream per remote camera, regardless of the number of operators and/or administrators viewing or recording the same remote camera.

i) The system must support remote alarm control for servers and management of I/O devices.

j) The system must include a camera viewing application installable on mobile devices such as smartphones and tablets, with controlled access via a defined protocol.

6. Cybersecurity Support

a) The system must support the use of digital certificates installed in cameras to verify trusted edge devices.

b) The system must support secure (encrypted and source-verified) connections between cameras and video servers. Camera controls, including PTZ functions, video, audio, and I/O signals, must be transmitted via HTTPS tunneling.

c) The system must be capable of establishing HTTPS sessions with secure SSL/TLS authentication, using trusted certificates installed in cameras to protect transmitted information.

d) The system must support secure HTTPS connections between video servers and lightweight client instances (web and mobile).

e) The system must support HTTPS tunneling when retrieving video from internal camera storage (edge storage) for cameras with this feature.

f) The system must support digital signature verification for exported videos to ensure their authenticity.

g) The system must support a native video player capable of verifying digital signatures.

h) The system must provide a digital signature verification utility that can be used to check the authenticity of exported videos in native or commercial formats (AVI/ASF).

i) The system must support AES-128, AES-192, and AES-256 encryption algorithms for exported video security.

j) The system must support hardware-accelerated self-encryption using AES-128 and AES-256 for data stored on recording disks.

7. Infrastructure

a) The system must run on Windows operating systems but must also offer a VMS version compatible with Linux, should the institution choose this alternative for security or cost-efficiency reasons.

b) The system must have the option to operate as a Windows service.

c) The system must support basic Windows diagnostic tools.

d) The system must be able to automatically restore itself in the event of a network connection loss, without requiring operator intervention

e) The system must support virtualized environments.

f) The system must have the capability to support a minimum of 5000 cameras or a recording throughput of 1.7 Gbps per server, ensuring the optimized use of computing resources within the institution.

8. Analytics Description

8.1. Automatic License Plate Recognition Module

8.1.1. General

a) The solution must be software-based only and compatible with commercially available IP cameras, provided they meet the minimum required specifications to deliver a color image in which the license plate is clearly distinguishable, without distortion or blurriness. Solutions based solely on proprietary hardware that tie the institution to a specific hardware provider will not be accepted. However, the solution should include the option to offer an LPR camera of the same brand, allowing the institution to receive support from the same manufacturer for both hardware and software.

b) The system must have the ability to enable/disable license plate recognition modules on any camera within the VMS system, providing a pool of license plate recognition module licenses that can be activated at any time on any camera based on daily operational needs.

c) The system must operate unattended 24 hours a day, seven days a week.

d) The system must simultaneously detect, capture, and compare multiple vehicle license plates in real time and for forensic analysis in pre-recorded videos.

e) The system must automatically determine the best frame from the video stream.

f) The system must allow license plate recognition video streams to synchronize with the video streams of an unlimited number of cameras.

g) The system must provide compensation for distortion and incorrect positioning of the captured license plate relative to the vehicle.

h) The system must record and store in a database the image, date, time, license plate, country/state of the plate, and the vehicle’s direction relative to the camera.

i) The system must offer at least three modes for storing captured license plate images in the database: full scene photograph, vehicle and plate photograph, or just the license plate image.

j) The system must be capable of using a central database (or multiple databases) in different or parallel locations. Even with low bandwidth, it must compare captured plates in real time with this database. When using distributed databases, the system must have the ability to replicate remote databases in a central database so that remote database information is backed up in the central database in case of availability failures in remote databases.

k) The system must detect vehicles approaching or moving away.

l) The system must be capable of recognizing license plates at speeds of up to 209 km/h.

m) The system must have an accuracy rate of over 90% in license plate recognition, measured across all readable plates.

n) The system must provide a quality index for license plate captures

o) The system must be able to identify multiple countries/states for license plates and determine the country/state of origin for each detected plate.

p) The system must be capable of automatically filtering recognition results and discarding low-accuracy recognitions—defined by the administrator

q) The system must be capable of capturing multiple traffic lanes (if the camera/resolution used allows it).

r) The system must provide the ability to adjust recognition parameters and thresholds.

s) The system must be able to log an event/alarm when a license plate is recognized or lost.

t) The system must be configurable to transmit only text, text and images, or text and video when detecting a license plate on blacklists or whitelists.

u) The system must allow editing by a human operator.

v) The system must have the option to be configured to prevent editing by a human operator.

w) The system must be capable of managing and recognizing vehicle license plates from multiple video channels in real time.

x) The system must be remotely manageable and fully integrated into the centralized solution (Federated Architecture) of the VMS.

y) The system must be accessible from a standard client PC with low-cost processors for remote visualization.

z) The system must be able to use internal statistics to adjust the recognition algorithm to improve performance as defined by the camera.

aa) The system must support internal license plate registration lists (whitelists, blacklists, and informational lists).

ab) The system must support automation of system reactions based on license plate recognition events in internal lists or external databases.

ac) The system must support sound playback upon plate recognition.

ad) The system must include the option to recognize vehicle make, model, and color.

ae) The system must operate with both color and black-and-white cameras without affecting the module’s performance.

af) In the case of an LPR camera provided by the same software manufacturer, it must have distinctive features compared to standard IP cameras. These features must include a motorized lens remotely configurable via the software and built-in white light illuminators integrated into the camera body (not external). The camera’s specifications must ensure proper software functionality, guaranteeing the highest possible accuracy in captured license plate readings. It must also have the option of processing the license plate recognition module within the camera housing.

8.1.2. Search

a. The system must have the capability to perform multiple search methods for captured license plates, dates, and/or times and associate the results with images/videos.

b. The system must be able to use generic input types during searches for unknown characters.

c. The system must be able to conduct searches using any known character string.

d. The system must be able to perform searches for multiple vehicles that match the search criteria.

e. The system must be able to trigger alarms and/or execute complex events in both proprietary and third-party systems based on predefined license plate parameters.

f. The system must be capable of forensic searches by vehicle type, as well as color, make, and model.

g. The system must be able to conduct forensic searches for convoys, understood as groups of vehicles moving together. This search must be possible across one, several, or all LPR detectors within the system, as well as within specific time periods.

8.1.3. Integration

a) The system must be capable of integrating with other devices, such as access control systems, door controls using dry contacts, speed radars, tag or RFID systems, CADs, other VMSs, etc.

b) The system must include internal scripting mechanisms to program logical behaviors of varying complexity levels.

c) The system must be capable of integrating and exchanging information in real time with external databases.

d) The system must provide an SDK connection for integration with third-party systems.

e) The system must offer an API for third-party systems seeking integration. The API must support the transmission of events, individual images obtained from video, and video sequences.

f) The system must be able to integrate with third-party access control systems via dry contacts and APIs.

g) The system must have the capability to connect with third-party access control systems, delivering a Wiegand signal to open access barriers using license plate recognition, either as a substitute for or in conjunction with (dual verification) an access control system card. This functionality must also include transmitting vehicle-related information to the third-party access control system when triggering barrier opening. This solution must ensure activation times of less than one second between plate detection and barrier opening, enabling seamless contactless passage in high-traffic access points.

8.2. Object Detection Tracking Module

8.2.1. General

a) The VMS must include a set of advanced video analytics detectors designed to enhance system operators' situational awareness.

b) The module must be capable of classifying objects as Person/Vehicle using a neural network-based engine.

c) The module must provide quick access to video files, ensuring that when an operator selects and clicks on an event viewer entry generated by the detector, the corresponding video is immediately displayed on the VMS video matrix.

d) The module must support fixed cameras or 180° / 360° cameras.

e) The module must support application in both indoor and outdoor environments.

f) The module must allow configuration of minimum and maximum object sizes.

g) The module must allow configuration of scene perspectives.

h) The module must offer an option to adjust object tracking sensitivity.

i) The module must provide an option to select the video resolution used for object tracking.

j) The module must incorporate advanced algorithms for extracting close-ups.

k) The module must incorporate advanced algorithms for object tracking.

l) The module must allow predefining the time to stop tracking objects that remain stationary.

m) The module must allow predefining the time to stop tracking false positives.

n) The module must be capable of handling sudden changes in scene brightness.

o) The module must support enhancement of objects of interest in video files.

p) The module must support advanced event management based on events generated by the detectors. For example, it must be capable of creating visual notifications in the event viewer, alarm monitor, 2D/3D maps, Video Wall, audio notifications, email/SMS alerts, mobile app notifications, and sending alerts to emergency service centers such as 911 or similar.

q) The module must be capable of integrating analytics events into a proprietary event management system from the same brand.

r) The module must be capable of storing detection data and subsequently performing forensic searches for people, animals, or objects based on color search criteria.

s) The module must be capable of activating audible notifications, messaging, or email alerts when a detection occurs.

t) The module must be capable of sending notifications to third-party systems when a detection occurs.

8.2.2. Detection

a) The module must be capable of detecting abandoned objects/packages.

b) The module must be capable of detecting objects removed from the scene.

c) The module must be capable of detecting loitering, meaning identifying people moving within a controlled area for a certain period of time.

d) The module must be capable of detecting crowds, meaning identifying large groups of people in both open areas and enclosed spaces, providing early warning of potential disturbances or disorder.

e) The module must be capable of detecting intrusion events, meaning identifying objects entering the perimeter of a restricted area.

f) The module must be capable of counting objects, meaning counting entities such as people or vehicles crossing a virtual control line.

g) The module must be capable of detecting a person running, meaning identifying someone moving at a speed…