Technical Specification

1. Executive Summary

This document specifies a computer vision-based system designed to augment existing RFID timing infrastructure at cycling events. The primary objective is to reduce missed tag reads, particularly in lapped races where a single missed read places a participant one lap behind.

The proposed solution leverages existing CCTV infrastructure (Hikvision DS-7600 series NVR) to provide a secondary detection mechanism. By correlating video-based bicycle detections with RFID triggers, the system identifies gaps in timing data and assists operators in resolving discrepancies.

Design Philosophy

The system operates on the principle of adaptive resource allocation: when RFID timing is working reliably (>98% correlation), the vision system runs in passive mode — detecting and archiving but not creating operator tasks or consuming resources on re-identification. When discrepancies occur, the system escalates through processing modes (NORMAL → ALERT → CRITICAL), increasing operator involvement proportionally.

Scale

Up to 300 participants per race
Up to 2000 participants per event day
Peak crossing rate: 10 cyclists in 5 seconds (sprint finishes)
4+ cameras per finish line

Key Capabilities

Real-time bicycle detection using deep learning models (YOLO-based)
Multi-camera fusion with calibration and automatic drift detection
Adaptive processing modes based on correlation success rate
Integration with race administration for scheduling context
Integration with custom tag-server via MQTT/WebSocket
Operator workflow for discrepancy resolution with task prioritisation
Post-race batch review for archived detections

2. Problem Statement

2.1. Current Situation

RFID timing systems are the standard for cycling events, using passive tags mounted on frame boards. Whilst generally reliable, these systems exhibit inherent inaccuracies resulting in occasional missed reads.

Contributing Factors to Missed Reads

Tag orientation relative to antenna
Metal interference from bicycle frames
Multiple tags in the read zone simultaneously (peloton crossings)
Environmental conditions (moisture, temperature)
Reader antenna positioning and power settings

2.2. Impact

In single-lap races, a missed read requires manual intervention but is easily detected at the finish. In lapped races, the impact is severe: a single missed read places the participant one lap behind the group, fundamentally corrupting their results. Manual detection requires cross-referencing multiple data sources and is error-prone under time pressure.

2.3. Objective

Provide an automated secondary detection system that:

Identifies potential missed RFID reads in real-time
Correlates detections across multiple data sources
Assists operators in resolving discrepancies efficiently
Maintains an audit trail of all corrections

3. Design Philosophy

3.1. Augmentation, Not Replacement

The RFID timing system remains the primary and authoritative source for race timing. The vision system serves as an augmentation layer that:

Provides a safety net for missed RFID reads
Adds a secondary audit trail for disputed results
Assists operators during high-density crossings
Does not add overhead when RFID is functioning correctly

Key Principle

When RFID is working well, the vision system should be nearly invisible. When discrepancies occur, it becomes the operator’s most valuable tool.

3.2. Adaptive Resource Allocation

Processing video streams and running re-identification models consumes significant resources (GPU, operator attention, storage). The system adapts its behaviour based on the current correlation success rate:

Correlation	System Behaviour	Operator Experience
Excellent (>98%)	PASSIVE mode: detection only, re-ID skipped, no tasks	Dashboard shows "All Clear"; minimal attention required
Good (90-98%)	NORMAL mode: full pipeline, tasks for discrepancies	Occasional task queue items to review
Degraded (<90%)	ALERT mode: aggressive re-ID, all gaps prioritised	Elevated attention; audible notifications
Failed (<70% or lost)	CRITICAL mode: video primary, all detections → tasks	Full manual verification required

Correlation

System Behaviour

Operator Experience

Excellent (>98%)

PASSIVE mode: detection only, re-ID skipped, no tasks

Dashboard shows "All Clear"; minimal attention required

Good (90-98%)

NORMAL mode: full pipeline, tasks for discrepancies

Occasional task queue items to review

Degraded (<90%)

ALERT mode: aggressive re-ID, all gaps prioritised

Elevated attention; audible notifications

Failed (<70% or lost)

CRITICAL mode: video primary, all detections → tasks

Full manual verification required

3.3. Race Context Awareness

The system integrates with race administration to understand:

Which participants are eligible to cross at any given time
Expected lap times and race duration
When races start and finish

This context enables intelligent filtering (ignore detections outside race windows) and improved matching (predict expected crossing times).

3.4. Fail-Safe Design

If vision fails → RFID continues as normal; operators notified
If RFID fails → Vision elevates to primary; operators alerted
If both fail → Manual timing procedures; system logs for post-race recovery
If correlation degrades → System adapts mode; operators informed

4. System Overview

4.1. Context Diagram

4.2. High-Level Architecture

5. Functional Requirements

5.1. Module 1: Video Stream Adapter (VSA)

Purpose

Interface with the Hikvision NVR to provide both live and recorded video streams to downstream components.

Table 1. Requirements
ID	Requirement	Priority
VSA-01	SHALL connect to Hikvision NVR via RTSP for live streaming	Must
VSA-02	SHALL support retrieval of recorded footage via Hikvision ISAPI for specified time ranges	Must
VSA-03	SHALL support multiple simultaneous camera streams (minimum 4 cameras)	Must
VSA-04	SHALL provide frame-accurate timestamp synchronisation across all streams	Must
VSA-05	SHALL handle stream disconnection gracefully with automatic reconnection	Must
VSA-06	SHALL expose a unified API for frame retrieval (live or recorded) by timestamp	Should
VSA-07	SHOULD support configurable frame rate decimation to reduce processing load	Should
VSA-08	SHALL log all stream interruptions with duration and recovery status	Must

5.1.1. Hikvision DS-7600 Series Integration

The Hikvision DS-7600NI series (Pro) NVRs support both RTSP streaming and ISAPI for programmatic access.

RTSP Stream Access

# Main stream (full resolution)
rtsp://<username>:<password>@<nvr-ip>:554/Streaming/Channels/<channel>01

# Sub stream (lower resolution, reduced bandwidth)
rtsp://<username>:<password>@<nvr-ip>:554/Streaming/Channels/<channel>02

# Example: Camera 1 main stream
rtsp://admin:[email protected]:554/Streaming/Channels/101

ISAPI Playback Access

# Search for recordings
POST /ISAPI/ContentMgmt/search
Content-Type: application/xml

<CMSearchDescription>
  <searchID>search-001</searchID>
  <trackList><trackID>101</trackID></trackList>
  <timeSpanList>
    <timeSpan>
      <startTime>2025-12-08T14:30:00Z</startTime>
      <endTime>2025-12-08T14:35:00Z</endTime>
    </timeSpan>
  </timeSpanList>
  <maxResults>100</maxResults>
  <searchResultPostion>0</searchResultPostion>
</CMSearchDescription>

# Retrieve playback stream
GET /ISAPI/ContentMgmt/download?playbackURI=<uri-from-search>

Table 2. DS-7600 Series Capabilities
Feature	Support
Maximum channels	8, 16, or 32 depending on model variant
Recording resolution	Up to 12MP per channel
RTSP streaming	Yes — main and sub streams per channel
ISAPI	Yes — full ContentMgmt API for search and playback
H.265/H.264	Both supported
NTP synchronisation	Yes — configurable NTP server
Timestamp in stream	Yes — embedded in frame metadata
Simultaneous playback streams	Typically 4-8 concurrent streams

Implementation Notes

Use sub-stream for real-time detection if bandwidth is constrained; main stream for review
Frame timestamps should be extracted from RTSP RTP packets, not system clock
ISAPI requires digest authentication; maintain session for performance
Consider caching recent footage locally to reduce NVR load during review

Technical Considerations

