Smart-City-Überwachung: 4K PTZ, Edge-KI & 36-Kanal-NVR – Referenzlösung

Direct Answer

A smart city surveillance deployment is best understood as three separated roles inside one workflow. The PTZ camera at each urban node owns long-range optical sensing, situational awareness and the operator's ability to verify what is actually happening. The edge AI analytics device owns stream ingestion, algorithm execution and the hand-off of candidate events. The network video recorder (NVR) owns centralized recording, playback, retention and the evidence trail behind both of them. None of the three replaces another, and an AI alert is a prioritisation input, not a final operational decision.

In the reference configuration described here, the IR6 IR High Speed Dome Camera is used as the long-range optical and PTZ sensing node, the FTD-16CH AI BOX is used as the edge analytics and integration layer that consumes RTSP/ONVIF streams and exposes alerts through northbound interfaces, and the FTD-N3364 36CH AI Network Video Recorder is used as the centralized recording, playback and evidence layer.

• Conclusion — Use 4K PTZ cameras for coverage and verification, a separate edge AI analytics layer for detection and classification, and a separate NVR for centralized recording and evidence. Keep the three responsibilities distinct in the bill of materials, in the network design and in the acceptance test plan.
• Applicable conditions — District-scale or corridor-scale urban monitoring where fixed cameras cannot resolve the event of interest, where existing camera groups must be reused, and where the operation already runs (or is deploying) a VMS, a recorder, or both, that can accept external alerts.
• Validation limits — Detection, classification and identification performance depends on installation geometry, target size in pixels, lighting, weather, lens selection, codec settings and the algorithm configuration actually enabled on site. Recorder behaviour depends on the final camera list, the AI channel allocation mode and the selected storage. Site-specific validation is required before any performance figure is written into a contract or a public claim.

Scenario Definition

What the scenario covers

This reference solution describes a municipal or district authority operating a mixed urban monitoring footprint: signalised intersections and arterial approaches, one or more public squares or plaza areas, pedestrian-priority zones, and a transit interchange or transport hub. Video originates from cameras installed across several procurement cycles, so resolution, codec, firmware generation and management software are not uniform. A centralized recording and evidence point — an on-premise recorder, the control-room platform, or both — is assumed to exist somewhere behind those cameras.

The scenario assumes three practical tasks:

• Incident awareness — traffic incidents, stopped or obstructive vehicles, wrong-way movement, and blocked pedestrian or vehicle flows need to reach an operator while the event is still actionable.
• Aggregate monitoring — crowd density at plaza and interchange areas needs continuous, zone-based observation rather than an operator watching a wall of monitors.
• Record and review — when an event is confirmed, the operator needs usable video evidence: a recorded stream that can be located, played back and exported, not a thumbnail or a single alert line.

Operating conditions

• Environment — pole-top and gantry-mounted cameras exposed to direct sun, rain, dust, vibration from traffic, seasonal temperature extremes and lightning-induced surges on long outdoor cable runs.
• Lighting — full daylight through to unlit night operation on unlit approaches, with mixed headlight glare, street lighting and shop-front light spill.
• Network — a distributed access layer with aggregation back to a control room or an equipment room, usually over existing municipal fibre, licensed or unlicensed point-to-point radio backhaul, or a combination of both. The recorder and the analytics device sit at the protected end of that network, not on the pole.
• Recording and evidence — centralized recording with a defined retention period, mains power and ventilation at the recorder location, and storage sized from the recording resolution, codec and retention policy rather than from a nominal HDD count.
• Operations — an existing VMS or command-centre platform that must remain the system of record, with city staff who have limited tolerance for a second user interface.

What this scenario does not define

This document is a reusable reference configuration, not a description of a completed project. It deliberately contains no customer names, no site counts, no measured response times and no measured recognition rates. Every quantity in a real project — node count, camera count, recorded channel count, distance budget, storage volume, retention period and alert threshold — must be derived from the site survey and confirmed during commissioning. Where this article states a product capability, the value comes from the current Fengtaida product records listed in Sources and Verification Notes.

System Objective

The objective of the architecture is to convert a scattered camera estate into one prioritised operator workflow with a usable evidence trail, without discarding the cameras that are already installed.

