Engineering
Control board redesign under a fixed enclosure constraint
An existing control board had to be redesigned within an enclosure that could not change, after several functions were added to the requirement.
- Stage
- In development
- Disclosure
- Anonymised summary
- Last reviewed
Context and constraints
A product team needed additional functions on an existing control board. The mechanical envelope was already tooled and could not be altered, so the redesign had to be resolved within fixed dimensions.
Constraints
- Enclosure dimensions and mounting points were fixed by existing tooling
- Power budget could not be increased without changing the supply arrangement
- The existing interface had to remain compatible with what users already knew
- Additional functions had to be introduced without losing existing ones
Our role
- Assessed the enclosure and power constraints against the added requirements
- Defined the board architecture and the trade-offs between the viable options
- Specified the schematic and PCB revisions and the design review checkpoints
- Defined the functional tests needed to confirm the revised behaviour
Delivered by other parties
- Enclosure and mechanical design remained with the client's own team
- Firmware for the added functions was developed alongside this work
- Tooling and volume manufacturing decisions remained with the client
Key decisions
| Decision | Consideration | How it was verified |
|---|---|---|
| How much function to add within the fixed envelope | Every added function consumed board area, power, or both, so the limit had to be found before committing the layout. | Board area and power were budgeted per function and compared against the remaining allowance, with the shortfall stated explicitly where it existed. |
| How to keep the existing user interface behaviour | Users had established habits, so interface changes carried a cost beyond engineering effort. | Existing behaviour was written down as a specification and checked against the proposed design before layout work began. |
| Where to place the design review checkpoints | Layout changes are expensive to unwind after a board is released for fabrication. | A review was scheduled before board release, with the checked items listed in advance rather than agreed after the fact. |
Verification evidence
-
Constraint and trade-off analysis
Board area and power budget per function, with the options and their consequences recorded.
- Scope
- Desk analysis based on the existing design and the new requirements.
-
Design review record
Checklist of reviewed items with the outcome and any open points.
- Scope
- Covers the agreed review scope; not a full product validation.
-
Functional test definition
Tests defined for the revised behaviour, including the conditions each result is valid under.
- Scope
- Defined for the agreed revision; results depend on the build under test.
Stated limitations
- This entry describes engineering definition and design work, not a production outcome
- No yield, cost, or reliability figures are published
- Firmware for the added functions was developed as a separate workstream
- The enclosure constraint was fixed by pre-existing tooling, not chosen in this work
Background
Adding functions to an existing product is usually presented as a software problem. Where the enclosure is already tooled, it is first a physical one.
Approach
The available board area and power were treated as a budget and allocated per function before any layout work started. Where the requirement exceeded the budget, that was stated as a shortfall rather than resolved by an optimistic estimate.
What this illustrates
Constraints that cannot move are the ones worth defining first. The redesign became tractable once the limits were written down and each added function was priced against them.