Two Industrial Parts Look Identical — The 12 Axes That Decide Whether They Interchange

Two Industrial Parts Look Identical — The 12 Axes That Decide Whether They Interchange

A defensible cross-reference for two industrial automation parts checks twelve axes — outline and mounting, dimensions, terminal and interface assignment, electrical ratings, function and I/O, firmware and hardware version, communication protocol, mechanical parameters, environmental class, ingress protection and temperature range, materials and construction, and certification and lifecycle status — and reports each axis as matched, differs, or unknown. The honest answer on at least one axis is almost always "unknown," because the data sits inside a manufacturer's datasheet, a buyer's project record, or a machine's documentation, and a sourcing desk cannot invent it. What an independent distributor can do is run the twelve-axis comparison, name the axes that could not be verified, and leave the selection decision with the buyer's engineering team. Buyers searching for «Аналог контроллера — как проверить, что подходит, а не просто похож?» and the English equivalent are really asking for that process.

Why "They Look the Same" Is Not a Test

A control cabinet has a Siemens Sirius 3RT contactor that has been in service for fourteen years. The user finds a third-party unit on a surplus list, takes a photograph, and the two are visually identical — same outline, same DIN-rail mounting, same terminal arrangement at a glance, same front-face marking style. The first instinct is to treat them as the same part. That instinct is wrong in industrial automation more often than it is right.

The problem is not the photograph. The problem is that industrial parts are described by a stack of attributes, and the visible ones are a small fraction of the total. A photo tells you about outline, mounting, terminal arrangement on the front face, and the marking style on the label. It does not tell you about the contact rating, the coil voltage tolerance, the mechanical life in operations, the certification scope the manufacturer filed the part under, the firmware generation if the part is programmable, the ambient temperature the part was qualified for, or whether the manufacturer has issued a product-change notification since the unit in your cabinet was made. Each of those is an axis. A cross-reference is the document that walks through them.

In maintenance work, the assumption that two visually identical parts interchange costs money. The cost is rarely the part itself; it is the cabinet rework when the substitute turns out to need a wider DIN-rail slot, or the diagnostic time when a contactor with a 24 VDC coil ends up wired to 230 VAC, or the line stoppage when a sensor rated to IP67 is fitted into an outdoor panel and fails its first heavy rain. The trade-off in cross-reference work is not between "yes" and "no" — it is between a documented comparison with its unknowns named, and a guess that feels safe until commissioning.

The Twelve Axes and What Each One Actually Compares

The framework used here is not new; it is the routine that an engineering team applies during a substitution review, written down so a sourcing desk can produce it consistently. There are twelve axes. Each is checked against the original manufacturer's datasheet, the catalog record in front of the desk, and any machine-specific documentation the buyer can supply. Where the data is not publicly published, the axis is reported as unknown rather than guessed. The buyer is always told to verify against the original manufacturer datasheet and your own qualification process.

Outline and mounting covers the form-fit envelope — overall length, width and height, the mounting method (DIN rail, panel cut-out, screw, rack), the module width in slot units, and the space required for heat dissipation. If the mounting method differs, the comparison stops: the part cannot be installed without mechanical rework and the verdict is "differs" without further work.

Dimensions checks the same envelope in finer detail — installation hole spacing, the depth including the wiring space behind the device, and the weight on the rail. Two parts that fit the same outline can still differ in installation hole position, and that single difference forces a panel rework.

Terminal and interface assignment is where the most expensive errors happen. The terminal numbering, the screw versus spring versus push-in terminal type, the position of the supply terminals, the I/O channel address layout, and the front connector type are all checked here. A different terminal sequence on a similarly shaped module is not a cosmetic issue — it is a wiring-schedule difference that can put 24 V across a 230 V coil or reverse the rotation of a three-phase motor.

Electrical parameters covers supply voltage and tolerance, per-channel current, total current, output voltage level, surge and short-circuit protection, and dissipation. Mismatches here are the second-largest source of cabinet rework, after terminal-sequence mismatches.

Function and I/O specification checks channel count and direction (digital in, digital out, analog in, analog out), signal type, resolution and accuracy, isolation, and any module-specific function such as high-speed counting or PTO. A module with more channels does not necessarily replace one with fewer; if the original uses a high-speed counter that the substitute does not provide, the substitution fails on this axis even if every other axis reads "matched."