See Camera Specifications for bandwidth and processing calculations
Consider hardware-accelerated decoding (NVDEC) for multiple streams
Test maximum concurrent playback streams with your specific NVR model

Table 3. Camera Specifications
Parameter	Value
Resolution	3 MP (typically 2048 × 1536 or 2304 × 1296)
Frame Rate	30 fps (standard) or 60 fps (high-speed capture)
Colour	Yes (RGB)
Codec (assumed)	H.264 or H.265

Table 4. Bandwidth Calculations
Scenario	Per Camera	4 Cameras	8 Cameras
3MP @ 30fps (H.264, high quality)	8-12 Mbps	32-48 Mbps	64-96 Mbps
3MP @ 60fps (H.264, high quality)	15-20 Mbps	60-80 Mbps	120-160 Mbps
3MP @ 30fps (H.265)	4-6 Mbps	16-24 Mbps	32-48 Mbps
3MP @ 60fps (H.265)	8-12 Mbps	32-48 Mbps	64-96 Mbps

Gigabit Ethernet (1 Gbps) is sufficient for up to 8 cameras at 60fps with H.264. For reliability and headroom, 10 GbE or dedicated network segment is recommended for 6+ cameras.

Processing Load Estimation

At 3MP resolution, each frame is approximately 9.4 megapixels (uncompressed). For YOLO inference:

30 fps per camera — Requires ~33ms per frame for real-time processing
60 fps per camera — Requires ~16ms per frame for real-time processing

Recommendation: Process at 30 fps even if cameras capture at 60 fps. The additional temporal resolution provides no significant benefit for finish line detection, but the 60 fps stream can be retained for high-quality playback during review.

Frame Decimation Strategy

Camera captures:  60 fps → NVR (full quality recording)
                       ↓
                  30 fps → Bicycle Detector (real-time processing)
                       ↓
                  On-demand → Frame Retriever (review at 60 fps)

5.2. Module 2: Bicycle Detector (BD)

Purpose

Process video frames to detect bicycles and their positions within each frame, providing trigger events when bicycles cross the finish line zone.

Table 5. Requirements
ID	Requirement	Priority
BD-01	SHALL detect bicycles in video frames using a deep learning model (YOLOv8 or equivalent)	Must
BD-02	SHALL provide bounding box coordinates for each detected bicycle	Must
BD-03	SHALL assign confidence scores to each detection	Must
BD-04	SHALL process frames at minimum 15 fps per camera on target hardware	Must
BD-05	SHALL distinguish bicycles from other objects (cars, pedestrians, motorcycles)	Must
BD-06	SHALL support configurable detection zones (regions of interest) per camera	Must
BD-07	SHALL generate trigger events only when a bicycle enters/exits the finish line zone	Must
BD-08	SHOULD track individual bicycles across frames within a single camera view	Should
BD-09	SHALL operate with acceptable accuracy under varying lighting conditions	Must
BD-10	SHOULD support model fine-tuning for cycling-specific scenarios	Could

Technical Considerations

Pre-trained YOLO models include "bicycle" class but may need fine-tuning for racing bikes with riders
Consider training on a custom dataset including frame boards and bib numbers
GPU acceleration essential: NVIDIA RTX 3060 or better recommended for 4 cameras

5.3. Module 3: Camera Fusion Module (CFM)

Purpose

Combine detections from multiple cameras to produce unified trigger events, avoiding duplicate triggers for the same cyclist crossing. For portable setups, detect camera movement and notify operators when recalibration is required.

Table 6. Requirements
ID	Requirement	Priority
CFM-01	SHALL provide a calibration workflow to establish camera positions relative to the finish line	Must
CFM-02	SHALL determine the spatial relationship between overlapping camera views	Must
CFM-03	SHALL merge detections from multiple cameras viewing the same finish line crossing	Must
CFM-04	SHALL assign a single timestamp to merged detections (earliest detection or configurable)	Must
CFM-05	SHALL handle non-overlapping camera views (e.g., approach camera + finish camera)	Should
CFM-06	SHALL tolerate camera time drift up to 100ms through synchronisation	Must
CFM-07	SHALL indicate which camera(s) contributed to each fused detection	Must
CFM-08	SHOULD support dynamic masking of obstructed regions	Should
CFM-09	SHALL detect camera movement beyond acceptable tolerance and alert operator	Must
CFM-10	SHALL continuously validate calibration against reference points	Must
CFM-11	SHALL support rapid field recalibration (target: <2 minutes per camera)	Must
CFM-12	SHOULD auto-correct for minor drift within tolerance (±2° rotation, ±5% translation)	Should

5.3.1. Camera Drift Detection

For portable pole/fence-mounted cameras, environmental factors (wind, vibration, accidental contact) can shift camera position during an event. Although pole and fence clamps provide better rigidity than tripods, each setup is unique and drift detection remains important.

Table 7. Mounting Characteristics
Mount Type	Stability	Drift Risk
Fence post clamp	Good — rigid attachment to fixed infrastructure	Low (unless fence itself moves)
Pole mount (dedicated)	Good — purpose-built stability	Low to Medium (pole flex in wind)
Tripod (fallback)	Moderate — susceptible to ground conditions	Medium to High

Figure 1. Drift Detection Strategy

Reference Point Selection

During calibration, the operator identifies 4-6 static reference points visible in each camera view:

Reference Type	Examples	Reliability
Ground markings	Finish line paint, lane dividers, distance markers	High
Fixed infrastructure	Barrier posts, fence corners, timing gantry edges	High
Temporary markers	Calibration targets placed for the event	Medium (can be moved)
Natural features	Road texture patterns, cracks, drain covers	Medium (lighting dependent)

Reference Type

Examples

Reliability

Ground markings

Finish line paint, lane dividers, distance markers

High

Fixed infrastructure

Barrier posts, fence corners, timing gantry edges

High

Temporary markers

Calibration targets placed for the event

Medium (can be moved)

Natural features

Road texture patterns, cracks, drain covers

Medium (lighting dependent)

Auto-Correction Mechanism

For minor drift within tolerance, the system applies a corrective homography transformation:

Detect current positions of reference points using template matching
Calculate transformation matrix between baseline and current positions
Apply inverse transformation to detection coordinates
Log correction magnitude and direction

Table 8. Operator Alert Levels
Level	Condition	System Response	Operator Action
INFO	Drift detected, auto-corrected	Log entry, continue operation	Review at convenience
WARNING	Approaching auto-correct limit	Audible alert, UI notification	Monitor; recalibrate at next opportunity
CRITICAL	Beyond auto-correct capability	Suspend camera, loud alert, UI banner	Immediate recalibration required

Figure 2. Recalibration Workflow (Field)

Figure 3. Calibration Process

5.4. Module 4a: Race Context Provider (RCP)

Purpose

Integrate with race administration software to provide scheduling context, enabling intelligent filtering and prioritisation throughout the system.

Table 9. Requirements
ID	Requirement	Priority
RCP-01	SHALL receive race schedule from administration software (start times, expected duration)	Must
RCP-02	SHALL maintain "no earlier than" constraint per participant based on scheduled start	Must
RCP-03	SHALL calculate expected race end time based on schedule and observed performance	Must
RCP-04	SHALL provide current race context (which race is active, time into race, expected remaining)	Must
RCP-05	SHALL identify participants eligible to cross at any given time	Must
RCP-06	SHALL detect when a race is effectively complete (bulk of participants finished)	Should
RCP-07	SHOULD support multiple concurrent races with different start times	Should
RCP-08	SHALL expose API for other modules to query participant eligibility	Must

Race Context Data Model

