Firmware and Hardware Versions: The Substitution Axis Nobody Checks Until Commissioning

Firmware and Hardware Versions: The Substitution Axis Nobody Checks Until Commissioning

A Mitsubishi MELSEC FX3U on a packaging line and a Mitsubishi MELSEC FX5U-32MT/DS sitting in the same slot of the same DIN rail look like they belong to the same family. They share a brand badge, a programming concept, and a documentation tree on the manufacturer's site. Engineers who assume that visual familiarity equals interchangeability learn otherwise at commissioning. The axis that catches them is firmware and hardware revision — the line printed on the side label and reappearing in the GSD file, the engineering software version, and the program portability note. That line decides whether the original program loads, whether the I/O scan time stays inside the cycle budget, and whether the SIL or PL rating on the unit still corresponds to the customer's safety case.

By the aoctrl.com supply-chain desk · Data through September 2026 · Last updated 16 September 2026.

What the firmware / hardware version axis actually contains

Twelve axes make up the substitution framework applied on every cross-reference at aoctrl.com: form and fit outline, dimensions, terminal and interface assignment, electrical, mechanical, function and I/O, firmware and hardware version, communication and protocol, environmental class, ingress and temperature, materials, and certifications and lifecycle. The axis covered here — firmware_version — is the one that hides behind every other axis. A candidate that fails it can still match form, fit, electrical, and protocol on paper; the failure only appears when the engineering software is opened, the program is downloaded, or a SIL or PL rated control loop is exercised.

Four things sit inside this single axis, and a substitution that misses any one of them fails at commissioning:

• Hardware revision suffix. Many modules carry a suffix that is easy to miss: a letter, a number, or a function state code (FS) printed after the base part number. Mitsubishi FX5U-32MT/DS, FX5U-32MT/DS-TS, and FX5U-32MT/ESS share the same base order code but differ in their transistor output sink or source wiring class and in their on-board positioning channel count. The same pattern shows up on Siemens 6ES7 modules (FS 01 versus FS 02 is a real split), on Schneider BMXP34 CPUs, and on Phoenix Contact QUINT power supplies (the original, Plus, and Power-Plus generations share a footprint but not a firmware stack). A quote line that omits the suffix is incomplete; the suffix is part of the MPN.
• Firmware version and the engineering-software compatibility window. Firmware versions ship with explicit engineering-software compatibility notes. GX Works3 releases state which FX5U firmware versions are supported in which project profile; a CPU running firmware outside the supported range refuses to load the project, or loads it with a warning the engineer resolves before download. On drives the equivalent window sits between the inverter firmware and the starter or commissioning software — FR-Configurator for Mitsubishi, SoMove for Schneider, Starter for Siemens G120. A spare drive that arrived with an older firmware image than the engineering-software release profile expects is not interchangeable with a machine built to a newer revision.
• Program portability and the device-description file (GSD / GSDML / EDS / ESI). PROFIBUS GSD files and PROFINET GSDML files are versioned. A remote I/O head that ships with a newer GSDML than the controller's engineering tool expects does not appear in the device catalogue without a manual update, and the bus configuration does not load. The same is true of EtherNet/IP EDS files, IO-Link IODD files, and CANopen EDS files. Cross-references that ignore the device-description version force a commissioning step the buyer did not budget for.
• Function state, cybersecurity advisories, and post-issue patches. Manufacturers publish firmware updates to close advisories. A candidate whose firmware predates an active advisory (Mitsubishi, Siemens, and Schneider all maintain active security advisory pages) is a functional unit but a documented risk. A substitution that ignores this axis can hand the buyer a part that is operationally fine and organizationally non-compliant with their own cybersecurity policy.

Four sub-axes, one axis name. Each one has to be answered before the substitution can be called complete.

Why same brand and same series is the trap

A prompt received in Russian is «Замена блока питания Phoenix QUINT — что подойдёт?» — Replacement for a Phoenix QUINT supply — what fits? — and the same pattern shows up across brands. The buyer assumes that any QUINT, any FX5U, any Sirius 3RT, or any Modicon M340 in the channel will substitute for the one in their cabinet. The brand and the family match. The dimensional fit and the electrical class on the nameplate are likely close enough to slot into the same bracket. The trap is that "the same series" is a marketing category, not a contractual one.

Three concrete traps observed on real substitutions:

