Integrated system deliverables
| Layer | Released project definition |
|---|---|
| Player / Compute | Source files, player, OS image, CMS, codec and update method |
| Display control | OLED controller, LED processor or embedded display electronics |
| Signal and Cabling | Input, conversion, protection, cable schedule and connection map |
| Installation | Structure, glass, mounting, thermal path and service access |
| Operations | Monitoring, recovery, spares, acceptance record and handover |
A demonstration proves that one configuration can display one piece of content under the conditions of that demonstration. Handover asks a larger question: can the installed system meet its requirements, recover from expected faults and be operated by the receiving team?
In an August 2026 discussion, an owner describes running out of usable spares after the supplying company closed. Include service records, compatible replacement parts and a recovery procedure in the acceptance package.
Start with a traceable requirement
Give each acceptance item an identifier, an owner, a configuration baseline and an agreed pass condition. A useful baseline identifies hardware revisions, firmware, player image, content package, cabling and processor settings. Store the report beside the configuration it tested.
AVIXA’s performance-verification framework supports relating project requirements to verification and reporting. The FAT/SAT/operations structure below is our proposed project workflow; it is not a claim that AVIXA prescribes these exact stages or limits.
Use each acceptance stage for a different question
| Stage | Question | Record the remaining gap |
|---|---|---|
| FAT: before shipment | Does the released hardware/software configuration meet the agreed factory test plan? | Simulated interfaces, temporary cabling and untested site conditions |
| SAT: installed system | Does it work with the actual mounting, power, network, cable routes and environment? | Open site defects, deviations and responsibility for closure |
| Operational acceptance | Can the receiving team operate, update, diagnose and restore it? | Training, access, backups or support arrangements still missing |
A practical test record
| Test | Action and observation | Pass condition to agree |
|---|---|---|
| Cold start | Follow the approved shutdown/start procedure; time arrival of the correct content | Correct application, input, map and content within the specified time |
| Network loss | Isolate the agreed network link; observe local playback and monitoring | Agreed fallback and truthful connection alarm |
| Signal loss | Interrupt the approved test link; restore it and observe recovery | Defined display state; no unintended persistent input or map change |
| Content update | Publish a versioned test package; check every intended display | Correct revision and schedule; rollback works if included in scope |
| Configuration restore | Restore onto an approved spare/test unit and verify the result | Matching mode, map, control behaviour and accepted image |
| Service replacement | Exchange the agreed field unit using its documented procedure | Mechanical fit, restored operation and acceptable visual matching |
For each row, record preconditions, operator, timestamp, observed result, evidence location and deviations. An unexecuted test is “not tested,” not “pass.” Electrical, thermal, structural and environmental qualification require their own defined procedures and competent personnel; a playback checklist cannot replace them.
Demonstrate what redundancy actually covers
Trace the source, processor, transmission path, power distribution and receiving hardware. Identify shared components. Then test only the failover scenarios included in the design and approved test plan. Two inputs on a controller do not establish independent sources; two supplies on one feed do not protect against that feed failing.
Make one person recover it from the handover pack
Ask a qualified team member who did not configure the system to locate the correct backup, identify the spare and follow the recovery instructions. Record missing steps. Include drawings, cable/port labels, asset IDs, software versions, calibration records, approved settings, licences, access ownership and escalation details.
Measure service time from the beginning of access and isolation through configuration and visual verification. Timing only the module exchange understates the operational interruption.
Close changes as well as defects
If firmware, cabling, hardware or a processor preset changes after FAT, record the reason and assess affected checks. Repeat those checks on the new baseline. Preserve accepted deviations and remaining actions with owners and dates. The final deliverable is a recoverable, documented configuration with evidence against the agreed requirements.
Technical sources
- AVIXA: Performance Verification — project verification and reporting framework
- AVIXA: Documentation Requirements — documentation scope; consult the applicable document for detailed requirements
About this guide: Use these project checks with acceptance limits agreed for the supplied configuration. VITREVIA supplies and integrates display systems directly from Shenzhen, China.
Download the editable test record (.txt)
Project checklist
Related product and project pages
Integrated Display Systems
Review the commercial and engineering scope for a coordinated display system.
Review System IntegrationDelivery and Support
Review documentation, shipment, warranty boundaries and spares planning.
Review Delivery and SupportTransparent Display Applications
Connect the technical guidance to transport, retail and museum project contexts.
Explore the ApplicationThe Player Is Online. Is the Display Actually Showing the Right Content?
Continue with the complementary display-system engineering guide.
Read the Related GuideProject Requirements
Organize geometry, environment, content, operation and service inputs for engineering review.
Build the Project Brief