Systems Engineering in the Unsexy Tier 2 Supply Chain

Freudenberg Sealing Technologies shows what it actually costs to satisfy OEM requirements, functional safety standards, and customer-specific constraints — all at once, as a component supplier.

There is no glamour in seals. No analyst breathlessly covers elastomer lip geometries. No conference keynote celebrates advances in PTFE gasket compounds. And yet, when a shaft seal fails in an EV battery coolant loop, the thermal runaway conversation begins very quickly, and the ISO 26262 audit trail points directly to the component supplier.

Freudenberg Sealing Technologies — headquartered in Weinheim, Germany, with manufacturing across four continents — makes exactly these components. Radial shaft seals, O-rings, structural gaskets, fluid-handling membranes, filtration media. Products measured in millimeters that appear in automotive powertrains, aircraft hydraulics, industrial compressors, and offshore energy systems. The company operates as a classic Tier 2 and Tier 3 supplier, selling primarily to Tier 1 systems integrators and OEM direct-supply programs when application criticality warrants it.

What Freudenberg represents, more broadly, is a category of industrial organization that systems engineering literature largely ignores: the component supplier that must simultaneously manage requirements from a dozen customers, prove compliance to safety standards it did not author, and maintain quality certifications that demand documented traceability — all while engineering objects whose market price is often measured in euros per unit.

This is the unsexy tier. It is also where a significant share of requirements engineering actually happens.

The Cascade Problem

OEM requirements engineering produces large, structured requirement sets — vehicle-level functional requirements decomposed through system architectures into subsystem specifications, which eventually reach Tier 1 suppliers as detailed technical specifications. Tier 1 organizations, in turn, derive their own component-level requirements, adding interface constraints, qualification test protocols, and application-specific tolerances.

By the time a requirement reaches Freudenberg, it has been transformed at least twice. The original OEM functional requirement — “the powertrain cooling system shall maintain fluid temperature within X°C under all operating conditions” — has become something like a specific maximum leak rate at a specific pressure and temperature range, with a specific FMEA severity rating, attached to a drawing reference, embedded in a Tier 1 customer’s proprietary requirements management system, exported as a PDF or an Excel attachment.

This is not an exaggeration. In practice, Freudenberg’s engineering teams receive requirements in at least the following formats: DOORS-exported PDFs, ReqIF files that require tool-specific import configurations, spreadsheet matrices with embedded rationale columns, customer-portal documents with revision control that doesn’t match internal versioning, and for some European OEM programs, Word documents with tracked changes.

Each of these represents a different customer’s requirements management maturity. The Tier 2 supplier has no authority over any of them. The engineering team’s job is to absorb all of them and produce something coherent.

Functional Safety at the Component Level

ISO 26262, the automotive functional safety standard, explicitly extends its scope to components. Part 8, Section 13 covers the qualification of hardware components not developed to the standard — including purchased components from suppliers who may not have participated in the original safety analysis. Part 5 covers hardware development requirements that propagate to component specifications through the safety concept.

For a sealing component appearing in a safety-relevant context — a braking system actuator, a steering rack seal, a battery coolant circuit in a BEV — the Automotive Safety Integrity Level (ASIL) assigned to the function propagates to the component’s technical requirements. The Freudenberg engineering team responsible for that component must understand the ASIL context, trace their component’s failure modes to the system FMEA, demonstrate that failure rates meet the hardware architectural metrics, and maintain this documentation across the component’s lifecycle.

This is a non-trivial burden for a component supplier. The engineers who design and qualify these seals are specialists in tribology, elastomer chemistry, and manufacturing process control — not in safety case construction. Yet the safety case demands their work be structured in a way that supports audit by someone who may never touch an elastomer compound.

The practical result is that Freudenberg, like most sophisticated Tier 2 suppliers, maintains a parallel requirements and safety documentation structure. The engineering work proceeds in one domain; the compliance documentation is assembled, often manually, in another. The gap between these two activities is where errors propagate and where audit findings occur.

The IATF 16949 Layer

ISO 9001 provides the quality management foundation. IATF 16949 adds the automotive sector supplement — and then each major OEM adds its own Customer-Specific Requirements (CSRs) on top of that. The Automotive Industry Action Group (AIAG) maintains reference materials, but the CSRs themselves are issued independently by GM, Ford, Stellantis, BMW, Volkswagen Group, and others, and they do not harmonize neatly.

For a Tier 2 supplier serving multiple OEM-derived programs through multiple Tier 1 customers, the CSR landscape looks something like this: requirements that conflict at the process level (different OEMs mandate different PPAP documentation elements for the same part category), requirements that conflict at the technical level (different acceptance criteria for the same test), and requirements that reference standards which themselves have been revised since the CSR was written.