{
  "race_id": "race_2025_elite_men",
  "name": "Elite Men 50km",
  "scheduled_start": "2025-12-08T09:00:00Z",
  "actual_start": "2025-12-08T09:02:15Z",
  "expected_duration_minutes": 75,
  "laps": 10,
  "participant_count": 45,
  "status": "IN_PROGRESS",
  "participants": [
    {
      "bib_number": "42",
      "earliest_crossing": "2025-12-08T09:02:15Z",
      "expected_lap_time_seconds": 450
    }
  ]
}

Crossing Eligibility Filter

Before creating a detection task or attempting re-identification, verify the crossing is plausible:

Integration with Administration Software

The Race Context Provider should sync with your existing race administration system. Options:

Method	Description	Recommendation
REST API polling	Query administration software every 30-60 seconds for schedule updates	Good for loosely coupled systems
Webhook/push	Administration software notifies RCP of schedule changes	Better for real-time accuracy
Shared database	Direct read access to administration database	Fastest, but tighter coupling
File import	Load race schedule from exported file at event start	Simplest; manual update if changes occur

Method

Description

Recommendation

REST API polling

Query administration software every 30-60 seconds for schedule updates

Good for loosely coupled systems

Webhook/push

Administration software notifies RCP of schedule changes

Better for real-time accuracy

Shared database

Direct read access to administration database

Fastest, but tighter coupling

File import

Load race schedule from exported file at event start

Simplest; manual update if changes occur

5.5. Module 4b: Timing Data Adapter (TDA)

Purpose

Interface with the existing tag-server to receive trigger events and participant identification.

Table 10. Requirements
ID	Requirement	Priority
TDA-01	SHALL receive real-time triggers from the tag-server	Must
TDA-02	SHALL capture participant identifier (tag ID mapped to bib number) for each trigger	Must
TDA-03	SHALL capture precise timestamp for each trigger (millisecond precision minimum)	Must
TDA-04	SHALL connect to tag-server via MQTT (recommended) or WebSocket streaming	Must
TDA-05	SHALL normalise timestamps to a common time base with video streams	Must
TDA-06	SHALL maintain a buffer of recent triggers for correlation purposes (minimum 60 seconds)	Must
TDA-07	SHALL detect and flag tag-server disconnections within 5 seconds	Must
TDA-08	SHOULD support REST API polling as fallback when streaming unavailable	Should
TDA-09	SHOULD support import of timing data from file (for post-race analysis)	Should
TDA-10	SHALL acknowledge receipt of triggers to tag-server (if protocol supports)	Should

Figure 4. Integration Architecture

Protocol Recommendation: MQTT

MQTT is the recommended protocol for tag-server integration due to:

Low latency — Persistent connection with minimal overhead
Guaranteed delivery — QoS levels ensure no missed triggers
Scalability — Multiple subscribers without additional load on tag-server
Resilience — Automatic reconnection and session persistence
Decoupling — Vision system doesn’t affect existing timing software feed

5.6. Module 5: Trigger Correlator (TC)

Purpose

Match video-based detections with RFID timing triggers to identify gaps and build a unified crossing log. Adapt processing priority based on correlation success rate.

Table 11. Requirements
ID	Requirement	Priority
TC-01	SHALL correlate video detections with timing triggers within a configurable time window (default ±2 seconds)	Must
TC-02	SHALL classify each event as: matched (both sources), video-only, or timing-only	Must
TC-03	SHALL maintain a master trigger list combining all sources	Must
TC-04	SHALL record the source(s) for each trigger in the master list	Must
TC-05	SHALL flag "video-only" events as potential missed RFID reads	Must
TC-06	SHALL flag "timing-only" events as potential false reads or camera occlusion	Should
TC-07	SHALL support configurable correlation strategies (timestamp only, timestamp + lane position)	Should
TC-08	SHALL generate gap reports per source system	Must
TC-09	SHALL calculate rolling correlation success rate	Must
TC-10	SHALL adjust processing mode based on correlation success rate	Must
TC-11	SHALL deprioritise video identification when correlation is high	Should

5.6.1. Adaptive Processing Modes

The system operates in different modes based on how well RFID and video triggers are correlating. When RFID is working reliably, video identification is unnecessary overhead. When discrepancies occur, video becomes critical.

Table 12. Processing Modes
Mode	Trigger	Behaviour	Resource Usage
PASSIVE	Correlation rate >98% over last 5 minutes	Video detection runs but re-ID is skipped; frames stored for retrieval if needed later; minimal task creation	Low
NORMAL	Correlation rate 90-98%	Full pipeline active; re-ID runs on unmatched detections; tasks created for video-only events	Medium
ALERT	Correlation rate <90% OR >3 consecutive misses	Aggressive re-ID on all detections; operator notified of degraded RFID; all gaps prioritised	High
CRITICAL	RFID feed lost OR correlation rate <70%	Video becomes primary source; all detections generate tasks; operator alerted to investigate RFID	Maximum

Figure 5. Mode Transition Logic

Correlation Rate Calculation

Rolling window: Last 5 minutes OR last 50 RFID triggers (whichever is smaller)

correlation_rate = matched_triggers / total_rfid_triggers

Where:
- matched_triggers = RFID triggers with corresponding video detection within ±2 sec
- total_rfid_triggers = All RFID triggers in window

Mode-Specific Behaviour

PASSIVE Mode (Correlation >98%)

Video detection continues (for audit trail and potential later review)
Re-identification engine is not invoked — saves GPU cycles
Frames are archived with crossing timestamp for retrieval if needed
No tasks created for well-correlated crossings
Operator dashboard shows "RFID Primary — Video Standby"

NORMAL Mode (Correlation 90-98%)

Full pipeline operational
Re-ID runs only on video-only or low-confidence detections
Tasks created for discrepancies requiring review
Operator dashboard shows active correlation statistics

ALERT Mode (Correlation <90%)

Re-ID runs on all detections (not just unmatched)
Builds comprehensive visual identity gallery
All video-only events immediately queued as high-priority tasks
Audible alert to operator: "RFID correlation degraded"
System prepares for potential full video reliance

CRITICAL Mode (RFID lost or <70%)

Video becomes the primary timing source
Every detection generates a task (identification required)
Operator receives urgent notification: "RFID failure — manual verification required"
System logs all detections for post-race reconciliation
Consider pausing race if safe to do so

Operator Mode Override

Operators can manually set processing mode:

Force ALERT mode before anticipated sprint finish
Force PASSIVE mode if false video detections are overwhelming the queue
Lock mode to prevent automatic transitions during critical race phases

Figure 6. Correlation Logic

5.7. Module 6: Visual Re-Identification Engine (VRIE)

Purpose

Assign consistent visual identifiers to cyclists across multiple crossings, enabling tracking without relying solely on RFID data.

Table 13. Requirements
ID	Requirement	Priority
VRI-01	SHALL extract visual features from detected cyclists (appearance embedding)	Must
VRI-02	SHALL assign a temporary visual identifier (VID) to each unique cyclist appearance	Must
VRI-03	SHALL match new detections against existing VIDs with confidence scoring	Must
VRI-04	SHALL link VIDs to participant identifiers when RFID data is available	Must
VRI-05	SHALL maintain a gallery of reference images per VID for operator review	Must
VRI-06	SHOULD utilise jersey colour, helmet colour, and bicycle colour as features	Should
VRI-07	SHOULD support manual linking of VIDs to participants by operator	Should
VRI-08	SHALL handle appearance variations due to lighting changes	Must
VRI-09	COULD attempt OCR on frame boards or bib numbers	Could

Technical Considerations

Person re-identification models (e.g., OSNet, TransReID) can be adapted for cyclists
Feature extraction should focus on stable attributes: kit colours, bike frame, helmet
OCR on frame boards is challenging due to motion blur and angle; treat as enhancement