• Trap one: the base order code is unchanged, but the function state moved. A Siemens SIMATIC module with the same 6ES7 order code but a higher FS suffix can carry a different default parameter set, a different diagnostic block, or a different failsafe default. The module that arrives is identical on the outside; the project that runs on it is not identical on the inside.
• Trap two: the engineering tool changed its compatibility table. A Mitsubishi GX Works3 project built against FX5U firmware 1.240 does not load onto an FX5U CPU running firmware 1.220 without a project downgrade step the engineer takes explicitly. The hardware is the same. The tool version is the same. The project does not load.
• Trap three: the device-description file shipped with the channel stock is not what the engineering tool expected. A FR-A820 inverter sourced through the independent channel in mid-2026 carried an FR-Configurator profile revision one step ahead of the project on the customer's drive; the customer had to update their engineering tool profile to commission the spare. The spare was mechanically swappable. The commissioning was not.

The pattern holds across brands. Same-series substitution is where the firmware_version axis produces the highest rate of "the part is correct, the project does not load" outcomes. Engineers who build a spare-parts strategy around the series name rather than the order code plus the firmware suffix are budgeting for an avoidable commissioning step.

What is recorded on every quote, and what is deliberately not

The catalog record on aoctrl.com carries a lifecycle_stage field for every part. For Mitsubishi MELSEC FX5U-32MT/DS (catalog id 74255, aiDemandScore 87.46) the lifecycle stage reflects the manufacturer's current positioning; for FX5U-32MT/ESS (id 74256) it reflects the same; for FX5U-80MR/DS (score 87.32) the positioning is again reflected. Across the FX5U family the catalog also lists the FX5-4LC (id 596354, score 87.44), FX5-20PG-D (id 74215, score 87.54), and FX5-20PG-P (id 596435, score 87.54), with the MELSEC iQ-R series units R60DAI8 (score 87.68), R60RD8-G (87.52), R60AD8-G (87.46), R60DAV8 (87.36), and LJ71GF11-T2-CM (87.44) sitting alongside. The lifecycle field is one of the few things committed in writing on a quote because it comes from the manufacturer's published state.

Everything else on the firmware axis — the firmware version actually loaded on the specific unit being supplied, the engineering-software version the customer's project is built against, the GSDML revision, the cybersecurity-advisory status — is surfaced as a question, not a statement. The quote therefore carries three classes of information on this axis:

• What is fixed on the line item. The base order code with its full suffix, the catalog lifecycle stage, the physical condition per line (new surplus, refurbished, or used, with refurbished units backed by bench-test records and used units sold without test warranty unless the quote states otherwise), and the warranty window stated on the quote.
• What is variable per unit. The firmware version printed on the side label of the specific unit being quoted, the GSD or GSDML or EDS revision that ships with it, and any visible sign of an engineering-software compatibility window read off the unit. These are written as observed values, not as commitments.
• What the buyer confirms before order confirmation. The firmware version the customer's project expects, the engineering-software release profile the customer is building against, the device-description revision installed in the customer's tool, and any internal cybersecurity policy that constrains firmware age. None of these are facts about the part; they are facts about the customer's toolchain and project.

A quote that collapses the three classes into a single line — "Mitsubishi FX5U-32MT/DS in stock" — is hiding the axis from the buyer, and the buyer will find it at commissioning.

Where the axis becomes "do not substitute"

The firmware_version axis has a hard stop in three places. The recommendation is to refuse the substitution across any of them, even when every other axis matches.

• Functional safety on the substituted part. A SIL or PL rated relay, drive, or controller carries its safety declaration tied to a specific firmware and hardware combination. The declaration does not transfer by series name. A substitution across a firmware revision where the safety case was not re-issued is, by definition, outside the manufacturer's certified envelope. The phrase used on the report is "customer to re-qualify the SIL or PL case against the new firmware", not "the substitution maintains the rated safety case". That re-qualification sits with the customer's safety lifecycle.
• Program that ships with a hardware-locked licence or authorisation key. A controller, drive, or HMI that holds a licence tied to a hardware serial number does not accept the licence on a different unit even when the firmware matches. The unit that arrives is identical to the original on every axis except the licence key, and the licence key is the axis that breaks the program. The licence rehost is surfaced on the quote as a separate line.
• Firmware older than an active cybersecurity advisory that the customer's policy treats as a blocker. If the customer's policy excludes firmware older than the manufacturer's most recent advisory patch, and the unit available runs that older firmware, the report says so on the quote. The unit ships only after the customer confirms in writing.