Firmware, hardware version and engineering-software compatibility is the axis that buyers ask about most often and that a sourcing desk can verify least often. The hardware version, the function state suffix, the firmware generation, the engineering-software release that supports it, and the device-description files (GSD, GSDML, EDS, ESI and the like) all live in the manufacturer's records and in the buyer's project archive. When those are not available to the desk, the axis is reported as unknown and the buyer is told to verify against the original manufacturer datasheet.

Communication and protocol covers the fieldbus or industrial Ethernet type, the port count and physical interface, the supported data rate, the maximum station count or topology, and the role the device plays in the network (master, slave, head station). A device that speaks PROFINET cannot replace a PROFIBUS slave without a network reconfiguration; a device that supports only Modbus TCP cannot replace one that carried EtherCAT on the same physical connector.

Mechanical parameters covers terminal torque, permissible conductor cross-section, mechanical life in operations, mating cycles, and latch or locking hardware. These rarely cause a substitution to fail outright, but they shape the maintenance interval the buyer should plan for.

Environmental class and EMC covers the operating temperature range, humidity tolerance, vibration and shock resistance, EMC immunity and emission class, pollution degree, and installation altitude. A part rated for an industrial environment should not silently replace one rated only for a commercial environment.

Ingress protection and temperature range is reported separately because a part's IP rating is specific to its installed configuration — the same device can carry different ratings when panel-mounted versus free-standing. The work here is to confirm that the IP claim and the temperature range both apply to the configuration the buyer is actually building.

Materials and construction covers contact plating, housing material and flammability rating (UL94 class), sealing material, conformal coating on PCBs, and RoHS/REACH status. Two sensors with the same housing can have very different plating lives if one uses gold-flash contacts and the other uses tin.

Certifications and lifecycle covers the CE, UL, CSA and similar declarations with their actual file numbers where they exist, any functional-safety rating (SIL or PL) the manufacturer has stated, the lifecycle status (current, phased out, end-of-life), and the buyer's market-entry requirements. This axis is the one that most often has to be reported as "not stated by manufacturer" because datasheets vary widely in what they publish, and the buyer's local market requirements are not the desk's to evaluate.

The framework is deliberately exhaustive. If an axis is left out, it silently becomes "matched" by omission, which is the failure mode this routine is designed to prevent.

Matched, Differs, or Unknown: The Three Verdicts

Every axis on a cross-reference table carries one of three verdicts, and the buyer should not accept a table that uses only "yes." Matched means the datasheet and the available documentation show the same figure on both sides. Differs means the figures differ in a way that matters to the application, and the desk states the difference. Unknown means the desk could not confirm the figure from publicly available material and the buyer is being told to verify it on their side.

The "unknown" verdict is the one that distinguishes a real cross-reference from a marketing claim. A sales desk that returns "compatible on every axis" has either invented data it does not have or has silently treated "unknown" as "matched." In a twelve-axis comparison on a typical industrial module, one to three axes are usually unknown to the desk — most often firmware version, functional-safety certification scope, and the buyer's local market requirements. The honest document names them.

Buyers searching for «Как проверить, что аналог действительно подходит, а не просто похож?» are really asking whether the desk will tell them the unknown axes. The answer to that question is what separates an independent sourcing desk from a franchised channel that has an interest in selling a current-production substitute.

A Worked Cross-Reference, Axis by Axis

The example below is illustrative rather than a recommendation. It uses a real industrial automation cross-reference pattern — a same-brand, same-series question where two modules from the same family carry different suffixes — and walks through the twelve axes.

The candidate question: a buyer has an S7-300 digital-input module in service and finds a same-series module offered as a substitute. The two modules share an outline and a terminal layout at first glance; the suffix codes differ by a single digit. The desk runs the twelve-axis comparison.

On outline and mounting, both modules share the S7-300 SM 32 footprint and the same DIN-rail mounting, so the axis reads matched against the S7-300 system manual.

On dimensions, the depth and the height are identical for the SM 32 family, so this axis reads matched.

On terminal and interface assignment, the front connector and the pin assignment are identical across the SM 32 family — matched.

On electrical parameters, the supply voltage and the per-channel current rating are within the family specification — matched.

On function and I/O specification, both modules are 16-channel digital inputs — matched.

