A project specification often starts with resolution and a preferred form factor. That is not enough to protect a bid. A camera can meet the pixel count yet fail the evidence task because the lens is wrong, the night scene is washed out, the recorder cannot display every stream, or the delivered firmware differs from the sample. Commercial buyers need a specification that connects the scene to the image, system, installation, test, and service requirements. It should also distinguish mandatory pass conditions from preferences that can be traded against budget. This brief presents a specification structure, not a universal camera schedule. A warehouse gate, retail back room, parking entrance, and remote site need different fields. Where data is missing, make it a question for the site survey or supplier response instead of filling it with an assumed number.
Define the Evidence Task by Zone
Now break the project down into zones of interest, list out the scene views required for each, and note the following about each view: height of mounting, view size from location, travel direction, any special lighting required, any reflective surfaces that may cause problems, and any obstructions to the view. By marking up the floor plan with the required views for each zone of interest, you can turn a vague requirement such as ‘cover the loading bay’ into a testable task. Also ensure that the required view will provide sufficient detail at the required distance. For example, a wide-angle lens may not be the best choice for tasks that require detailed inspection at long range.
Review purpose: Are people viewing the images in real time or viewing recorded images at a later time? Are they reading information from labels on people or objects, etc.? This affects the choice of lens, exposure, frame rate, storage, etc., and whether views are fixed or motorized and whether single or multiple views are required. A PTZ view should not be specified as continuous 360-degree coverage of all areas of interest unless accompanied by fixed companion views or a full patrol plan has been specified for the area.
Create a simple camera schedule with one row per location. ID, scene task, required view with required lens, mount position, special lighting, environmental exposure required, power, networking, recording, etc., and required retention period with space for acceptance evidence of each camera. Link this schedule to your marked-up floor plan and the resultant purchase order for the cameras. This simple schedule will act as a single point of reference for designers, installers, and end users alike.
Write Measurable Technical Fields
Details such as image resolution, lens, field of view, frame rate, codec, number of streams, low-light conditions, WDR requirements, and event behavior should all be specified. Where possible, avoid ambiguous terms such as ‘crystal clear’ and ‘long range. ‘Where the application requires detail at a specific distance, then define a target and require a sample or design to meet this. If a specific numeric value cannot be specified prior to the site test, then note this as a commissioning acceptance item.
Network and storage fields should name the intended architecture. These include PoE or separate power, WiFi or cellular where applicable, switch and recorder interfaces, local or cloud storage, required retention, export format, and remote access path. Ask for average and peak bitrate under the intended settings if bandwidth is tight. Do not specify internet speed as a substitute for LAN capacity or recorder throughput.
Note that environmental fields need to be filled with the real installation conditions, such as indoor/outdoor, dust, rain, washdown, direct sun exposure, salt air, temperature range, vibration, etc., and possible service access. Although JT-8698PRO lists a dual-camera setup with ball-machine linkage and two 2MP SC233A CMOS sensors, and JTZ-9690PRO lists a 6MP sensor, H.265 encoding, IP66 rating, and 2.4G WiFi, the comparison tables of the JT-8698PRO outdoor camera and the JTZ-9690PRO PTZ camera make only good reference points. However, the finally delivered model might differ from the scheduled one. A model name does not automatically make a project acceptance criterion.
When imposing a design freeze, it is essential to outline an exception to this rule as well. Thus, even minor changes to parts such as the lens, the radio module, the housing, the firmware or the behavior of the app, the adapter or the storage medium have to be indicated against the relevant requirements and proof provided to the supplier in the form of a short deviation log.
When creating a specification for your project, also outline the commissioning record. This document outlines installed camera ID, height, direction, firmware, recorder channel, stream, and time zone details, plus the storage policy in use. Also list the test clip used for acceptance testing. This document will be referred to by service personnel on subsequent visits to alter a lens, angle, or even stream settings. On multi-site projects, ensure that you use the same field names on all schedules but allow for acceptance testing to be varied at individual sites. The schedule is used for design, purchasing, installation, and subsequent service support as opposed to simply being an appendix to the tender.
Get the supplier to return a compliance matrix for release before, covering the requirement, the proposed model, the evidence for the requirement, any exceptions to the requirement, who owns the requirement, and who has approved the requirement. A project specification review is most useful if you include the zone schedule, the proposed recorders and networks, the target market, and the proposed acceptance test plan. Thus, all the open items are visible on the line as opposed to being buried in a line that reads ‘meets requirements.’
Freeze Interfaces and Acceptance Before the Quote
Compatibility requirements must be clearly described for the recorder/VMS versions, supported stream types, event sources and corresponding event protocols, audio channels and corresponding requirements, mobile applications, and user roles, as well as export workflows. Mixed systems must be clearly described for the functions that must work. In addition to “ONVIF compatible,” it must be described how “discovery,” “live view,” “recording,” “search,” “events,” and “time,” as well as “PTZ control,” work on different products.
For the configuration items, the firmware versions, the default regions as well as time zones, languages, and passwords, and the onboarding procedures and the storage must be clearly described as well as the model-specific app dependencies. Acceptance tests must be described by the people that are authorized to approve changes and by the documents that must be provided for changes. Sensors, wireless modules, and adapters, as well as enclosures, must not be replaced unnoticed and then put into production, because they can affect the acceptance test results in a negative way.
A sample acceptance test protocol must be attached to the RFQ. This protocol must contain tests for daytime/night-time images, for moving objects, and for network failures, as well as for recording and exporting images and audio for accessories, for packaging, and for the connection to a recorder. The exact sample revision as well as the pass criteria must be recorded. A general statement of the supplier that the tested product is also delivered is not as useful as the mentioned data.
Make Serviceability Part of Procurement
Ensure that the commercial ownership of a supplier extends beyond the installation of their product. Establish their warranty terms and conditions, their advance replacement/repair policy, their spare parts availability, their firmware support policy, and their technical response times. Establish their product life-cycle plans to ensure that a single bracket or adapter does not cost more than the original purchase price of that item when part of a system of dozens of cameras. For OEM or project-specific products, establish their drawing requirements, sample approval, tooling ownership, etc., and their packaging, minimum order quantity, lead time, and change fees. Jortan’s manufacturing facility and our commercial camera range can be compared against these criteria. Their factory, mold, and injection capabilities are of interest where housing changes are required. However, it is essential to establish what the supplier is supplying and what evidence of the production stages they can provide.
Conclusion
A good commercial camera specification is based on the evidence required at each zone and links this to the lens, network, recording, environment, acceptance test, and service. Unknowns must be visible, and all approvals need to be linked to the delivered specification change. Procurement can then compare offers without transferring unknowns into promises of a contract.
FAQ
Q1: Should every camera in a commercial project use the same resolution?
A1: No. Zones can have different levels of detail, lens coverage, and low-light performance. Standardization of spares and service is useful but must not conflict with the evidence required.
Q2: Is an ONVIF statement enough for recorder compatibility?
A2: No. Specify and test the following functions of the project: discovery, stream display, recording, playback, events, audio, time synchronization, and PTZ.
Q3: What should be attached to a camera RFQ?
A3: Zone schedule, site details, recorder & network details, retention target, required functions, acceptance test plan, target market, and change-approval rules.
