How Industrial Automation OEMs Are Managing Requirements for Modular Machine Platforms

A filling machine OEM selling into food and beverage, pharmaceutical, and personal care markets does not build one machine. It builds one platform—then configures it into hundreds of variants. The base conveyor, filling head architecture, and HMI framework are shared. But the cleanability requirements, fill volume tolerances, regulatory compliance obligations, and integration protocols vary by customer, market, and geography.

This is the central systems engineering challenge for industrial automation OEMs today: a single mechanical and electrical platform must accommodate wildly diverging customer-specific requirements without spawning a documentation ecosystem so complex it collapses under its own weight.

The companies managing this well are not simply working harder on their Word documents or Excel requirement matrices. They are rethinking the architecture of how requirements are structured, owned, and configured—borrowing from automotive MBSE practice and adapting it for the realities of smaller engineering teams, shorter cycles, and customer-by-customer delivery.

The Core Problem: Platform vs. Variant Requirements

Most industrial automation OEMs understand intuitively that some requirements are platform-level and some are variant-level. The problem is that very few have formalized this distinction in their requirements tooling.

A platform requirement defines something true of every configuration the platform will ever produce. A conveyor section shall withstand 150% of maximum design load. The HMI shall support a minimum screen resolution of 1280x800. These requirements do not change based on customer, market, or regulatory context.

A variant requirement defines something true only under specific conditions. For pharmaceutical configurations, the machine shall comply with 21 CFR Part 11 for electronic records. For ATEX-rated installations, all electrical enclosures shall achieve minimum IP65 rating. These requirements exist because of a specific context—they are conditional on a feature, a market, or a customer class.

When OEMs fail to separate these cleanly, two failure modes emerge. The first is requirement duplication: the same platform-level requirement gets copied into twenty variant specifications, and when the platform changes, engineers have twenty documents to update instead of one. The second is configuration contamination: a variant-specific requirement gets interpreted as a platform requirement and applied universally, causing cost overruns and over-engineering on configurations that didn’t need it.

Both failure modes are expensive. Duplication drives change management costs that compound over time. Configuration contamination drives Bill of Materials cost into machines where the customer is paying for compliance they neither need nor requested.

What Automotive MBSE Gets Right—And Where It Doesn’t Transfer

The automotive industry has been managing platform-variant relationships at scale for two decades. A vehicle platform like Volkswagen’s MQB supports dozens of models, body styles, and powertrain options from a shared requirements and component base. The discipline underpinning this is called product line engineering—and it sits at the heart of mature MBSE practice in automotive.

Product line engineering formalizes two concepts that industrial automation OEMs need. First, feature models: structured representations of what variability is possible on a platform, including which features are mandatory, which are optional, and which are mutually exclusive. A machine cannot be simultaneously ATEX-rated and specified for clean-room ISO Class 5 environments without explicit engineering review—that constraint should be captured in the feature model, not discovered during commissioning.

Second, variation points: specific locations in the requirements architecture where variant-level requirements attach to platform-level requirements. A variation point for “electrical enclosure rating” would have the platform baseline requirement attached at the top, with variant-specific derivations hanging below, each tagged to the feature or market condition that activates them.

The challenge is that automotive MBSE as practiced in large OEMs involves dedicated systems engineering organizations, multi-year program cycles, and toolchains—IBM DOORS Next, Siemens Polarion, PTC Integrity—that are licensed and implemented at enterprise scale. An industrial automation OEM with a 15-person engineering team and a 6-month customer program timeline cannot operate that model.

What actually transfers is the conceptual discipline. The tools and process overhead do not have to follow verbatim. Automation OEMs need the underlying logic—platform/variant separation, feature-conditioned requirements, constraint enforcement—implemented in tooling that their actual teams can operate at their actual pace.

Configuration Management: Where the Complexity Lives

When an automation OEM receives a customer order, a configuration is selected or assembled from the platform’s option set. That configuration has to be traced back to a specific set of requirements, a specific set of design decisions, and a specific set of test obligations. This is configuration management—and for modular machine platforms, it is where most of the systems engineering complexity concentrates.

The traditional approach is to create a customer-specific requirements document that describes the machine as configured. Engineers pull relevant sections from various platform and variant specification documents, paste them together, and send the resulting document to the customer for approval. The problem is immediately visible: that document is now disconnected from the living platform specification. When the platform changes, no automated mechanism exists to propagate the change into customer-specific documents. Engineers either do it manually—slowly, inconsistently—or they don’t do it at all.

A more disciplined approach models configuration as a selection event, not a copy event. Instead of copying requirements into a new document, the engineer selects the applicable features and markets, and the configuration-management system assembles the applicable requirements by reference—pulling from platform requirements, adding the activated variant requirements, and suppressing the deactivated ones. The customer-specific view is a filtered view of a shared requirement model, not a standalone document.

