KNX OEM Project Checklist: Requirements, Samples, and Production
Plan a KNX OEM project with measurable requirements, prototype and pilot gates, certification scope, ETS deliverables, change control, and factory test records.
The dangerous moment in a KNX OEM project is not always the first prototype. It is the email saying “sample approved” when nobody has defined what was approved.
Was it the glass color? The relay behavior? The enclosure fit? The ETS application? A sample can look finished while still using temporary firmware, hand-modified hardware, or a component that cannot be sourced for production.
A useful OEM checklist therefore follows release evidence, not just dates. Specify the product, approve a controlled configuration, prove that it can be built repeatedly, and retain the information needed to support it. This guide focuses on that buyer–manufacturer handoff rather than repeating the full KNX device development process.
Decide what is actually being customized
| Project type | Typical scope | Question to settle early |
|---|---|---|
| Label/finish variant | Branding, colors, packaging, documentation | Which changes affect the registered product or required approvals? |
| Application variant | ETS parameters, communication objects, logic, UI | Who owns the application and its maintenance? |
| Hardware derivative | New I/O, supply, display, enclosure, or board revision | What validation and certification work must be repeated? |
| New platform | New architecture plus hardware and software | Which development and lifecycle responsibilities remain with each party? |
Do not let “OEM” stand in for a statement of work. A logo change and a new switching output stage require very different engineering effort, even if they share the same front cover.
KNX Association’s manufacturer technology guidance describes several development routes, including system components and OEM approaches, followed by product certification. Establish the applicable route with the manufacturer and certification stakeholders before committing to a launch date.
Replace adjectives with an acceptance method
“Premium screen,” “fast response,” and “high reliability” are not test instructions. Translate each important requirement into a condition, expected result, and evidence owner.
| Requirement area | Weak wording | More useful requirement structure |
|---|---|---|
| Display | Easy to read | Approved UI sample, specified lighting/viewing conditions, agreed legibility test |
| Switching | Supports LED loads | Declared load/inrush envelope and validation with agreed representative drivers |
| KNX behavior | Fully compatible | Approved objects, DPTs, flags, parameters, startup states, and tested interaction list |
| Mechanical | Fits standard box | Named box/drawing revision, tolerances, cable space, and physical fit check |
| Recovery | Reliable firmware | Defined interruption/restart cases and an approved recovery procedure |
| Appearance | Consistent black finish | Controlled reference sample, inspection lighting, and agreed allowable variation |
Distinguish “must pass” requirements from preferences. If everything is a preference until the purchase order, the supplier cannot plan meaningful validation.
For a touch panel, include each target language’s longest labels. For an actuator, include behavior after bus loss and restoration, local override, and output status semantics. For a gateway, include the supported endpoint versions and the distinction between command acknowledgement and confirmed field state.
Approve a sample configuration, not a loose device
A golden sample is a controlled reference. It should identify the hardware revision, firmware build, ETS application version, enclosure/finish revision, and the test report against which it was approved. Keep an agreed reference at both organizations where practical.
| Gate | Evidence needed to leave the gate | What approval does not mean |
|---|---|---|
| Requirements baseline | Signed scope, exclusions, interface list, acceptance plan | Design is already validated |
| Engineering prototype | Functional evidence and an open-issues list | Production tooling or yield is proven |
| Design validation | Agreed environmental/electrical/functional results for the defined configuration | Any later component substitution is acceptable |
| Pilot build | Production-intent process, traceable units, test coverage, defect review | Every future batch can skip inspection |
| Production release | Approved configuration, closed critical issues, controlled work/test instructions | Firmware and component changes need no review |
The gate names can differ. Their purpose is to prevent a sales milestone from being confused with an engineering release.
When a prototype includes rework, photograph and record it. Decide whether the correction is present in the next PCB revision or remains an approved production process. An undocumented wire on a sample is not a reliable manufacturing instruction.
Give ETS deliverables their own sign-off
An electrically sound device can still be difficult to integrate if its ETS application is poorly organized. Review names, units, DPTs, object availability, feedback, defaults, and behavior after download. Test from a clean project as well as the developer’s working project.
Ask an integrator to perform a representative configuration using only the supplied instructions. Record where they need undocumented knowledge. The objective is not merely to show a telegram in a monitor; it is to make the product commissionable by somebody who did not design it.
Keep exported application files and their versions in the release package. Define how a field installation moves from an older application to a newer one, what settings may be lost, and how rollback or recovery is handled when supported. See firmware customization planning for related change boundaries.
For secure products, specify the supported provisioning process and custody of device-specific security material. Avoid shared production secrets where unique device material is required. Limit access to provisioning tools and define replacement/RMA handling without exposing customer installation keys.
Do not use KNX certification as a blanket compliance statement
KNX conformity and interoperability are one part of a product’s release evidence. Market-specific electrical safety, EMC, environmental, radio, and labeling obligations may be separate. A KNX logo is not evidence that every requirement in every destination market has been satisfied.
Ask the responsible compliance specialist and test organization to map the actual product variants, brands, and changes to the required evidence. Keep the scope written down. This article is a project checklist, not a legal determination of which legislation applies.
The KNX certified-products information describes third-party conformity testing rather than a manufacturer’s unsupported declaration. Verify the exact marketed variant and applicable process; do not rely solely on a certificate for a vaguely similar base device.
Test production units differently from design samples
Qualification testing asks whether a design can meet its requirements. End-of-line testing asks whether this particular unit was assembled and programmed correctly. Neither replaces the other.
For each serial number, consider recording the product/revision, programmed versions, provisioning outcome, test-station identity, timestamp, pass/fail result, and disposition of any rework. The necessary detail depends on the product and contract, but a handwritten batch total rarely helps diagnose a single returned unit.
Agree which tests are performed on every unit and which are sample-based. Safety-related production tests must follow the applicable requirements and competent test design. Do not turn an arbitrary endurance test duration into a reliability claim.
If the pilot build has defects, review both the failure and the escape path. A reversed connector caught at final test may require a process correction; the same connector shipped to a customer also requires a test-coverage correction.
Put ownership and change control in writing
Before paying for tooling or development, agree access and usage rights for drawings, tooling, firmware, ETS applications, artwork, test fixtures, and test data. Ownership and a right to use are not the same thing. Have appropriate commercial/legal advisers review the agreement rather than relying on informal email assumptions.
Require advance change notification for relevant components, suppliers, firmware, manufacturing location, and test process. Each proposed change needs an impact assessment, validation scope, approval owner, and effective serial-number or batch boundary.
For end-of-life parts, define the notice and last-buy process. For returns, define diagnosis, replacement configuration, data handling, and the feedback loop into corrective action. A low unit price says little about any of these costs.
How many samples should be ordered?
Enough to support the agreed tests, destructive use where necessary, integrator evaluation, and retained references. There is no universal sample quantity; derive it from the validation plan before agreeing the sample budget.
Can a cosmetic change affect release work?
Yes. Changed materials, openings, labels, or dimensions can affect fit, thermal behavior, markings, and the scope of existing evidence. Have the responsible specialists assess the actual change.
What should accompany an OEM quotation request?
A function brief, target markets, expected volumes, interface requirements, customization list, schedule assumptions, and acceptance expectations. Share those through the project contact together with a clear list of items that are still undecided.