1. One workflow, not one vendor — all monitored video and all analytics events should be reachable from the VMS or command-centre client the operators already use.
2. Detect broadly, verify optically — the analytics layer raises candidate events at aggregate level; the PTZ camera is the instrument the operator uses to confirm what the event actually is.
3. Record once, find it again — every stream that matters operationally is recorded into one centralized layer with a defined retention period. In this reference configuration that layer is an NVR specified for 36-channel 4K IP camera input, with four SATA 2.0 storage interfaces supporting up to 14TB each (the HDD model and capacity remain project variables), dual Gigabit Ethernet (2 × RJ45 10/100/1000Mbps) and ONVIF support, so that a confirmed event can be located, played back and exported instead of being reconstructed from memory.
4. Keep the alert proportional — analytics is configured per zone and per risk model, so that an alert rate the team cannot process does not degrade trust in the system.
5. Scale by design — analytics capacity, recorder channel count and storage bays, PoE or DC power budget, switch ports and backhaul bandwidth are planned as one system, so that adding nodes later does not require re-architecting the core.
6. Evidence-grade output — recording coverage, retention policy, playback expectation and export path are defined before go-live, not after the first incident review, and any recorder function that depends on the camera model is validated against the final camera list before it is quoted.

Two boundaries belong in the objective statement itself. First, analytics output is decision support: the system is allowed to be uncertain, and the workflow must carry that uncertainty to the operator rather than resolving it silently. Second, every performance target is a testable acceptance item: a distance, a channel count, a retention period or a detection task only becomes a commitment once a site acceptance test defines the scene, the target and the pass criterion.

Reference Architecture

The architecture follows a five-stage chain. Each stage has one owner, one interface and one verifiable action; if a stage has no verification step, it is not designed yet.

Urban task definition → Sensing (IR6) → Analytics and integration (AI BOX) → Recording and evidence (FTD-N3364 NVR) → Response and verification (VMS / operator).

Transmission infrastructure — supporting sub-item, not a stage

Access switching and backhaul sit underneath stages 2 to 4 as a supporting sub-item rather than as a stage of their own. The relevant questions are how many streams share each uplink, at what resolution and codec, whether the camera group sits on the same VLAN as the analytics device and the recorder, and how the site behaves when a backhaul link degrades. Where fibre is impractical, a licensed or unlicensed point-to-point or point-to-multipoint radio link can carry the aggregated camera traffic back to the control room or to the equipment room that hosts the recorder; that link is specified as a separate infrastructure line item and validated against the measured stream load. Access switching, PoE or DC distribution and the backhaul link are project infrastructure decisions in this reference solution, not a product role.

Stages 2, 3 and 4 are deliberately separate products. A camera that performs well optically is not automatically the right place to run multi-algorithm inference, and an analytics appliance does not record and retain evidence. Keeping the roles separate also keeps the upgrade path open: the sensing layer can be extended node by node, the analytics layer can be expanded or re-configured without touching the camera estate, and the recording layer can be extended by adding a recorder or storage rather than by replacing the cameras.

Equipment Roles

The reference configuration uses six roles. Three of them are performance-critical hardware selections — the sensing camera, the edge analytics device and the recorder — and the rest are infrastructure and workflow decisions that must be made before the bill of materials is finalised.

Role 1 — IR6: long-range optical and PTZ sensing, and operator verification

The IR6 IR High Speed Dome Camera is the sensing and verification node. It is the device that must still produce a usable image at the far end of an approach, in darkness, and while the operator is steering it.

• 4K / 8MP imaging — 1/1.8" Sony CMOS sensor, 3840×2160 at up to 30fps, giving the pixel density needed to keep a distant target worth zooming into.
• Optical zoom for distance — 20x optical zoom (6.0–120 mm) per the product specification table. Some current Fengtaida merchandising fields describe the same camera as "up to 32x" total zoom; treat 20x optical as the conservative engineering basis and confirm the exact zoom configuration of the quoted SKU before specifying a distance budget (see Sources and Verification Notes).
• 500m IR range — infrared illumination specified for full-darkness coverage on unlit approaches and perimeters.
• PTZ positioning — 360° endless pan, up to 90° tilt, 250 presets and 8 patrol routes, which is what makes an operator verification step practical: a preset returns the camera to a known scene instead of relying on freehand navigation during an incident.
• Environmental and electrical envelope — IP66 and IK10, operating range −45°C to +70°C, TVS 6000V surge protection for exposed pole-top installation, and DC12V power with average consumption of 12W–40W.