This distinction—by reference versus by copy—has significant downstream consequences. A by-reference architecture means a platform requirement change propagates automatically to every configuration that includes it. The systems engineer reviews the change impact, approves it, and all affected customer configurations update. A by-copy architecture means the same change has to be manually applied to every affected document. In a program with forty active customer configurations, this is not a theoretical risk. It is a recurring failure mode.

How Requirements Platforms Are Evolving to Support This

Legacy requirements tools were designed around document management. IBM DOORS, in its original form, treated a module as a structured document—a flat list of requirements with attributes. Traceability links were bolt-on features. Variant management was typically handled through document variants or through manual attribute filtering. These are workable approaches for single-product programs, but they strain visibly under the weight of multi-variant platform programs.

Jama Connect and codeBeamer have both made meaningful progress on requirements reuse and configurability. codeBeamer in particular has invested in product line engineering support, including feature models and variant branching, which makes it a credible choice for complex platform programs. These are real capabilities and should be evaluated seriously by OEMs with the organizational maturity and budget to deploy them at enterprise scale.

What has changed more recently is the emergence of tools designed from the ground up around graph-based requirement models rather than document-based ones. In a graph model, requirements are nodes with explicit relationships—derivation, containment, conflict, dependency—rather than entries in a structured document. Variant configuration becomes a relationship problem: which nodes are active for a given feature configuration, and how do relationships between nodes constrain what configurations are valid?

Flow Engineering has built its platform explicitly on this graph-based approach, designed for hardware and systems engineering teams who need product line engineering capability without enterprise-scale implementation overhead. Its model of requirements as interconnected entities—where platform requirements, variant requirements, and design decisions are all first-class nodes in a connected model—maps directly onto the platform-variant separation that modular automation OEMs need. Change impact analysis, which in a document-based tool requires manual cross-reference, surfaces automatically in a connected model: every node affected by a proposed change is visible before the change is committed.

For automation OEMs who have been managing variant requirements by maintaining parallel documents or by using attribute filters in legacy tools, the shift to a connected graph model represents a significant process change. But it is the architecture that matches the actual structure of the problem.

Practical Implications for Automation OEM Engineering Teams

The gap between where most industrial automation OEMs are today and where mature platform requirements management looks like is real, but it is not unbridgeable. Several specific practices close the gap progressively.

Start with explicit platform/variant tagging. Even before changing tools, every existing requirement should be tagged as platform-level or variant-level. This is a clarifying exercise as much as a data exercise—it forces engineering and product management to agree on what is truly common. The arguments that surface during tagging reveal the configuration ambiguity that is already creating errors downstream.

Define your feature model before your variant documents. Document the option set—markets, regulatory contexts, customer classes, mechanical configurations—as a structured model before writing variant-specific requirements against it. A feature model is the control structure for all the variability that follows. Without it, variant requirements are written ad hoc, and the resulting structure has no internal consistency.

Replace copy-based configuration with reference-based configuration. This is a tooling and process change, but the process change matters as much as the tooling. Engineers who have been copying requirements into customer documents need to understand why that practice generates downstream risk—not just that the new tool works differently.

Apply change impact analysis before approving platform changes. Every proposed change to a platform requirement should generate an explicit list of affected configurations before approval. This is a discipline, not just a feature. OEMs that have this practice catch configuration errors that would otherwise surface during factory acceptance testing or, worse, at the customer site.

Build traceability incrementally, not retrospectively. One of the recurring mistakes automation OEMs make when adopting better requirements tooling is attempting to retroactively trace everything before getting value from the new system. Traceability should be built forward: start with new programs and new configurations, capture the links as decisions are made, and let the historical artifacts remain as reference documents rather than forcing them into a model they were not designed to support.

Honest Assessment

Modular platform programs are not inherently harder to engineer than single-product programs. They are harder to document and manage when the documentation and management structures are designed for single-product thinking. The engineering discipline—separating what is common from what varies, modeling constraints between options, managing configuration by reference rather than by copy—is learnable and implementable by engineering teams that are nowhere near automotive scale.

The industrial automation sector is approximately a decade behind automotive in applying these disciplines systematically. The gap is closing because the cost of not closing it is now visible: platforms with forty variants generate configuration errors at acceptance testing, and those errors are expensive in industries where a machine that cannot be commissioned is a machine that cannot be invoiced.

Tools that support product line engineering concepts—whether at enterprise scale from established vendors or in focused modern platforms—give engineering teams the architecture they need to manage that complexity. The teams that implement this discipline now will be able to scale their platforms in ways that teams still managing variant requirements through document proliferation will not.

The platform is not the problem. The structure you use to manage what the platform means, for each customer, in each context, is where the work lives.