Service scope and implementation plan
direction numberD30
Demand scenario8 items
main inputLWIR/RGB-LWIR L3/L4; LWIR L3/L4;
Typical routeT06、T07、T19、T08、T11、T20
The project scope is determined based on samples, equipment, working conditions and written indicators; general modules, special models and multi-sensor integration are configured according to the evaluation results.
Application scenarios and development content
IR233Pedestrian, cyclist and animal detection at night
- Minimum input and technical route
- LWIR/RGB-LWIR L3/L4;T06+T07
- target output
- Target box, category and distance interval
- Implementation
- Product model required
- critical acceptance
- AP, Recall layered by day/night/weather/distance
IR234Vehicle, motorcycle and obstacle detection at night
- Minimum input and technical route
- LWIR L3/L4;T07
- target output
- Categories, boxes, trajectories and collision candidates
- Implementation
- Product model required
- critical acceptance
- Small target Recall, false alarm/km, delay
IR235Multi-sensor sensing in fog, smoke and glare conditions
- Minimum input and technical route
- RGB+IR+Radar L4;T06+T07
- target output
- Fusion of target and modal health states
- Implementation
- Requires multi-sensor fusion
- critical acceptance
- Compare single/multimodal gains by degradation conditions
IR236Pedestrian crossing, road edge and TTC risk analysis
- Minimum input and technical route
- L3/L4;T07+T19
- target output
- Trajectory, TTC and risk events
- Implementation
- Requires geometry/velocity model
- critical acceptance
- TTC error, risk recall, alarm advance
IR237Detection of road thermal anomalies, burning vehicles and abandoned hot objects
- Minimum input and technical route
- LWIR L3/L4;T08+T07
- target output
- Hot targets, road coordinates and events
- Implementation
- Road data required
- critical acceptance
- False alarms/km, discovery distance and latency
IR238Thermal imaging assists in determining vehicle occupant presence and seat occupancy
- Minimum input and technical route
- LWIR L3;T07
- target output
- Seat occupancy and crew candidates
- Implementation
- Cockpit data required
- critical acceptance
- Child seat/sun/air conditioning layered, seat level F1
IR239Driver's eye NIR, head posture and fatigue characteristics
- Minimum input and technical route
- NIR L3;T11+T19
- target output
- Eye key points, head pose, and persistent events
- Implementation
- Product model required
- critical acceptance
- Glasses/Complexion/Night Layering, Event F1
IR240Road infrared data sets, scene playback and safety assessment
- Minimum input and technical route
- L3/L4;T20
- target output
- Hierarchical data, scene coverage and regression reporting
- Implementation
- Need to verify system
- critical acceptance
- Scene coverage, labeling consistency, and version reproducibility
Implementation and delivery methods
- Project input confirmationCheck camera, spectral band, bit depth, SDK, environmental conditions, sample and acceptance true value.
- Sample verificationVerify key processing links, applicable conditions and abnormal working conditions, and determine the development scope and acceptance methods.
- Algorithm development and integrationImplement data parsing, algorithms, quality gating, interfaces and target platform deployment.
- Test acceptance and handoverRetest according to the agreed test set and target platform, and hand over the deliverables, test results and applicable conditions.
- Requirements and technical solutions, input and output and interface field definitions
- Algorithm library, model or SDK/API; delivery form is confirmed in the project plan
- Sample program, parameter configuration, error status and calling instructions
- Test set version, indicator definition, stratification results and failed sample records
- Target platform adaptation, resource usage and running delay records
- Version, dependencies, license, reproduction steps and applicable conditions description
Acceptance design
Each scenario establishes independent test cases according to "key acceptance". When sharing models across scenarios, results are reported separately for each scenario, distance, load, environment, and target size, supplemented by overall statistics.
When high-risk alarms or controls are involved, the algorithm output is used for review or linkage judgment; safety functions, regulatory responsibilities, and automatic disposal require separate design and acceptance.
Frequently Asked Questions for Enterprise Customers
Can I purchase directly based on one of the scenes?
Can be evaluated first as a separate work package. The formal scope should describe the device, data, target objects, environment, interfaces, delivery form, and acceptance thresholds.
Can it be started when there are no abnormal samples?
The data interface, normal baseline, acquisition plan and simulation/controlled test design can be completed first; the abnormal detection rate and fault classification effect can be evaluated after obtaining sufficient abnormal true values.
Can the algorithm directly trigger alarms or equipment actions?
Duration, deduplication, quality gating, manual review, communication failure and safety interlocking need to be designed based on business risks. High-risk actions should be activated after completion of independent safety mechanisms and on-site acceptance.