Test the released OEM configuration

An OEM integration acceptance test must identify the exact controller hardware, firmware, protocol and configuration under test. Generic factory test results are useful background, but they do not prove that the branded and customized release behaves as the integrator expects.

Define the acceptance record

Test groupRepresentative checksEvidence
IdentityModel, serial number, boards, firmware and protocol versionPhotographs and version report
I/OEvery configured output, detector and auxiliary inputChannel-by-channel result
ControlPlans, transitions, clearance, flash and local fallbackTimed scenario log
IntegrationCommands, status, alarms, timestamps and permissionsPacket trace and central-system record
RecoveryPower cycle, network loss, restart and invalid requestObserved state and alarm behavior
DocumentationManuals, wiring, protocol, release notes and labelsControlled document list

Use requirements as test inputs

Every acceptance case should reference a requirement or tender clause and define preconditions, steps, expected result and retained evidence. Avoid “works normally” as an acceptance result. Record measured timing, status codes, alarm text and configuration values.

Include negative and boundary cases

Test invalid commands, maximum configured I/O, timing limits, incomplete messages, interrupted communications and restart during normal operation. Negative tests demonstrate that the controller rejects unsupported or unsafe requests predictably and leaves a diagnosable event record.

Control exceptions

If a case fails, assign an owner, severity, temporary restriction and retest requirement. Do not hide a known exception inside meeting notes. The final acceptance sheet should state which cases passed, which were waived by an authorized customer representative and which block pilot deployment.

Frequently asked questions

How is an OEM integration test different from a factory test?

A factory test checks production quality and base product functions. The OEM integration test checks the exact branded configuration, customized firmware, protocol behavior, central platform, labels and documents agreed with the integrator. Both are useful, but they answer different acceptance questions.

Should every controller output be tested?

Test every output and input configured for the accepted model, including spare or optional channels that will be sold as available. A channel-by-channel fixture result catches mapping, labeling and board-configuration errors that a demonstration using only one signal group may miss.

Can failed cases be accepted with a waiver?

Only an authorized project representative should approve a documented waiver after the operational and safety impact is understood. Record the restriction, affected versions, corrective plan and field controls. Safety-related or tender-mandatory failures should normally block release until corrected and retested.

Related buyer resources

Planning an OEM controller project? Send the target market, phase plan, I/O list, protocol requirements and tender documents through our project enquiry form.