Firmware campaign planner

How the calendar is computed

The model schedules the campaign the way careful integrators actually run one: a small canary first, then waves that grow by the growth factor until the fleet is covered, with a soak period after every wave before the next one is allowed to start. Each wave consumes maintenance windows; each window fits a whole number of cameras, its length minus the setup overhead divided by the full per-camera path, passes multiplied by minutes per pass. All passes for one camera run back to back inside one window, so no camera is parked on an intermediate build for a week.

How many cameras run at once is the smaller of two caps: engineer capacity, engineers multiplied by cameras in flight per engineer, and the coverage cap, the share of any one site you will allow offline at the same time, applied per site. The planner tells you which cap is binding, because staffing past the coverage cap buys nothing.

The failure allowance is applied per pass. Failures that can be fixed remotely re-enter their own wave as retries and consume window capacity. Failures that need hands on the camera become site visits, costed in engineer hours; multiple hard failures at one site share a visit.

Why pushing faster barely moves the date

Soak time is quantized to the window calendar. A three-day soak at one window a week still costs seven days at every gate, because the next window is the first chance to resume. At the default fleet that quantization is most of the campaign: soak gates alone set a 22-day floor under a 29-day calendar, and no amount of push speed touches it.

The sensitivity table above re-runs the entire model with one input changed, and at the defaults the result is stark. Doubling concurrency saves 7 days, all of it inside the final wave. Halving the soak saves nothing at all, the gate is the week, not the soak. One extra window per week saves 14 days, twice what doubling concurrency buys, because it acts at every gate. When the calendar matters, argue for a second window before you argue for a bigger batch.

What vendors actually publish about timing

Very little, which is why every per-camera figure here is labeled a planning estimate. The numbers that do exist, and what they are worth:

• Axis. The upgrade instructions shipped inside every firmware package say the flash step "may take 1-10 minutes." That excludes transfer queueing and the restart and reconfiguration phases; no end-to-end total is published. An Axis partner integration document uses roughly 5 minutes per device for batch upgrades.
• Hanwha. Network camera manuals state the upgrade "may take a max of 10 minutes," after which the camera restarts.
• Bosch. No per-camera figure at all. The one documented special case is the MIC optics-block upgrade at about 15 minutes per camera.

A defensible planning range for a same-track upgrade is 5 to 10 minutes per camera end to end, stretching to 10 to 20 for major version jumps and older hardware. No vendor and no third party publishes camera firmware failure or retry rates, so the failure input is an assumption you own, not a statistic.

When one camera is more than one pass

The passes input is where campaigns quietly double. Each of the three vendors documents real multi-pass paths:

• Axis recommends stepping through the LTS releases in between when a camera jumps several majors, and the stated path onto a new major runs through the preceding LTS, with on-camera analytics applications reinstalled along the way. A catch-up campaign on a neglected fleet is routinely two or three full passes per camera.
• Bosch gates its firmware history at hard boundaries: a camera below 6.50 must stop at 6.50 before it can accept anything newer, and the oldest platforms need up to three sequential uploads. Downgrading back past that boundary requires a special build from vendor support.
• Hanwha documents mandatory intermediate stops on specific lines, including a three-step migration for its AI series that also clears the cameras' analytics configuration, and one-way versions that cannot be rolled back once installed. Reconfiguration time after a migration belongs in your per-pass minutes.

Current versions, tracks, and support status for all three vendors are collected in the camera firmware tracks and support reference. Credentials and certificates age on their own clock rather than in campaigns, and that recurring load is modeled in the credential and certificate rotation calculator.

Before the first window

The model starts at the first window, and real campaigns have a lead time in front of it that is easy to forget. Axis firmware images sit behind a MyAxis sign-in, so every distinct model and version is a manual acquisition step before anything is scheduled; each download page publishes a SHA-256 checksum, and verifying it is your only defense against a corrupted or wrong-model image at scale. Bosch intermediate builds past certain boundaries come from vendor support rather than the public download area. Budget the acquisition and staging work into your prep hours per wave.

Assumptions and limits

• Per-camera minutes and the failure rate are planning assumptions. The vendor-published anchors are listed above; nothing else is public.
• Windows are billed whole. The crew is booked for the window whether the canary night uses 50 minutes of it or all four hours. Hands-on utilization is a different number from the bill.
• The coverage cap uses the average site size. One flagship site plus nine small branches will bind differently; model those fleets as separate runs.
• The calendar excludes change freezes, the scheduling tail of site visits, and recording-gap accounting during upgrades.
• Rollback is not assumed anywhere: one vendor holds exactly one step back with documented floors, one has a limited recovery image, one documents no camera rollback at all. Plan forward.
• Nothing is transmitted. The calculation runs in the browser and the share link carries the inputs in the URL.

What this looks like across a real fleet

Everything above assumes somebody knows, for every camera, what firmware it runs today, what track it is eligible for, and whether it came back healthy after its window. Across hundreds of cameras that knowledge is the campaign's real bottleneck, and it goes stale the week after the spreadsheet is built. MentatNOC keeps it current on its own: model, firmware, and change history for every camera, staged waves with canaries, and integrity verification before an image ever reaches a device. It never stores or watches your video. The write side is described on the firmware, password, and certificate actions page, and you can walk a staged rollout in the live demo.