5.8. Module 7: Lap Predictor (LP)

Purpose

Predict expected crossing times based on historical lap data to assist matching and highlight anomalies.

Table 14. Requirements
ID	Requirement	Priority
LP-01	SHALL calculate average lap time per participant from confirmed crossings	Must
LP-02	SHALL predict expected crossing time for next lap (with confidence interval)	Must
LP-03	SHALL account for typical lap time degradation over race duration	Should
LP-04	SHALL flag detections that fall within expected windows for unmatched participants	Must
LP-05	SHALL provide probability scores for candidate matches based on timing predictions	Must
LP-06	SHALL detect anomalies (e.g., lap time <50% or >150% of average)	Should
LP-07	SHOULD incorporate race context (lead group pace, weather conditions)	Could

Prediction Model

\$T_{expected}(n+1) = T_{last} + \bar{L} \times (1 + \delta_{degradation})\$

Where:

\$T_{expected}(n+1)\$ = Expected time for lap n+1
\$T_{last}\$ = Timestamp of last confirmed crossing
\$\bar{L}\$ = Mean lap time for this participant
\$\delta_{degradation}\$ = Degradation factor (typically 0.5-2% per lap)

5.9. Module 8: Task Manager ™

Purpose

Maintain a prioritised queue of human tasks for resolving discrepancies. Adapt task creation and prioritisation based on current processing mode and race context.

Table 15. Requirements
ID	Requirement	Priority
TM-01	SHALL create tasks for video-only detections requiring resolution (when in NORMAL or higher mode)	Must
TM-02	SHALL prioritise tasks by: race position impact, time elapsed, confidence level, processing mode	Must
TM-03	SHALL assign tasks to operators (manual or automatic)	Should
TM-04	SHALL track task status: pending, in-progress, resolved, deferred	Must
TM-05	SHALL record resolution outcome and operator notes	Must
TM-06	SHALL provide task filtering by type, priority, status, and race	Must
TM-07	SHALL support bulk operations (e.g., dismiss all low-confidence tasks)	Should
TM-08	SHALL maintain audit trail of all task state changes	Must
TM-09	SHALL integrate with Review Console for task execution	Must
TM-10	SHALL suppress task creation in PASSIVE mode (archive for later review only)	Must
TM-11	SHALL escalate all tasks to high priority when in ALERT or CRITICAL mode	Must
TM-12	SHALL provide post-race batch review mode for deferred tasks	Should

5.9.1. Task Creation by Processing Mode

Mode	Task Creation	Rationale
PASSIVE	No tasks created; detections archived with frames for potential later review	RFID is reliable; video serves as backup audit trail only
NORMAL	Tasks created for video-only detections and timing anomalies	Standard operation; discrepancies require attention
ALERT	Tasks created immediately with elevated priority; operator notified	RFID degraded; video identification becomes important
CRITICAL	All detections create tasks; urgent notification to operator	RFID failed; manual verification required for all crossings

Mode

Task Creation

Rationale

PASSIVE

No tasks created; detections archived with frames for potential later review

RFID is reliable; video serves as backup audit trail only

NORMAL

Tasks created for video-only detections and timing anomalies

Standard operation; discrepancies require attention

ALERT

Tasks created immediately with elevated priority; operator notified

RFID degraded; video identification becomes important

CRITICAL

All detections create tasks; urgent notification to operator

RFID failed; manual verification required for all crossings

5.9.2. Task Prioritisation Algorithm

Tasks are scored based on multiple factors:

priority_score =
    base_priority(task_type)
  + mode_modifier(current_mode)
  + race_position_impact(estimated_position)
  + time_urgency(time_since_detection)
  + confidence_modifier(detection_confidence)

Table 16. Priority Score Components
Component	Calculation	Range
Base priority	VIDEO_ONLY=50, TIMING_ANOMALY=40, REIDENTIFICATION=30	30-50
Mode modifier	PASSIVE=0, NORMAL=0, ALERT=+30, CRITICAL=+50	0-50
Race position impact	Potential podium=+25, Top 10=+15, Mid-pack=+5	0-25
Time urgency	+1 per minute since detection (max +20)	0-20
Confidence modifier	High confidence=-10, Low confidence=+10	−10 to +10

Example Scenarios

Scenario A: PASSIVE mode, video-only detection

No task created
Detection and frames archived
Available for post-race review if needed

Scenario B: NORMAL mode, video-only detection, mid-pack rider

Base: 50 + Mode: 0 + Position: 5 + Time: 0 + Confidence: 0 = 55
Task created, queued at normal priority

Scenario C: ALERT mode, video-only detection, potential podium

Base: 50 + Mode: 30 + Position: 25 + Time: 0 + Confidence: 0 = 105
Task created immediately, high priority, operator notified

5.9.3. Post-Race Review Mode

After the race concludes, operators can review archived detections from PASSIVE mode:

System presents archived video-only detections from the race
Operator can bulk-dismiss obviously false detections
Remaining items can be promoted to tasks for resolution
Particularly useful for verifying results before official publication

5.10. Module 9: Review Console (RC)

Purpose

Operator interface for reviewing flagged events and resolving discrepancies.

Table 17. Requirements
ID	Requirement	Priority
RC-01	SHALL display video frames before, at, and after each flagged detection	Must
RC-02	SHALL show all available data for the detection (timestamp, confidence, camera source)	Must
RC-03	SHALL display candidate participant matches with probability scores	Must
RC-04	SHALL show reference frames from other laps for candidate participants	Must
RC-05	SHALL allow operator to confirm, reject, or reassign participant identity	Must
RC-06	SHALL support playback of video segment around detection	Must
RC-07	SHALL allow manual timestamp adjustment if detection timing is incorrect	Should
RC-08	SHALL provide keyboard shortcuts for rapid task processing	Should
RC-09	SHALL show race context (current standings, lap counts) during review	Should
RC-10	SHALL support side-by-side comparison of detection frames with reference images	Must

Figure 7. Operator Workflow

6. Non-Functional Requirements

6.1. Performance

ID	Requirement	Target
NFR-P01	Video processing latency (frame to detection)	< 200ms per frame
NFR-P02	Trigger correlation latency	< 500ms from detection
NFR-P03	Task creation latency	< 1 second from gap identification
NFR-P04	System throughput — per race	Support 300 participants, 4 cameras, 10 crossings/5 sec peak burst
NFR-P05	System throughput — per event day	Support 2000 total participants across multiple races
NFR-P06	Frame retrieval for review	< 2 seconds for any historical frame within current event
NFR-P07	Mode transition latency	< 5 seconds from trigger condition to mode change

Requirement

Target

NFR-P01

Video processing latency (frame to detection)

< 200ms per frame

NFR-P02

Trigger correlation latency

< 500ms from detection

NFR-P03

Task creation latency

< 1 second from gap identification

NFR-P04

System throughput — per race

Support 300 participants, 4 cameras, 10 crossings/5 sec peak burst

NFR-P05

System throughput — per event day

Support 2000 total participants across multiple races

NFR-P06

Frame retrieval for review

< 2 seconds for any historical frame within current event

NFR-P07

Mode transition latency

< 5 seconds from trigger condition to mode change

6.2. Reliability

ID	Requirement	Target
NFR-R01	System availability during event	99.5% uptime
NFR-R02	Data persistence	Zero data loss for timing events and archived frames
NFR-R03	Recovery from component failure	< 30 seconds automatic recovery
NFR-R04	Graceful degradation	Continue timing-only operation if vision fails
NFR-R05	RFID failure detection	Detect feed loss within 10 seconds, transition to CRITICAL mode

Requirement

Target

NFR-R01

System availability during event

99.5% uptime