Role boundary. The IR6 senses, illuminates, positions and streams. It is not positioned as the analytics engine and it is not positioned as the recording layer of this architecture. Any on-camera detection feature (for example human detection and auto-tracking, which appears in the current product records) is treated as a supporting function for the operator, not as a substitute for the site acceptance test.

Role 2 — FTD-16CH AI BOX: edge analytics and integration layer

The FTD-16CH AI BOX (FTD-AIBOX-C16) is the analytics and integration layer. It sits behind the cameras, decodes their streams, runs configurable algorithms and publishes events toward the VMS or third-party platform. It is an analytics and integration device: it is not the recorder described in Role 3, and "NVR" appears in its store tags only as an adjacent classification (see Sources and Verification Notes).

• Edge inference — 6 TOPS peak NPU performance, with a Cortex-A76 + Cortex-A55 8-core CPU at 2.4GHz, 8GB memory and 128GB eMMC.
• Channel capacity — 16 channels of 1080P video decoding and encoding, H.264/H.265, at 1080P@25FPS. Current Fengtaida marketing copy also describes "up to 32 channels" as an expansion figure; the conservative baseline for planning is 16 channels at 1080P per this device, with additional devices or vendor confirmation required for larger totals.
• Algorithm configuration, not outcome guarantees — the platform supports configurable scenario algorithms drawn from the current product records, which include vehicle analysis, face and behaviour analysis and plate identification functions. These are algorithm selection and operator verification capabilities. The product is not specified here as guaranteeing a specific identification result, accuracy rate or operating speed in a given scene — those outcomes depend on camera geometry, lighting, plate or target conditions and the configuration enabled on site, and must be established by site-specific validation.
• Interfaces — dual Gigabit Ethernet (2 × 10/100/1000 Mbps), HDMI output and input, USB 3.0, USB 2.0, Type-C OTG, RS485, GPIO and relay terminals. Northbound: HTTP, MQTT, GB28181. Southbound: GB28181, ONVIF, RTSP, RTMP.
• Algorithm density — per the current product record, each channel can run up to 10 AI algorithms at one time, and deployments that need more than 16 algorithms can use polling analysis. This is a configuration constraint, not a performance claim.
• Installation envelope — DC12V/2A, power consumption approximately 8W (configuration dependent), IP40 with fanless heat dissipation, operating temperature −20°C to +60°C, dimensions 235 × 150 × 62.5 mm. The AI BOX is a protected-area device: it belongs in a ventilated equipment room, an air-conditioned cabinet, a 19-inch rack or an enclosure rated to at least IP40. It is not an outdoor camera and must not be specified as an all-weather front-end device.

Role 3 — FTD-N3364 36CH AI Network Video Recorder: centralized recording, playback and evidence layer

The FTD-N3364 36CH AI Network Video Recorder (model FTD-N3364) is the centralized recording layer. It receives IP camera streams, records them to local storage, and provides the playback, search and export path that turns a confirmed event into evidence. It sits alongside the analytics device rather than replacing it.

• Recorded channel capacity — the current product record specifies 36-channel 4K IP camera input, with NTSC up to 30fps and PAL up to 25fps. This is the channel count that the recording layer is planned around; a site whose camera count exceeds it needs additional recording capacity, and the channel count must not be confused with the analytics channel count of the AI BOX.
• Compression — H.264 and H.265, when supported by the connected camera. Codec support is therefore a property of the camera-to-recorder pair, not an unconditional recorder capability.
• Storage — four SATA 2.0 interfaces, each supporting up to 14TB per the product record. Retention, resolution, codec and frame rate together determine how that capacity is actually used; the HDD model, capacity and quantity remain project variables.
• Network — two RJ45 adaptive 10/100/1000 Mbps Ethernet ports (dual Gigabit Ethernet), ONVIF support and network PTZ control. The dual-port architecture is a network-planning item: camera-side and client-side or management-side segmentation must be defined in the network design, not assumed.
• Video output and interfaces — 1 HDMI and 1 VGA output, with HDMI supporting synchronous audio output; 2 × USB 2.0 for backup; a graphical interface with mouse and keyboard support.
• Playback and evidence — the product record documents playback of up to 4 channels in 36-channel mode, with the supported resolution profile depending on the mode and configuration, plus evidence search by time and smart events. Neither the simultaneous playback figure nor the recording throughput is asserted here as a guaranteed performance level for a specific site.
• AI-assisted functions are camera-dependent — the product record lists human figure detection, face capture, face comparison, motion detection, image occlusion, out-of-bounds, electric fence, off-duty detection and passenger statistics, with a face database of up to 1,000 faces, and notes that camera support may be required. These functions are not promised as available on every camera. The record also documents face-comparison modes in 36CH, 32CH, 25CH and 16CH formats with different AI channel allocations, so the AI channel allocation must be validated against the final camera list before it is quoted.
• Installation envelope — AC 100–240V, 50–60Hz mains power, 15W or less without HDD, operating environment −10°C to +50°C and 10–95% RH, dimensions 440 × 365 × 70 mm and weight 4.25 kg. Remote access options listed in the product record are EasyVMS remote monitoring and playback and HiEasy mobile monitoring. The NVR is equipment-room equipment: it needs mains power, ventilation and rack or shelf space, and it is not an all-weather outdoor device.