Outside these three stops, the firmware_version axis is a documented partial match with explicit UNKNOWN fields, not a refusal.

What the buyer sees on the cross-reference report

The cross-reference report sent with a substitution carries the axis outcomes in a fixed table. For the firmware_version row the report reads, by convention:

A row that lands on UNKNOWN is not a refusal. It is a flag that the buyer's engineering team resolves before commissioning. UNKNOWN is not filled with inference ("probably compatible", "usually works"); the inference is what makes a substitution fail at the worst possible moment — under power, with the line stopped, with the commissioning engineer on the phone.

When the candidate and the original sit on different sides of a firmware window — original on FW 1.240, candidate on FW 1.220 — the report carries an explicit note: a project downgrade or firmware update step is required, and that step is the customer's engineering work. The firmware update file is supplied only when the manufacturer publishes it; no private mirror of any manufacturer's firmware library is hosted.

Verify against the original manufacturer datasheet and your own qualification process before commissioning any substitution recorded as partial match.

How this connects to the wider substitution report

Firmware_version is one of twelve axes. The others do not stop mattering just because this one is the subject of the article. A substitution that passes firmware_version but fails function_io (the candidate lacks the high-speed counter the original used), or fails environmental_class (the candidate is rated for cabinet-internal ambient, not the cabinet-external IP65 environment the original carried), is still a failed substitution. The axis covered here is the one engineers skip most often; it is not the only one that can kill the commission.

For substitutions where the candidate sits in a different series — FX3U to FX5U, or S7-300 to S7-1500, or Sirius 3RT to TeSys D — the firmware_version axis is also where the engineering-software compatibility question moves from "project downgrade" to "full project migration". On FX3U to FX5U the project file does not port: the FX3U uses GX Works2 / GX Developer, the FX5U uses GX Works3, the instruction set is not identical, and the device-description catalogue is separate. The cabinet can stay; the program cannot. Customers who assume the engineering-tool step is a click find themselves rewriting the program at commissioning, and the spare they ordered to keep the line running instead becomes the trigger for a longer stop.

This is also where the cross-reference report's "do not substitute" row can fire on the firmware_version axis alone. If the customer's engineering tool is locked to a release profile their IT department does not update, and the candidate's firmware sits outside that profile, no other axis matters — the project does not load. The report marks that as a fail on the firmware_version axis and stops the recommendation there.

What the buyer controls, and what they do not

The buyer controls four things on this axis, and only four:

• The engineering-software release profile they choose to lock the project to, and the policy that locks it.
• The firmware version committed in their project as the deployment target.
• The device-description revisions installed in their tool, and the policy on how often those are refreshed.
• The internal cybersecurity policy that decides which firmware advisories are blocking and which are advisory.

Everything else on the axis is a fact about the unit supplied: the side-label firmware, the device-description revision that ships with it, the manufacturer's most recent advisory for the family. Those facts are stated on the report; the toolchain and the policy belong to the buyer.

A substitution report that asks the buyer to confirm their toolchain and policy is not being difficult. It is the only way to keep the axis honest. A report that asks for nothing and writes "compatible" does the customer a disservice at the moment the cabinet is powered up.

Compliance and delivery to Russia and the CIS

Substitution decisions and the engineering work that follows from them are the customer's engineering responsibility. aoctrl.com operates as an independent industrial-automation distributor and BOM sourcing desk — not an authorized distributor of any brand listed in the catalog. Units are supplied from independent-channel stock with condition disclosed per line on the quote. The compliance responsibility for placing an assembled panel on a specific market sits with the importer of record.

For buyers in Russia and the CIS the commercial mechanics are independent of the engineering axis covered above. Delivery is arranged under EXW, DAP, or DDP per the terms stated on the quote at the time the order is confirmed; the commercial invoice and packing list travel with the consignment; payment confirmation is per order. We screen end users and end uses before quoting, classify each order, and decline transactions that cannot be screened. Worldwide delivery, including Russia and the CIS, is offered on the same quoting basis as any other destination; specific transit times are stated only on the quote, not on the website.

A practical next step

Send the cross-reference request through the inquiry page with the original MPN (full suffix), the candidate MPN being considered, the engineering-software release profile the project is locked to, and the firmware version the project expects. The cross-reference report comes back with twelve rows, the firmware_version row marked as observed or UNKNOWN per the unit actually being quoted, and the questions the customer's engineering team closes before commissioning. The cabinet can stay; the program and the engineering tool need a documented step. That is the axis, and that is how it is written.