NFR-R02

Data persistence

Zero data loss for timing events and archived frames

NFR-R03

Recovery from component failure

< 30 seconds automatic recovery

NFR-R04

Graceful degradation

Continue timing-only operation if vision fails

NFR-R05

RFID failure detection

Detect feed loss within 10 seconds, transition to CRITICAL mode

6.3. Scalability

ID	Requirement	Target
NFR-S01	Camera count	Support 2-8 cameras per finish line
NFR-S02	Participants per race	Up to 300 concurrent participants
NFR-S03	Participants per event day	Up to 2000 across all races
NFR-S04	Concurrent races	Support 2 concurrent races (e.g., overlapping categories)
NFR-S05	Historical storage	Retain event data for 90 days minimum; archive capability for full season

Requirement

Target

NFR-S01

Camera count

Support 2-8 cameras per finish line

NFR-S02

Participants per race

Up to 300 concurrent participants

NFR-S03

Participants per event day

Up to 2000 across all races

NFR-S04

Concurrent races

Support 2 concurrent races (e.g., overlapping categories)

NFR-S05

Historical storage

Retain event data for 90 days minimum; archive capability for full season

6.4. Usability

ID	Requirement	Target
NFR-U01	Operator training time	< 2 hours for proficient use
NFR-U02	Task resolution rate	Experienced operator: 30 tasks/hour
NFR-U03	False positive rate (NORMAL mode)	< 20% of flagged events should be false positives
NFR-U04	PASSIVE mode task suppression	>95% of crossings handled without operator intervention when RFID reliable
NFR-U05	Setup time (field)	< 30 minutes from equipment arrival to system operational
NFR-U06	Recalibration time (single camera)	< 2 minutes via tablet/mobile interface

Requirement

Target

NFR-U01

Operator training time

< 2 hours for proficient use

NFR-U02

Task resolution rate

Experienced operator: 30 tasks/hour

NFR-U03

False positive rate (NORMAL mode)

< 20% of flagged events should be false positives

NFR-U04

PASSIVE mode task suppression

>95% of crossings handled without operator intervention when RFID reliable

NFR-U05

Setup time (field)

< 30 minutes from equipment arrival to system operational

NFR-U06

Recalibration time (single camera)

< 2 minutes via tablet/mobile interface

7. Data Model

7.1. Core Entities

7.2. Enumeration Values

Crossing Source

RFID_ONLY - Detected by timing system only
VIDEO_ONLY - Detected by vision system only
BOTH - Confirmed by both systems
MANUAL - Manually entered by operator

Crossing Status

CONFIRMED - Verified crossing with participant ID
PENDING_REVIEW - Awaiting operator verification
UNIDENTIFIED - Valid crossing, participant unknown
REJECTED - Determined to be false positive

Task Status

PENDING - Awaiting assignment
IN_PROGRESS - Currently being reviewed
RESOLVED - Completed with outcome
DEFERRED - Postponed for later review

8. Tag-Server Integration

Since you have developed and control the tag-server, this provides significant flexibility for integration. This section outlines recommended extensions to the tag-server to optimise integration with the Vision Timing Augmentation System.

8.1. Recommended Tag-Server Extensions

MQTT Publisher

If not already implemented, add an MQTT publisher that broadcasts crossing events to a configurable broker. This allows the Vision system to subscribe without any changes to existing timing software integrations.

# Conceptual implementation
import paho.mqtt.client as mqtt

class MQTTPublisher:
    def __init__(self, broker_host, broker_port=1883):
        self.client = mqtt.Client()
        self.client.connect(broker_host, broker_port)

    def publish_crossing(self, event_id, crossing):
        topic = f"timing/{event_id}/crossings"
        payload = json.dumps({
            "timestamp": crossing.timestamp.isoformat(),
            "tag_id": crossing.tag_id,
            "bib_number": crossing.bib_number,
            "reader_id": crossing.reader_id,
            "signal_strength": crossing.rssi,
            "read_count": crossing.consolidation_count,
            "sequence": crossing.sequence_number
        })
        self.client.publish(topic, payload, qos=1)

Enhanced Crossing Metadata

The RFID sports timing hardware performs signal strength filtering and reports only the strongest reading per crossing. This means the tag-server receives clean, consolidated data rather than raw reads.

Available metadata from tag-server (confirm which fields your hardware provides):

Field Description Availability

Field	Description	Availability
`timestamp`	Precise crossing time from RFID hardware	Always
`tag_id`	Unique identifier of the RFID tag	Always
`bib_number`	Participant number (from tag mapping)	Always
`reader_id`	Which reader/timing point generated the crossing	Likely
`sequence`	Monotonic sequence number for ordering	Recommended to add

timestamp

Precise crossing time from RFID hardware

Always

tag_id

Unique identifier of the RFID tag

Always

bib_number

Participant number (from tag mapping)

Always

reader_id

Which reader/timing point generated the crossing

Likely

sequence

Monotonic sequence number for ordering

Recommended to add

Since the RFID hardware already filters to the strongest signal, fields like signal_strength and read_count may not be available. The pre-filtered data is actually advantageous — it reduces noise and provides cleaner input for correlation.

Bidirectional Communication

Consider adding a channel for the Vision system to query or update the tag-server:

Endpoint Purpose

Endpoint	Purpose
`GET /api/participants?event_id={id}`	Retrieve participant list with bib-to-tag mappings
`GET /api/crossings?event_id={id}&bib={bib}`	Retrieve all crossings for a specific participant
`POST /api/crossings`	Submit a manually-added crossing from Vision system resolution
`GET /api/health`	System health check for monitoring

GET /api/participants?event_id={id}

Retrieve participant list with bib-to-tag mappings

GET /api/crossings?event_id={id}&bib={bib}

Retrieve all crossings for a specific participant

POST /api/crossings

Submit a manually-added crossing from Vision system resolution

GET /api/health

System health check for monitoring

8.2. Integration Sequence

8.3. Event Synchronisation

The tag-server likely maintains the authoritative list of participants and their tag assignments. The Vision system should synchronise this data at event start and periodically during the event.

Figure 8. Synchronisation Flow

9. Technology Stack

9.1. Recommended Components

Layer	Technology	Rationale
Video Processing	Python + OpenCV + FFmpeg	Mature ecosystem, hardware acceleration support
Object Detection	YOLOv8 (Ultralytics) or YOLOv9	State-of-the-art accuracy, good speed, active development
Deep Learning Runtime	ONNX Runtime with CUDA/TensorRT	Optimised inference, vendor-neutral
Re-identification	PyTorch + torchreid or fast-reid	Pre-trained models available, customisable
Message Broker	Eclipse Mosquitto (MQTT) or EMQX	Lightweight, reliable delivery, easy integration with tag-server
Event Streaming	Redis Streams	Low-latency internal event streaming between modules
Database	PostgreSQL with pgvector extension	Robust, supports vector similarity search for re-ID
API Layer	FastAPI (Python)	High performance, async support, auto-documentation
Operator UI	React or Vue.js with TypeScript	Component-based, responsive, good video support
Deployment	Docker + Docker Compose	Portable, consistent environment, easy updates

Layer

Technology

Rationale

Video Processing

Python + OpenCV + FFmpeg

Mature ecosystem, hardware acceleration support

Object Detection

YOLOv8 (Ultralytics) or YOLOv9

State-of-the-art accuracy, good speed, active development

Deep Learning Runtime

ONNX Runtime with CUDA/TensorRT

Optimised inference, vendor-neutral

Re-identification

PyTorch + torchreid or fast-reid

Pre-trained models available, customisable

Message Broker

Eclipse Mosquitto (MQTT) or EMQX