Managing this is primarily a documentation and change management problem. When a customer issues a CSR revision, the impact must be assessed across every active program where that customer’s requirements apply. When two customers’ requirements conflict on a specification parameter, the engineering team must decide how to resolve it — which typically means satisfying the more stringent requirement, documenting the decision, and getting customer acknowledgment that both requirements are met.

None of this requires exotic systems engineering methodology. It requires disciplined requirements traceability: knowing exactly which customer requirement maps to which internal specification, which test protocol, which manufacturing process parameter, and which quality record. At the volume Freudenberg operates — hundreds of active programs across automotive, aerospace, and energy — maintaining that traceability manually is not sustainable. Maintaining it in disconnected spreadsheets is functionally equivalent to not maintaining it.

The Traceability-Without-Authority Problem

The distinctive challenge for Tier 2 suppliers is what might be called traceability without authority. Unlike an OEM systems engineering organization, which owns its requirements and can impose structure on them, a Tier 2 supplier must build traceability to requirements it received externally, cannot modify, and must track across revisions it does not control.

This has specific practical implications:

Requirement stability is not guaranteed. Customer requirements change through program development. The Tier 2 supplier may receive multiple revisions of a specification, sometimes with inadequate change documentation. The internal requirement derived from the customer requirement must be updated, but the original customer requirement document is not under the supplier’s configuration control.

Conflict resolution is undocumented. When two customers impose conflicting constraints, the engineering decision that resolves the conflict lives in someone’s email, in a meeting note, or in institutional memory. This is recoverable during the original program but becomes a liability during a warranty investigation or audit years later.

ASIL context is often incomplete. A component sold into a safety-relevant application may arrive with a safety requirement but without the full ASIL decomposition rationale. The Tier 2 supplier is expected to implement the requirement but may not have sufficient context to assess whether their implementation actually satisfies the safety intent.

These are structural problems. They exist because the automotive supply chain was not designed as an integrated systems engineering environment. It was designed as a series of commercial relationships, each with its own documentation conventions, each optimizing locally.

What Sophisticated Tier 2 Organizations Do Differently

The organizations that manage this environment effectively share a few characteristics that are worth naming.

They maintain an internal requirements model that is distinct from — but traceable to — the customer requirements they receive. Rather than working directly in customer-provided documents, they derive internal specifications that they own and control, with explicit links to the source customer requirement and revision.

They treat change management as an engineering process, not an administrative task. When a customer requirement changes, the impact assessment is performed systematically, not as a side conversation. The internal requirements that derived from the changed requirement are identified, reviewed, and updated with documented rationale.

They invest in conflict identification early in program intake. Before a new customer requirement set is absorbed into the internal system, it is reviewed against existing obligations — other customers’ requirements, internal design standards, certified process parameters — to surface conflicts before they become embedded in product designs.

And they increasingly use tooling that supports bidirectional traceability across multiple concurrent requirement streams. This is the area where the gap between best practice and common practice is widest. Most Tier 2 organizations still manage this in Excel or in document management systems that handle version control but not semantic traceability. Some have adopted IBM DOORS or DOORS Next, which handles requirements at scale but carries significant configuration and licensing overhead that is difficult to justify at the Tier 2 level where program margins are thin. Jama Connect provides better usability and more modern collaboration features but is similarly positioned for larger systems-level programs rather than component-level requirements management across many short-cycle programs.

Tools designed around connected, graph-based requirement models — where customer requirements, internal specifications, test protocols, and safety artifacts are nodes in a traceable network rather than rows in a document — address this structural problem more directly. Flow Engineering, built for exactly this kind of multi-stream, multi-stakeholder requirements environment, represents the direction this market is moving: away from document management toward requirement graph management, where the relationships between requirements are as important as the requirements themselves.

An Honest Assessment

Freudenberg Sealing Technologies is a well-run engineering organization. They carry IATF 16949 certification, supply to Tier 1 customers with demanding quality systems, and manage product liability across genuinely safety-critical applications. None of that happens accidentally.

But the challenges they face are not unique to them. They are structural features of the Tier 2 supply chain that apply to every sophisticated component supplier serving automotive, aerospace, or energy markets: requirements received in inconsistent formats, safety obligations that extend to components, quality standards that layer customer-specific variations on top of each other, and traceability responsibilities that cannot be met with document-centric tools.

The systems engineering literature focuses on the OEM and Tier 1 level because that is where the architecture decisions happen. The hard daily work of making those decisions traceable, auditable, and manufacturable happens one tier down, in companies whose products cost a few euros and whose documentation liability is measured in millions.

That tier deserves better tooling, better methodology, and more direct attention than it typically receives.