Firm Design Phase

Firm design is where pretty block diagrams and ROM pricing collide with reality. It is a risk-transfer exercise — transferring ambiguity into specification before the first fabrication drawing is released. Problems not resolved here compound at every subsequent phase.

The Four Core Documents

Basis of Design (BOD)

The governing document for the entire project. Every change order is priced as delta from the BOD. This document will be argued over if the project goes to dispute. Make it specific.

BOD establishes:

• Design throughput requirements (peak rate, sustained rate, design-day volume)
• Product specification (dimensions, weights, packaging types — including what is explicitly out of spec)
• System configuration (number of aisles, sorter type, pick module layout)
• Operational profile (shifts, hours, staffing assumptions)
• Building conditions assumed at bid (floor flatness, column grid, clear height, power, HVAC)
• Interface assumptions (WMS vendor and version, ERP integration method)

Functional Design Specification (FDS)

Behavioral specification for the system: how does this system act, not what physical components it contains. The software team codes against the FDS. A vague FDS produces ambiguous code.

FDS defines:

• Controls logic and operational modes (induction modes, accumulation strategies, flush sequences, fault recovery, startup/shutdown)
• WCS/WES software functional requirements (order batching, divert assignments, exception handling, operator screens)
• Interface protocols (WMS API definitions, message formats, error handling, retry logic)
• Safety and interlock behavior (E-stop zones, zone isolation, light curtain interactions)
• Reporting and monitoring (OEE metrics, alarm structures)

A medium-complexity FDS runs 80-200 pages. Full-line systems with robotics integrations can exceed 400 pages. The FDS must define system behavior at degraded state: what happens when a scanner reads 0% for 30 seconds, when the WMS stops responding, when a divert fails.

Interface Control Document (ICD)

The single document that creates the most commissioning pain when done poorly. The failure mode: both the integrator and the WMS vendor read an incomplete ICD and conclude that responsibility ends wherever the document goes vague. During commissioning, both sides point at the gap.

A complete ICD specifies for every interface:

• Message trigger — what event initiates the message
• Message direction — WCS → WMS, WMS → WCS, bidirectional
• Message format — field names, data types, character lengths, encoding
• Timing and sequencing — latency requirements, acknowledgment requirements
• Error handling — timeout behavior, malformed message handling, missing field behavior
• Test cases — minimum 5 scenarios per interface: happy path, timeout, malformed input

In brownfield retrofits with legacy WMS, the ICD is even harder to close. The WMS may have undocumented field behaviors, hard-coded business logic, or API quirks only discovered during integration testing against the live system. The Target Canada collapse (2013-2015) included a WMS where data interfaces produced incorrect actual results because the real data model diverged from the specification. Lesson: never rely on the WMS vendor’s documentation alone.

Class 1 Cost Estimate

Firm design must produce a Class 1 estimate: ±10% accuracy — the number the capital approval committee will write a check against. Concept phase is Class 4-5 (±30-50%).

Getting from ±50% to ±10% requires resolving:

• All equipment quantities
• All software scope including custom development hours
• All installation labor by trade and site-specific productivity factors
• All subcontractor quotes (firm quotes with schedule commitments, not budgetary)
• Site conditions confirmed by actual survey

If more than 5% of total project value is unresolved open scope, the estimate cannot honestly be represented as Class 1. Carrying forward open items with rough allowances produces a Class 3 estimate with false precision.

The 80/20 Configuration-Customization Split

On any major WCS platform (Dematic iQ, Honeywell Momentum, Swisslog SynQ), roughly 80% of a conventional conveyor-and-sortation WCS can be delivered through out-of-the-box configuration.

The other 20% includes:

• Custom business rules (release logic tied to carrier cutoffs not fitting the standard batch model)
• Non-standard WMS interfaces (legacy SAP with custom IDOC structure, or proprietary WMS built 15 years ago)
• Complex exception handling workflows
• Any third-party system integration (robotics partner software, voice, BMS)

This 20% of custom scope typically consumes 50-60% of the software labor budget. Custom development is slow, hard to test, and surfaces bugs during commissioning when fixes are most expensive.

The antidote is not to avoid customization — some is genuinely required. The antidote is to identify every custom software requirement during firm design, cost it explicitly, and own the decision. Undiscovered customization that surfaces at FAT is how the budget dies.

What Breaks at the Concept-to-Firm Handoff

Simulation assumptions vs. design reality: The simulation ran with assumed product flow and system availability. When the Lead Engineer routes the actual conveyor path around the real column grid, the path requires an additional 80 linear feet and two right-angle transfers. Cost and throughput impact.

Interface gaps: “Standard REST API” in the concept becomes “14-year-old flat-file interface polling every 90 seconds” in firm design. That is a custom middleware project.

Specialty subcontractor scope: If the concept included a robotics pick cell, the actual delivery depends on a sub. When the sub’s software cannot hit throughput spec, the integrator owns the failure but has limited ability to fix it. The ICD is the tool for managing this.

Safe practice: Structured scope review that explicitly challenges every assumption in the concept package at firm design kickoff. Freeze the ICD before releasing any subcontractor RFQs.

Source: 2.6-advanced-automation-design