Role boundary. The NVR records, stores, plays back, searches and exports. It is not the edge analytics engine of this architecture, and it must not be described as the AI BOX. Its AI-assisted functions are camera-dependent and are limited by the final camera list and by the AI channel allocation mode actually configured. Conversely, the analytics device does not replace the recorder: an alert is not a retention policy.

Role 4 — VMS / command centre: workflow and evidence management

The VMS remains the system of record for workflow. It owns user roles and permissions, live and playback viewing, event queues, alarm acknowledgement, operator notes, retention policy, export and audit trail. In this architecture the analytics layer is a producer of events and metadata, the recorder is the holder of the recorded evidence, and the VMS is the place where an event becomes an assigned and documented action. Municipal platforms differ widely in integration style — some consume ONVIF/RTSP streams only, some accept GB28181, some integrate through HTTP or MQTT message buses — so the northbound contract, and the relationship between the platform and the recorder, must be written down before hardware is ordered.

Role 5 — Network and backhaul (transmission infrastructure sub-item)

Urban nodes are distributed, which makes transmission a design decision rather than an afterthought. The relevant questions are: how many streams share each uplink, at what resolution and codec, whether the camera group sits on the same VLAN as the analytics device and the recorder, and how the site behaves when a backhaul link degrades. Aggregated camera traffic also has to reach the recording layer, so the recording VLAN and the recording stream load belong in the same calculation. Where fibre is impractical, a point-to-point or point-to-multipoint radio link carries the aggregated camera traffic back to the control room or equipment room; where that is used, the link is specified as a separate infrastructure line item and validated against the actual stream load. Switching, PoE or DC distribution and backhaul remain project infrastructure decisions in this reference solution rather than product selections.

Role 6 — Power, surge and mounting

Pole-top urban nodes combine long cable runs, exposed mounting positions and traffic vibration. The IR6 is specified as DC12V with average consumption of 12W–40W, so the power supply, cable gauge and voltage drop budget must be sized for the worst-case load — including any heater operation at low temperature — rather than the average. Surge protection is specified at TVS 6000V on the camera, and site-level earthing and a junction or waterproof enclosure belong in the same line item group. One current product merchandising field lists "built-in PoE power support" for the IR6 while the technical specification fields state DC12V; where PoE is desired, confirm the power option of the quoted SKU with the factory rather than assuming it (see Sources and Verification Notes). The recorder is separately powered from the mains in the equipment room, so recording continuity depends on the equipment-room power design as much as on the camera power design.

How the roles must not be confused

Engineering Decisions

The decisions below are the ones that most often determine whether an urban PTZ, analytics and recording deployment behaves as expected after go-live. Each is written as decision → applicable conditions → validation limit.

Decision 1 — Separate the sensing budget from the analytics budget

Size the camera count from scene coverage and target resolution at the distance that matters; size the analytics device from the number of streams that actually need algorithms. The two numbers are usually different, and forcing them to match either over-specifies cameras or under-provisions analytics. Validation limit: confirm both numbers against a surveyed zone map, not a nominal camera list.

Decision 2 — Count recorded channels, analytics channels and cameras separately

Three different counts govern this architecture: the number of cameras installed, the number of streams that need analytics, and the number of streams that must be recorded. The recorder is specified for 36-channel 4K IP camera input, the analytics device is planned at 16 channels of 1080P, and neither number is the camera count. Validation limit: if the recorded stream count approaches the recorder's specified channel limit, plan additional recording capacity rather than assuming a single unit scales indefinitely, and confirm the 4K channel count against the actual camera models.