On firmware, hardware version and engineering-software compatibility, the suffix code indicates a different function-state or hardware revision. The desk can read the suffix from the labeling but cannot confirm from public documentation whether the firmware on the candidate is compatible with the buyer's STEP 7 project. This axis reads unknown, and the buyer is told to verify against the original manufacturer datasheet.

On communication and protocol, both modules speak the same backplane bus within the S7-300 rack — matched.

On mechanical parameters, terminal torque and conductor cross-section limits are identical for the family — matched.

On environmental class and EMC, the family carries the same industrial rating — matched.

On ingress protection and temperature range, both modules carry the same IP20 and 0–60 °C industrial rating — matched.

On materials and construction, the housing material and PCB finish are not publicly differentiated at the module level — unknown.

On certifications and lifecycle, the lifecycle status of the candidate module is documented in the S7-300 product-change-notification history; whether the buyer's project requires a specific revision is a project-side decision — unknown.

The table for the buyer, then, is not "compatible." It is eleven axes reported and one marked unknown, with the unknown axes flagged for buyer-side verification. That is what a cross-reference document looks like in practice.

When the Right Answer Is "Do Not Substitute"

Not every cross-reference leads to a substitution. There are situations where the honest answer is to keep sourcing the original, or to treat the change as a redesign rather than a replacement, and a sourcing desk should say so. None of these cases fall inside the cross-reference framework above; each is a reason to refuse the substitution and stay with the original part.

The first is when a part participates in a function that the manufacturer's safety validation process has to certify. We do not run a cross-reference on parts that participate in emergency-stop circuits, safety light curtains, safety relay chains, or category-rated stop functions — those substitutions belong inside the machine's safety validation process, and the desk's role is to keep finding the original part, not to propose an alternative. The second is certified assembly scope. A part that sits inside a type-tested assembly — a UL-listed panel, a CE-marked machine, an Ex-rated enclosure — cannot be substituted without changing the assembly's certification scope. The axis that catches this is certifications and lifecycle, and the verdict is "differs" even when every other axis is matched.

The third is documentation pinned to a specific part. Some machines carry a spare-parts list in their manual that names a specific module by order code; the documentation itself is part of the machine's compliance record, and changing the module is a documented change rather than a substitution.

The fourth is the case where the buyer cannot verify the unknown axes. If the desk has named the unknown axes and the buyer has no project record to confirm them, the substitution is unsupported and should not proceed. The procurement action in that case is to source the original part, not to substitute on a guess.

These four situations are where the cross-reference framework produces a "do not substitute" outcome, and they are the situations in which a sourcing desk that returns "compatible" on every axis would be doing the buyer a disservice.

What a Written Cross-Reference Report Contains — and What It Cannot Certify

A cross-reference document produced for a BOM line is a line-by-line comparison. It names the candidate part, the original part, the twelve axes, the verdict on each, and the source for the verdict. The source is a manufacturer datasheet, the catalog record in front of the desk, or the buyer's own project documentation. Where the source is the desk's own catalog record, the document states that; where it is a third-party source the buyer provided, the document states that as well.

What the document does not contain is a compatibility certificate. An independent distributor does not certify that a substitute will work in a specific application, because the certification rests on the buyer's engineering process and on the manufacturer's own datasheet. A document that says "compatible" without an axis-by-axis breakdown is not a cross-reference; it is a marketing claim, and the buyer should treat it as one.

The document also does not contain a statement of functional-safety integrity or a confirmation of the buyer's local market-entry requirements. These belong to the buyer's quality system, to the certifying body, and to the buyer's import side respectively. The desk's job is to keep them out of the document so the document stays honest.

How to Send a Cross-Reference Request

Send the original part number, the candidate part number if there is one, the machine or the project the part is being considered for, and any documentation you have that names a required revision or function state. If you have only the candidate part number and the machine, that is also workable — the desk will work the comparison back from there. The request goes to /compare, with supporting material attached through /inquiry for lines that also need sourcing. For buyers in Moscow, the Russian regions or the CIS, the cross-reference table ships with the same line-by-line structure and the same per-line condition disclosure that a BOM sourced through /procurement would carry; the trade terms — EXW, FCA, DAP or DDP — appear on the quotation rather than as a general policy, and Incoterms, customs clearance and the screening posture follow the wording on the /shipping-returns page.