Lightweight, reliable delivery, easy integration with tag-server

Event Streaming

Redis Streams

Low-latency internal event streaming between modules

Database

PostgreSQL with pgvector extension

Robust, supports vector similarity search for re-ID

API Layer

FastAPI (Python)

High performance, async support, auto-documentation

Operator UI

React or Vue.js with TypeScript

Component-based, responsive, good video support

Deployment

Docker + Docker Compose

Portable, consistent environment, easy updates

9.2. Message Broker Architecture

9.3. Hardware Recommendations

Table 18. Processing Server (for 4 cameras at 30 fps)
Component	Minimum	Recommended
CPU	Intel i7-12700 / AMD Ryzen 7 5800X (8 cores)	Intel i9-13900 / AMD Ryzen 9 7900X (12+ cores)
GPU	NVIDIA RTX 3060 12GB	NVIDIA RTX 4070 12GB or RTX 4080
RAM	32 GB DDR4	64 GB DDR5
Storage (System)	500 GB NVMe SSD	1 TB NVMe SSD
Storage (Frame Archive)	2 TB SATA SSD or HDD	4 TB NVMe SSD (for faster retrieval)
Network	Gigabit Ethernet	10 GbE or dual Gigabit (bonded)

GPU Sizing Rationale

At 3MP resolution with YOLOv8-m (medium model):

Single RTX 3060: ~25-30 fps inference per stream
Single RTX 4070: ~40-50 fps inference per stream
For 4 cameras at 30 fps each = 120 fps total required

With batching optimisation, an RTX 4070 can handle 4 streams comfortably. For 8 cameras or future expansion, consider RTX 4080/4090 or dual GPUs.

Table 19. Crossing Rate Analysis
Scenario	Rate	Detection Requirement	Margin
Sprint finish (peak burst)	10 crossings / 5 sec = 2/sec	Detect 2 bicycles per frame at 30 fps	Comfortable — YOLO handles 50+ objects/frame
Sustained bunch crossing	50 crossings / 15 sec = 3.3/sec	Detect 3-4 bicycles per frame	Comfortable
Busy period average	300 crossings / 4 min = 1.25/sec	Detect 1-2 bicycles per frame	Very comfortable

Critical Insight: Bunch Detection

During sprint finishes, multiple cyclists cross nearly simultaneously. The challenge is not detection speed but tracking identity through the crossing zone. At 2 crossings/second with 30 fps video, each cyclist is visible for approximately 15-20 frames (assuming ~0.5 second transit through zone). This provides adequate frames for:

Confident bicycle detection (multiple frame confirmation)
Object tracking assignment (ByteTrack/BoT-SORT)
Feature extraction for re-identification

Figure 9. Recommended Processing Strategy

The peak burst rate of 2 crossings/second is well within system capacity. The primary challenge during sprint finishes is maintaining distinct track IDs for closely-spaced cyclists, not raw detection throughput.

Table 20. Event Scale
Parameter	Typical Value
Participants per race	50-300
Total participants per event day	Up to 2000
Races per day	5-15
Laps per race	5-20
Crossings per day (maximum)	2000 participants × 10 avg laps = 20,000 crossings

Storage Calculation

Assuming we store key frames (not full video) for detected crossings:

~10 frames per crossing (before, during, after)
3MP JPEG at 80% quality ≈ 300 KB per frame
3 MB per crossing

Table 21. Per Event Day
Scenario	Crossings	Storage
Small event (500 participants, 8 laps avg)	4,000	12 GB
Medium event (1000 participants, 10 laps avg)	10,000	30 GB
Large event (2000 participants, 10 laps avg)	20,000	60 GB

Table 22. Retention and Total Storage
Retention Period	Storage Required
Single event day	60 GB (worst case)
30 days (4 events/month)	240 GB
90 days (12 events)	720 GB
Full season archive	2-4 TB

Recommendation: 2 TB NVMe SSD for active/recent events, with archival to HDD or cloud storage for historical data.

9.4. Time Synchronisation

Accurate time synchronisation is critical for correlating video detections with timing triggers. Your infrastructure provides excellent options for achieving sub-millisecond accuracy.

Table 23. Available Time Sources
Source	Description	Accuracy
Local NTP Server	Already deployed at events	1-10 ms typical
RFID Timing GPS	Built into timing system hardware	<1 ms (internal use)
Stratum 1 PTP/NTP Device (optional)	GPS-disciplined hardware clock with PTP and NTP output	<100 µs with PTP, <1 ms with NTP

Figure 10. Recommended Architecture

Configuration Options

Option A: Use Existing Local NTP (Simpler)

All devices sync to local NTP server
Expected accuracy: 1-10 ms between systems
Sufficient for ±2 second correlation window
No additional hardware required

Option B: Deploy Stratum 1 Device (Higher Accuracy)

GPS-disciplined Stratum 1 provides authoritative time
Use PTP for processing server (if NIC supports IEEE 1588)
Use NTP for NVR and other devices
Expected accuracy: <1 ms between systems
Enables tighter correlation window and more precise timestamps

Table 24. Synchronisation Requirements
System	Sync Method	Notes
Processing Server	NTP (or PTP if available)	Primary correlation engine; highest accuracy beneficial
Hikvision NVR	NTP	Frame timestamps from NVR metadata, not decode time
Tag Server	NTP	Should sync to same source as processing server
RFID Hardware	Internal GPS	Provides authoritative crossing timestamps; already accurate

Validation Procedure

Before each event, verify synchronisation:

# On processing server
$ chronyc sources -v
$ chronyc tracking

# Check offset is <10ms (ideally <1ms)
# Check NVR time via ISAPI or web interface
# Compare tag-server timestamp with server clock

Correlation Window Sizing

The correlation window (time tolerance for matching video and RFID triggers) should be set based on synchronisation accuracy:

Sync Accuracy	Recommended Window	Notes
<1 ms (PTP)	±500 ms	Tight matching, fewer false correlations
1-10 ms (NTP)	±1 second	Default; accounts for typical NTP jitter
10-50 ms (poor NTP)	±2 seconds	Conservative; may increase false matches
Unknown/unsynchronised	±3 seconds	Emergency fallback only; verify sync ASAP

Sync Accuracy

Recommended Window

Notes

<1 ms (PTP)

±500 ms

Tight matching, fewer false correlations

1-10 ms (NTP)

±1 second

Default; accounts for typical NTP jitter

10-50 ms (poor NTP)

±2 seconds

Conservative; may increase false matches

Unknown/unsynchronised

±3 seconds

Emergency fallback only; verify sync ASAP

10. Potential Issues and Mitigations

10.1. Technical Risks

Risk	Description	Mitigation	Severity
R01	Camera occlusion during peloton crossings	Multiple camera angles, use timing system as primary during bunch finishes	High
R02	Insufficient detection accuracy in poor lighting	IR-capable cameras, model fine-tuning on low-light data, pre-event lighting assessment	Medium
R03	Video stream latency causing correlation failures	Configurable correlation window, NTP synchronisation, timestamp buffering	Medium
R04	Re-identification failures for similar kit/bikes	Multiple feature extraction, operator override capability, don’t rely solely on re-ID	Medium
R05	Network bandwidth saturation	H.265 compression, frame rate reduction, dedicated network segment	Medium
R06	GPU memory exhaustion with multiple streams	Batch processing, model quantisation (FP16/INT8), queue management	Medium
R07	Timing system integration complexity	Modular adapter design, file-based fallback, early integration testing	High
R08	Camera movement during event (wind, accidental contact)	Continuous drift detection with reference points, auto-correction for minor drift, immediate alerts for significant movement	High
R09	Tripod instability on uneven ground	Use weighted tripods, sandbags, or ground stakes; pre-event stability check	Medium
R10	Calibration loss between events	Store calibration profiles per venue; quick recalibration workflow; consider fixed mounting points at regular venues	Low