Decision 3 — Define the verification objective before choosing a lens

Decide whether the operator needs to detect movement, recognise a vehicle class, or read a plate or a face, and at what distance. Each objective implies a different pixel density on target. Validation limit: a lens and sensor combination that meets one objective may not meet another; the pass criterion has to be agreed before installation, and re-tested afterwards.

Decision 4 — Treat IR range and low-light behaviour as separate properties

IR distance (500m on the IR6) describes illumination reach; it does not by itself describe image usability at that distance, which also depends on target reflectivity, atmospheric conditions and the zoom level in use. Validation limit: night-time acceptance tests must be run at the real distances and in the real weather, and re-run after any lens or illumination change.

Decision 5 — Plan analytics by exception, not by exhaustiveness

Algorithm count per channel is finite (up to 10 concurrent algorithms per channel on the FTD-16CH AI BOX per the current product record, with polling analysis available where more algorithms are required). Prioritise the two or three alert categories that the operations team will actually act on, and use polling or additional devices for the remainder. Validation limit: confirm the enabled algorithm set and licensing model per channel with the supplier and test the alert rate under real peak conditions.

Decision 6 — Configure identification functions as assisted review

Where plate identification, face or vehicle analysis is required, configure it as an assisted review function that produces a candidate event for an operator, together with the camera, zone and timestamp. Do not write scene-independent recognition results into the specification. Validation limit: algorithm selection and operator verification, together with a site calibration period, decide what the function can deliver; results must be measured in the actual scene, at the actual camera geometry, before being used in an enforcement or contractual workflow.

Decision 7 — Size recording storage from retention, resolution and codec

Storage is a consequence of the retention policy, not a starting point. The recorder provides four SATA 2.0 interfaces supporting up to 14TB each, and the recording load is set by the recorded resolution, codec, frame rate, motion activity and hours per day per channel. Two sites with the same channel count can need very different capacity. Validation limit: the HDD model, capacity and quantity must be confirmed against the measured recording load and the retention period, and the compression path (H.264 or H.265) is only available when the connected camera supports it; no retention duration is guaranteed until the pair is tested.

Decision 8 — Freeze the final camera list before AI channel allocation and ONVIF integration are accepted

The recorder's AI-assisted functions — including face capture, face comparison and the associated channel formats and face database — are documented in the current product record as camera-dependent, with camera support possibly required. AI channel allocation varies between the documented modes (36CH, 32CH, 25CH and 16CH face-comparison formats). Validation limit: validate the final camera list model by model against the recorder's ONVIF and network PTZ expectations and against the AI channel allocation actually required, and re-check it whenever a camera model is substituted.

Decision 9 — Control the alert rate before scaling the node count

A system that produces more alerts than the control room can process loses operator trust quickly. Zone geometry, dwell time, direction filters and confidence thresholds are the tools for tuning this. Validation limit: alert volume per operator shift is a site metric; it must be measured during a calibration period and reviewed after any node addition.

Decision 10 — Resolve power, surge and thermal before mounting

DC12V devices with 12W–40W average consumption require a voltage-drop calculation over the real cable run, plus a surge strategy for exposed pole-top positions. The analytics device operates from DC12V/2A in a protected area up to +60°C, and the recorder is a mains-powered, equipment-room device rated for −10°C to +50°C, so three different thermal and power envelopes have to be satisfied in one design. Validation limit: measure supply voltage at the camera terminals under load, not at the cabinet, and confirm the equipment-room power, ventilation and earthing arrangements for both the analytics device and the recorder.

Decision 11 — Freeze the integration contract early, including who holds the recording

Write down which platform is the system of record, which device holds the recorded streams, which protocol carries live video, which protocol carries events, how time synchronisation is handled, what happens when the analytics device or a backhaul link is offline, and how events are attributed to a camera and zone. The recorder exposes dual Gigabit Ethernet (2 × RJ45 10/100/1000Mbps), ONVIF support and network PTZ control, and provides HDMI/VGA local output, while the analytics device integrates through HTTP, MQTT and GB28181 northbound and GB28181, ONVIF, RTSP and RTMP southbound. Validation limit: an end-to-end event test with the actual VMS version and the actual recorder, including a check that the alert can be matched to the correct recorded stream.

Decision 12 — Define acceptance tests and evidence retrieval as one test plan