A useful cross-reference request includes four pieces of information: the original part's full order code including suffixes, the candidate part's full order code if you have one, the application environment (cabinet, panel, outdoor, washdown), and any documentation that pins a revision or a function state. Without those four, the desk will return a comparison that is correct on the public axes and leaves the project-specific ones as unknown, which is still a useful document but is not the document a buyer with a tight project record would accept.

The desk returns a line-by-line table with the twelve axes, the source for each verdict, and the axes that could not be verified. The desk does not return a "yes" or "no" — the desk returns the comparison, and the buyer's engineering team returns the decision. The cross-reference is a tool for that decision; it is not a substitute for it.

Send us your BOM through /inquiry when a comparison has to run alongside sourcing; the cross-reference table arrives back on the same quote. For buyers working on a single line at a time, the request can start at /compare with the two order codes and the machine name attached.

By the AO Control sourcing desk. As of September 2026.

Data Notes

The framework and the worked example in this article draw on aoctrl's internal twelve-axis substitution framework, which is shared with buyers as part of cross-reference work. Public references for the framework's axes and the data points they cover include the S7-300 system manual and SM 32 family documentation maintained by Siemens on its product support portal, the Phoenix Contact QUINT power-supply family datasheet, the Schneider TeSys D contactor catalog, and the Omron E5CC/E5EC temperature-controller datasheet for the parameter conventions used in industrial cross-reference tables. Lifecycle status references follow each manufacturer's published product-change-notification history; per-line condition disclosure (new, new surplus, refurbished, used) is reported on each quotation. Cross-references are not a substitute for the manufacturer's own datasheet and the buyer's qualification process; the final selection decision sits with the buyer's engineering team, and the desk reports axes that could not be verified rather than filling them in.

FAQ

Is a cross-reference the same as a guaranteed replacement?

No. A cross-reference is a documented comparison, not a warranty of interchangeability. Two parts can look identical and still differ in firmware, terminal assignment, environmental rating or certification scope. Every comparison published here names the axes that were verified and the ones that were not, and the final substitution decision rests with the buyer's engineering team. The desk reports the comparison; the buyer returns the decision.

Why can't a sourcing desk just say whether two parts are compatible?

Because the honest answer usually contains the word "unknown" on at least one axis. A desk can confirm outline, mounting and terminal layout from a manufacturer datasheet; it cannot confirm that the buyer's program will run on a different controller family, or that the buyer's certification scope still holds after the swap. Naming the unknown axes is the point of the exercise, and the buyer is always told to verify against the original manufacturer datasheet.

What are the twelve axes a cross-reference actually compares?

Outline and mounting, dimensions, terminal and interface assignment, electrical parameters, function and I/O specification, firmware and hardware version, communication protocol, mechanical parameters, environmental class, ingress protection and temperature range, materials and construction, and certifications and lifecycle. Each is reported as matched, differs, or unknown; omitting an axis would silently imply it matches.

Do same-brand, same-series parts always interchange?

Not necessarily, and this is one of the most expensive assumptions in industrial maintenance. Within one family, suffix codes encode function state, I/O configuration, supply voltage and firmware generation. Two modules from the same series can share an outline and share nothing else that matters.

When should a substitution not be attempted at all?

When the part participates in a function the manufacturer's safety validation has to certify, when it sits inside a certified assembly whose scope would change, when the machine's documentation pins the design to a specific part, or when the substitute cannot be verified on the axes the application depends on. In those cases the right action is to keep sourcing the original, or to treat the change as a redesign rather than a replacement.

Who is responsible if a substitute does not work in the cabinet?

The selection decision and its validation sit with the buyer's engineering process; that is why every comparison ends with a verification instruction rather than a conclusion. What an independent distributor is responsible for is that the goods match the condition and identity stated on the quotation, which is what per-line condition disclosure and pre-dispatch photographs exist to document. Buyers searching for «Кто отвечает, если замена не заработала?» are really asking where the boundary sits — it sits with whoever made the substitution decision, supported by the documentation the desk supplied.

How do I send a cross-reference request to aoctrl?

Send the original part's full order code, the candidate part's full order code if there is one, the application environment and any documentation that pins a revision or a function state. The request can be started at /compare, with supporting material attached through /inquiry. The desk returns a twelve-axis table with the source for each verdict and the axes that could not be verified; trade terms for shipment to Russia or the CIS appear on the quotation rather than as a published policy.