Risk

Description

Mitigation

Severity

R01

Camera occlusion during peloton crossings

Multiple camera angles, use timing system as primary during bunch finishes

High

R02

Insufficient detection accuracy in poor lighting

IR-capable cameras, model fine-tuning on low-light data, pre-event lighting assessment

Medium

R03

Video stream latency causing correlation failures

Configurable correlation window, NTP synchronisation, timestamp buffering

Medium

R04

Re-identification failures for similar kit/bikes

Multiple feature extraction, operator override capability, don’t rely solely on re-ID

Medium

R05

Network bandwidth saturation

H.265 compression, frame rate reduction, dedicated network segment

Medium

R06

GPU memory exhaustion with multiple streams

Batch processing, model quantisation (FP16/INT8), queue management

Medium

R07

Timing system integration complexity

Modular adapter design, file-based fallback, early integration testing

High

R08

Camera movement during event (wind, accidental contact)

Continuous drift detection with reference points, auto-correction for minor drift, immediate alerts for significant movement

High

R09

Tripod instability on uneven ground

Use weighted tripods, sandbags, or ground stakes; pre-event stability check

Medium

R10

Calibration loss between events

Store calibration profiles per venue; quick recalibration workflow; consider fixed mounting points at regular venues

Low

10.2. Operational Risks

Risk	Description	Mitigation	Severity
R11	Operator overwhelmed by task volume during sprint finish	Priority-based queuing, bulk dismiss for low-confidence, realistic throughput expectations; defer non-critical tasks until after race	High
R12	Calibration drift during event	Continuous reference point monitoring, automatic drift detection and alerting, rapid field recalibration workflow	Medium
R13	Over-reliance on vision system	Clear messaging that vision augments (not replaces) RFID, maintain manual processes	Medium
R14	Power or hardware failure	UPS for critical components, graceful degradation to timing-only mode	Medium
R15	Setup time pressure	Streamlined calibration workflow, pre-configured camera profiles, checklist-driven setup procedure	Medium
R16	Adverse weather affecting cameras	Weather covers for tripods, lens hoods, hydrophobic lens coatings; contingency for rain delays	Low

Risk

Description

Mitigation

Severity

R11

Operator overwhelmed by task volume during sprint finish

Priority-based queuing, bulk dismiss for low-confidence, realistic throughput expectations; defer non-critical tasks until after race

High

R12

Calibration drift during event

Continuous reference point monitoring, automatic drift detection and alerting, rapid field recalibration workflow

Medium

R13

Over-reliance on vision system

Clear messaging that vision augments (not replaces) RFID, maintain manual processes

Medium

R14

Power or hardware failure

UPS for critical components, graceful degradation to timing-only mode

Medium

R15

Setup time pressure

Streamlined calibration workflow, pre-configured camera profiles, checklist-driven setup procedure

Medium

R16

Adverse weather affecting cameras

Weather covers for tripods, lens hoods, hydrophobic lens coatings; contingency for rain delays

Low

10.3. Issues with Original Proposal

Area	Concern and Recommendation
OCR on frame boards	Motion blur and oblique angles make OCR unreliable. Recommendation: Treat OCR as a "nice to have" enhancement, not a core identification method. Focus on visual re-identification using whole-person appearance features.
Real-time identification requirement	Expecting real-time participant identification from video alone is ambitious. Recommendation: Design for post-crossing resolution workflow; real-time correlation is feasible, but positive identification may require operator input.
Single trigger per crossing	Assuming cameras won’t generate multiple triggers is optimistic, especially with tracking jitter. Recommendation: Implement debouncing with configurable time window (e.g., 1 second) per camera before fusion.
"Same frequency per lap" assumption	Lap times can vary significantly (breakaways, mechanicals, fatigue, tactics). Recommendation: Use prediction with wide confidence intervals; don’t over-constrain matching based on expected times.
Multi-camera fusion complexity	Homography-based fusion requires careful calibration and assumes a flat ground plane. Recommendation: Start with simpler timestamp-based fusion; add spatial fusion as enhancement.
Arbitrary visual ID stability	Visual embeddings can drift or fail to match across lighting changes. Recommendation: Use visual ID as supporting evidence, not authoritative; always allow operator override.

Area

Concern and Recommendation

OCR on frame boards

Motion blur and oblique angles make OCR unreliable. Recommendation: Treat OCR as a "nice to have" enhancement, not a core identification method. Focus on visual re-identification using whole-person appearance features.

Real-time identification requirement

Expecting real-time participant identification from video alone is ambitious. Recommendation: Design for post-crossing resolution workflow; real-time correlation is feasible, but positive identification may require operator input.

Single trigger per crossing

Assuming cameras won’t generate multiple triggers is optimistic, especially with tracking jitter. Recommendation: Implement debouncing with configurable time window (e.g., 1 second) per camera before fusion.

"Same frequency per lap" assumption

Lap times can vary significantly (breakaways, mechanicals, fatigue, tactics). Recommendation: Use prediction with wide confidence intervals; don’t over-constrain matching based on expected times.

Multi-camera fusion complexity

Homography-based fusion requires careful calibration and assumes a flat ground plane. Recommendation: Start with simpler timestamp-based fusion; add spatial fusion as enhancement.

Arbitrary visual ID stability

Visual embeddings can drift or fail to match across lighting changes. Recommendation: Use visual ID as supporting evidence, not authoritative; always allow operator override.

11. Suggested Improvements

11.1. Priority 1: Core Functionality

Add confidence thresholds throughout the pipeline - Don’t create tasks for very low-confidence detections; configure thresholds per module.
Implement a "bunch crossing" mode - When many cyclists cross simultaneously, switch to a simplified workflow that focuses on count verification rather than individual identification.
Pre-event model validation - Include a test/calibration phase before each event where known participants make test crossings to verify detection and camera setup.
Offline processing capability - Support post-race batch processing of video for events where real-time processing isn’t critical or hardware is limited.

11.2. Priority 2: Enhanced Accuracy

Multi-frame detection confirmation - Require detection in N consecutive frames before generating a trigger (reduces false positives from momentary misclassifications).
Tracking-based triggers - Use object tracking (e.g., ByteTrack, BoT-SORT) within each camera view to generate a single trigger per tracked object crossing the line, rather than per-frame detections.
Direction filtering - Only trigger for bicycles moving in the expected direction (towards/across finish line), filtering out cyclists warming down or crossing backwards.

11.3. Priority 3: Operational Efficiency

Configurable automation levels - Allow events to choose: fully manual review, semi-automated (high-confidence auto-accept), or post-race batch mode.
Mobile operator interface - Tablet-friendly UI for officials who may not be at a desk.
Integration with results publication - API to push corrections to existing results systems.

11.4. Priority 4: Future Enhancements

Multi-finish-line support - For stage races or events with intermediate timing points.
Cloud processing option - Offload GPU-intensive processing to cloud infrastructure for smaller events without dedicated hardware.
Machine learning feedback loop - Use confirmed resolutions to improve re-identification model over time.

12. Deployment Architecture

13. Testing Strategy

13.1. Test Environment

A realistic test environment is essential for validating the system before deployment at live events.

Table 25. Test Environment Components
Component	Approach
Video Streams	Record sample footage from actual events; replay via RTSP simulator
Timing Data	Export historical crossing data from tag-server; replay with timestamps adjusted
Synchronisation	Verify correlation works correctly with recorded data before live testing
Ground Truth	Manually annotate test footage with actual crossings for accuracy measurement

Test Data Requirements