For procurement teams ready to send a BOM, share the line list through /procurement or /baojia and ask for the per-line quote with condition, lifecycle stage, and firmware suffix on each line.

Data Notes

• Catalog evidence (2026-09-16): FX5U-32MT/DS aiDemandScore 87.46 (id 74255); FX5U-32MT/ESS 87.34 (id 74256); FX5U-80MR/DS 87.32; FX5-4LC 87.44 (id 596354); FX5-20PG-D 87.54 (id 74215); FX5-20PG-P 87.54 (id 596435); R60DAI8 87.68; R60RD8-G 87.52; R60AD8-G 87.46; R60DAV8 87.36; LJ71GF11-T2-CM 87.44. Lifecycle stage, suffix, and firmware revision recorded per line on each quote.
• Framework: substitution follows the twelve-axis method published in the cross-reference report template; outcomes recorded per axis as matched, differs, or UNKNOWN.
• Compliance: aoctrl.com is an independent distributor — not an authorized distributor of any brand listed. EAC and TR CU certification is not held and is not issued on behalf of the importer. We screen end users and end uses before quoting and decline transactions that cannot be screened.
• Service actions: cross-reference report on /compare; BOM quotation on /procurement; per-line condition and lifecycle disclosure on /quality; worldwide delivery terms on /shipping-returns; payment mechanics on /terms-of-sale.

FAQ

What is the firmware / hardware version axis in a cross-reference?

It is one of twelve axes applied on every cross-reference at aoctrl.com, alongside form and fit, dimensions, terminal layout, electrical, mechanical, function and I/O, communication and protocol, environmental class, ingress and temperature, materials, and certifications and lifecycle. The axis covers the order-code suffix, the hardware revision or function state code, the firmware version on the side label, the engineering-software release profile the project is built against, the device-description revision (GSD, GSDML, EDS, ESI, IODD), and the cybersecurity-advisory status. A substitution that misses this axis can match every other row and still fail at commissioning.

Why does same-series substitution so often fail at commissioning?

Same-series substitution fails most often on the firmware_version axis because industrial-automation manufacturers revise firmware and hardware within a series to add functions, fix bugs, and close advisories. A spare unit that carries a different firmware or a different suffix than the original can refuse the project, fail the device-description match, or land outside the engineering-software compatibility window. The brand and the family match; the engineering-tool profile does not.

Can an FX3U be replaced with an FX5U without reworking the cabinet?

The cabinet can usually stay because the FX5U fits the same DIN-rail footprint class and the same wiring concept, but the program does not port. The FX3U is built in GX Works2 / GX Developer with the FX3U instruction set; the FX5U is built in GX Works3 with a different instruction set and a different device-description catalogue. A line-by-line port is the engineering work, and the customer's engineering team owns it.

What goes on the cross-reference report under this axis?

The report lists, as observed values, the order code with its full suffix, the hardware revision or function state code on the side label, the firmware version, the device-description revision that ships with the unit, and the manufacturer's most recent cybersecurity advisory for the family. It lists, as buyer-supplied values, the engineering-software release profile the project is locked to, the firmware version the project expects, and the device-description revision installed in the customer's tool. Where a value is not stated by the manufacturer for the unit being supplied, the row reads UNKNOWN; the report does not fill UNKNOWN with inference.

Where does the firmware / hardware version axis refuse a substitution?

The recommendation is to refuse the substitution across three places: a SIL or PL declaration that is not re-issued for the new firmware combination, a hardware-locked licence or authorisation key that the candidate does not carry, and a firmware revision that is older than an active cybersecurity advisory the customer's policy treats as a blocker. Outside these three the report writes a partial match with explicit UNKNOWN fields and the caveat to verify against the original manufacturer datasheet and the customer's own qualification process.

What does the buyer confirm before a substitution is shipped?

Four items: the engineering-software release profile the project is locked to, the firmware version the project expects, the device-description revisions installed in the engineering tool, and the internal cybersecurity policy that decides which advisories are blocking. The unit-side facts are stated on the report; the toolchain and the policy belong to the buyer.

Does aoctrl.com hold EAC or TR CU certification?

No. EAC and TR CU certification is not held, and certification is not issued on behalf of the importer. The compliance responsibility for placing an assembled panel on a specific market sits with the importer of record. We screen end users and end uses before quoting, and decline transactions that cannot be screened.