Commissioning should produce measured evidence for night and day image usability, stream stability under load, event latency to the VMS, alert volume, and a recording retrieval exercise. The retrieval exercise must prove that the confirmed event can be found in the recording with the playback channels available in the configured mode, played back and exported. Validation limit: a test that cannot be repeated by a second engineer on a different day is not an acceptance test.

Reference Configuration Matrix

The matrix below is a reusable starting point for a quotation, not a fixed bill of materials. Quantity, distance budget, camera count, recorded channel count, storage volume and retention period are project variables derived from the site survey. Where a value depends on the site, the matrix says so instead of inventing a number.

Site-specific validation required. Nothing in this matrix should be converted into a performance commitment — coverage distance, identification capability, alert volume or retention duration — without a documented acceptance test on the actual installation.

RFQ Preparation Checklist

Supplying the items below with an enquiry allows a configuration and quotation to be produced without a second round of clarification.

Site and scope

• Authority type and deployment scale: district, corridor, campus or single interchange.
• Node types and approximate counts: signalised intersections, arterial approaches, plaza or public square areas, pedestrian zones, transport interchange.
• Monitoring task per zone: incident awareness, crowd density estimation, restricted-area monitoring, vehicle flow, other.
• Required detection, recognition or identification distance from each camera position to the target.
• Rollout plan: phased or single stage, and the required completion window.

Sensing

• Whether existing cameras are retained, replaced or extended (and, if retained, whether they will also feed the analytics layer and the recorder).
• Mounting position and height available: pole, signal-pole extension, wall, gantry or corner.
• Confirm the zoom, IR and power configuration of the quoted camera SKU against the required distance budget.
• Whether a pan-tilt-zoom node is required at every position or only at selected long-range positions.

Analytics

• Camera count, stream resolution, codec and frame rate intended for analytics.
• Required algorithm set per channel, and the priority order if the channel budget is exceeded.
• Expected alert categories per zone and the operator action expected for each one.
• Calibration period available for threshold tuning before go-live.
• Algorithm licensing, customisation or training requirements.

Recording, storage and evidence

• Camera count, 4K channel count and stream resolution to be recorded, and whether the recorded stream count is expected to stay inside the 36-channel 4K input of a single recorder or to require additional recording capacity.
• Recording resolution, codec and frame rate per channel, and confirmation that the connected cameras support the intended H.264 or H.265 recording path.
• Required retention period, plus hours per day and motion profile per channel, so that storage can be sized from the recording load rather than from a nominal disk count.
• HDD model, capacity and quantity, whether all four SATA 2.0 interfaces are populated, and the largest single-drive capacity accepted (up to 14TB per interface per the product record).
• AI functions expected from the recorder, the AI channel allocation mode required (the product record documents 36CH, 32CH, 25CH and 16CH face-comparison formats with different AI channel allocations), the expected face database size (up to 1,000 faces per the product record) and confirmation of the final camera list these functions depend on.
• Playback and evidence expectations: simultaneous playback channels required in the operating mode, search by time bar or smart event, clip export format, USB backup requirement and audit trail.
• Display outputs required (HDMI and VGA), and whether a local monitor with mouse and keyboard is needed at the recorder location.
• Network topology for the dual Gigabit Ethernet ports (2 × RJ45 10/100/1000Mbps), camera-side and client-side or management-side segmentation, ONVIF expectations and remote access requirements (the product record lists EasyVMS remote monitoring and playback and HiEasy mobile monitoring).
• Mains power availability, rack or shelf space, ventilation and earthing at the recorder location, and the equipment-room temperature range to be maintained.

Infrastructure and environment

• Power available at node: DC, PoE, local cabinet or solar, and the cable run length.
• Backhaul available: municipal fibre, leased line, point-to-point radio link or cellular/SIM, with measured or estimated capacity.
• Environment: maximum and minimum temperature, coastal or corrosive exposure, dust, lightning exposure, traffic vibration.
• Equipment-room or cabinet conditions for the analytics device and the recorder: ventilation, air conditioning, rack space, IP40 or better enclosure for the analytics device, mains supply and earthing.

Integration and workflow

• VMS or command-centre platform, version and licensing model.
• Whether the platform, the recorder or both hold the recorded streams, and how an alert is matched to the corresponding recorded video.
• Integration style required: ONVIF, RTSP, RTMP, GB28181, HTTP, MQTT, SDK or API.
• Event semantics required: camera, zone, time, category, snapshot, clip reference.
• Retention period, storage location, export format and audit requirements.
• Behaviour required when the analytics device, a recorder or a backhaul link is unavailable.