Minimum 3 events with different conditions (lighting, participant density)
Include examples of: bunch crossings, solo breakaways, missed RFID reads
Annotate ground truth for at least 500 crossings
Include edge cases: obstructed cameras, similar kit colours, mechanical incidents

13.2. Accuracy Metrics

Table 26. Detection Accuracy
Metric	Definition	Target
Recall (Sensitivity)	Crossings detected / Actual crossings	> 95%
Precision	True crossings / All detections	> 85%
F1 Score	Harmonic mean of precision and recall	> 90%

Table 27. Correlation Accuracy
Metric	Definition	Target
Match Rate	Correctly correlated pairs / Total RFID triggers	> 98%
False Gap Rate	False video-only detections / Total video-only	< 15%
Missed Gap Rate	Undetected actual RFID misses / Total RFID misses	< 10%

Table 28. Re-identification Accuracy
Metric	Definition	Target
Rank-1 Accuracy	Correct match is top candidate	> 70%
Rank-5 Accuracy	Correct match in top 5 candidates	> 90%

13.3. Test Scenarios

Scenario 1: Normal Operation

50 participants completing 10 laps each
RFID read rate: 99%
Expected: ~5 video-only detections flagged for review
Validate: Correct gap detection and task creation

Scenario 2: Bunch Finish

30 participants crossing within 10 seconds
Some RFID collisions causing missed reads
Expected: Multiple video detections, operator can identify by position/appearance
Validate: System handles high-density crossings without crashing

Scenario 3: Camera Occlusion

Single camera blocked for 30 seconds
Participants cross during occlusion
Expected: Timing-only detections logged, no false gaps created
Validate: Multi-camera fusion compensates, or graceful degradation

Scenario 4: Poor Lighting

Dawn/dusk footage with low contrast
Expected: Detection confidence lower but still functional
Validate: System adjusts thresholds or flags low-confidence detections

13.4. Pre-Event Validation Checklist

Before each event, the following checks should be completed:

Table 29. Equipment Setup
#	Check	Status
1	Tripods positioned with clear view of finish line, weighted/secured
2	Cameras mounted and connected to NVR
3	Camera streams accessible and decoding correctly on processing server
4	Network connectivity verified between all components

Table 30. Calibration
#	Check	Status
5	Each camera calibrated with finish line zone marked
6	Reference points identified and stored for drift detection (4-6 per camera)
7	Multi-camera fusion verified (if overlapping views)
8	Test crossing detected correctly in finish zone

Table 31. Integration
#	Check	Status
9	Tag-server MQTT/WebSocket connection established
10	Participant list synchronised from tag-server
11	Time synchronisation verified (<10ms drift across all systems)
12	Test crossing detected by both RFID and video, correctly correlated

Table 32. Operator Readiness
#	Check	Status
13	Operator console accessible and displaying real-time status
14	Task queue empty or containing only test items
15	Frame retrieval working for test crossing timestamp
16	Alert sounds/notifications audible at operator position
17	Database backup configured and tested

Table 33. Final Verification
#	Check	Status
18	Perform 2-3 full test crossings with known participants
19	Verify detection, correlation, and task workflow end-to-end
20	Confirm camera drift detection baseline is stable
21	Brief all operators on alert levels and recalibration procedure

14. Implementation Phases

14.1. Phase 1: Foundation (4-6 weeks)

Deliverables

Video Stream Adapter with Hikvision integration
Basic Bicycle Detector with single camera
Timing Data Adapter for your specific system
Simple Trigger Correlator (timestamp-based)
Minimal operator UI showing correlated events

Success Criteria

Successfully ingest video from NVR
Detect bicycles with >80% recall on test footage
Correlate timing and video triggers within 2-second window

14.2. Phase 2: Multi-Camera & Tasks (4-6 weeks)

Deliverables

Camera Fusion Module with calibration UI
Task Manager with prioritisation
Review Console with frame display
Gap analysis and reporting

Success Criteria

Process 4 cameras simultaneously
Generate tasks for video-only detections
Operator can resolve tasks and update records

14.3. Phase 3: Intelligence (6-8 weeks)

Deliverables

Visual Re-Identification Engine
Lap Predictor with confidence scoring
Enhanced Review Console with candidate matching
Reference frame retrieval

Success Criteria

Consistent visual ID assignment (>70% accuracy across laps)
Lap predictions within 5% of actual for stable riders
Operators can use reference frames for identification

14.4. Phase 4: Hardening & Optimisation (4 weeks)

Deliverables

Performance optimisation for target hardware
Comprehensive error handling and recovery
Full audit logging
Documentation and operator training materials

Success Criteria

Meet all non-functional requirements
Successfully complete pilot event
Operator confidence in system reliability

15. Appendices

15.1. Appendix A: Glossary

Term

Definition

Bib Number

Race number worn by participant, used for identification

Correlation Rate

Percentage of RFID triggers that have a matching video detection within the time window

Crossing

A single instance of a participant passing over the finish line

Detection

A single identification of a bicycle in a video frame

Frame Board

Panel mounted on bicycle displaying participant’s race number

ISAPI

Hikvision’s Integration Service API for accessing NVR features programmatically

Lap

One complete circuit of the race course

NVR

Network Video Recorder - device that records IP camera footage

Peloton

Main group of cyclists in a race

Processing Mode

System operational state (PASSIVE, NORMAL, ALERT, CRITICAL) based on correlation success

RCP

Race Context Provider - module that integrates with race administration software

Re-ID

Re-identification - matching a person across different camera views or times

RFID

Radio-Frequency Identification - technology used for timing tags

Tag-Server

Custom middleware that consolidates RFID reads and provides streaming output

Trigger

An event indicating a finish line crossing from any source

VID

Visual Identifier - temporary ID assigned based on visual appearance

YOLO

"You Only Look Once" - family of real-time object detection models

15.2. Appendix B: Open Questions

Table 34. Answered
Question	Answer
Timing system protocol	Custom tag-server provides REST API, streaming (WebSocket), message broker, or MQTT
Camera resolution/frame rate	3MP colour at 30 or 60 fps
Peak crossing rate	10 crossings/5 sec burst, 50 crossings/15 sec sustained, 300 crossings/4 min average
Fixed or portable setup	Portable — pole/fence clamp mounts (more rigid than tripods); unique positions per event
Signal strength metadata	RFID hardware pre-filters to strongest signal; raw metadata not available from tag-server
Time synchronisation	Local NTP available; timing system has GPS; option for Stratum 1 PTP/NTP hardware
Participant scale	Up to 300 per race, 2000 per event day across multiple races
Race scheduling	Administration software provides start times (no-earlier-than) and expected duration
NVR model	Hikvision DS-7600NI series (Pro)

Remaining Questions

What is the acceptable false-positive rate for operator review tasks?
Should the system support multiple simultaneous finish lines (e.g., criterium with start/finish separate from prime line)?
What is the interface to the race administration software? (REST API, database, file export?)
What timing software is downstream of the tag-server? Is there potential for direct integration with results publication?

Technical Clarifications Needed

What specific DS-7600 model variant? (Affects maximum concurrent playback streams)
What is the typical network infrastructure? (Dedicated switches, or shared with other event systems?)
What is the typical duration of individual races? (Affects frame archive sizing per race)
Are there mobile/tablet devices available for operators at the finish line?

15.3. Appendix C: References

YOLOv8 Documentation: https://docs.ultralytics.com/
Hikvision ISAPI Reference: (vendor documentation)
torchreid Library: https://github.com/KaiyangZhou/deep-person-reid
ByteTrack: https://github.com/ifzhang/ByteTrack
PostgreSQL pgvector: https://github.com/pgvector/pgvector