Commercial and programme

• Quantity, delivery destination and expected schedule.
• Market and any certification or documentation requirements for the destination.
• OEM / ODM or private-label requirements (branding, packaging, firmware).
• Documentation requirements: datasheet, specification sheet, test record format, acceptance report.

Request a Smart City Surveillance Configuration

A quotation for this reference architecture is produced from the checklist above: the node list and distance budget drive the PTZ selection, the recording scope drives the recorder and storage configuration, the analytics scope drives the edge device count and configuration, and the integration requirements drive the interface contract.

Send the site scope, the monitoring task per zone, the recording and retention requirement and the integration requirements, and the Fengtaida engineering team will return a configuration proposal with the equipment roles made explicit.

Request a Smart City Surveillance Configuration

Have the RFQ Preparation Checklist ready — node types, detection distance, camera and channel counts, recorded channel count and retention, power and backhaul availability, and the VMS integration requirement. The more complete the project brief, the more accurately the configuration can be scoped.

Related Products

All three hardware roles in this reference solution are current Fengtaida products. Links point to the live product pages used as the source of the specifications quoted above.

Related resources

• Smart City Surveillance Solutions — the Fengtaida smart city solution landing page, for the wider application context this reference solution belongs to.
• Border Security Solutions — the reference programme for long-range perimeter and 500m IR night-vision deployments, which is where the long-range optical principles used here are documented in more depth.
• Request a Configuration — send the RFQ Preparation Checklist to the Fengtaida engineering team.

Sources and Verification Notes

All product facts in this article come from the current Fengtaida product records read on 17 September 2026, or from links confirmed with the site operator. No customer deployment, site count, response time, recognition rate, retention duration, cost saving or uptime figure is asserted anywhere in this article.

Sources used

• IR6 IR High Speed Dome Camera — https://www.fengtaida.com/products/ir6-ir-high-speed-dome-camera (product record gid://shopify/Product/6219914903728, status ACTIVE; specification fields, description and technical metafields read 17 September 2026).
• FTD-16CH AI BOX — https://www.fengtaida.com/products/ftd-16ch-ai-analytics-server (product record gid://shopify/Product/8067566043312, status ACTIVE; FTD-AIBOX-C16 specification metafield, description and application fields read 17 September 2026).
• FTD-N3364 36CH AI Network Video Recorder — https://www.fengtaida.com/products/ftd-n3364-36ch-ai-network-video-recorder (product record gid://shopify/Product/8124072788144, status ACTIVE, model FTD-N3364, template suffix nvr-36ch-detail; product identity, product intro, application fit, technical specification and integration metafields read 17 September 2026).
• Smart City Surveillance Solutions page — https://www.fengtaida.com/pages/smart-city-solutions (link value taken from the current IR6 product record).
• Border Security Solutions page — https://www.fengtaida.com/pages/border-security-solutions (link value taken from the current IR6 product record).
• RFQ / contact page — https://www.fengtaida.com/pages/contact-us (confirmed by the site operator).

Product field inconsistencies and qualifications — conservative treatment

Deliberately excluded content

• Any specific customer, authority or project case study.
• Any deployment scale figure (node, intersection, square, zone or recorded-channel counts) presented as a completed project.
• Any measured result metric — event notification latency, recognition or reading performance, operator workload change, incident totals, retention duration achieved — or any financial return estimate.
• Appliance-style environmental claims for the FTD-16CH AI BOX or the FTD-N3364 NVR; both are protected-area devices and neither is an all-weather outdoor unit.
• Any claim that the recorder performs edge analytics inference, or that its camera-dependent AI functions are available on every connected camera.
• Any product link, product card or product name for infrastructure items that are not part of this article's confirmed three-product scope, including backhaul products.
• Unverified certification claims for the destination market; the IR6 record lists CE, FCC and RoHS compliance, and any further market certification is subject to confirmation.

Verification reminder. Before publication or quotation, re-read the current product fields, confirm the quoted SKU configuration of the sensing device, confirm the final camera list and AI channel allocation for the recorder, confirm the HDD model and capacity, and confirm the VMS integration contract of the specific destination site. Site-specific validation is required for every performance statement.