ABB: Systems Engineering for Electrification and Industrial Automation Products at Scale

ABB operates at a scale that makes most industrial technology companies look boutique. With revenues exceeding $35 billion annually, operations in more than 100 countries, and a product portfolio that spans residential circuit breakers, 20-megawatt variable frequency drives, surgical-precision collaborative robots, and distributed control systems for oil refineries, the company faces systems engineering challenges that few organizations can meaningfully compare to.

This is not a profile of ABB’s corporate strategy. It is an analysis of the engineering problem ABB actually lives with: how do you manage product requirements — and the functional safety obligations attached to them — across four divisions whose products have almost nothing in common except the word “industrial”?

Four Divisions, Four Engineering Realities

ABB’s current structure organizes the company into four business areas: Electrification, Motion, Process Automation, and Robotics & Discrete Automation. Each division has its own product logic, customer base, certification landscape, and development cadence.

Electrification covers the hardware most people associate with ABB’s heritage: switchgear, circuit breakers, surge protection devices, EV charging infrastructure, and low- to medium-voltage distribution equipment. Products here tend to have long market lives — some low-voltage switchgear families stay in production for 20 to 30 years — and are certified to standards like IEC 60947 (low-voltage switchgear), IEC 62271 (high-voltage switchgear), and an increasing array of functional safety standards as protection devices become embedded in safety-critical electrical systems.

Motion produces electric motors, generators, drives, and associated software. The variable frequency drive product line alone spans single-phase fractional-horsepower units used in HVAC systems to multi-megawatt marine and mining drive systems. Development cycles vary accordingly. A new drive platform for process industries might take four to six years from concept to market; a software update for an existing drive family might ship quarterly. IEC 61800-5-2 — the functional safety standard for power drive systems — governs how Motion products integrate into safety functions, and it has mandatory hooks back into IEC 61508 for the underlying safety instrumented system context.

Process Automation delivers distributed control systems (DCS), instrumentation, analytical measurement, and the associated engineering environments. ABB’s System 800xA and Ability Symphony Plus platforms are deployed in nuclear plants, petrochemical facilities, water treatment infrastructure, and pharmaceutical manufacturing — environments where IEC 61511 (functional safety for process industry sector, itself derived from IEC 61508) and sector-specific nuclear standards govern every design decision. Requirements here are inseparable from hazard and risk assessments: a process control requirement for a safety instrumented function cannot be written or changed without cascading effects on the associated Safety Integrity Level (SIL) claim.

Robotics & Discrete Automation produces industrial robots — the iconic IRB series arm manipulators — collaborative robots (cobots), machine vision systems, and software platforms for robot programming and fleet management. The robotics division operates under IEC 62061 and ISO 10218, which together govern functional safety for machinery and robots. As ABB has pushed into human-robot collaboration applications with its GoFa and SWIFTI cobot lines, the safety requirements for those products have become qualitatively different from traditional caged industrial robots: the hazard analysis now includes proximity to unprotected humans, which forces a much more granular and dynamic treatment of speed, force, and detection functions.

These four divisions share corporate infrastructure, some common engineering processes, and an ABB-wide commitment to functional safety culture. What they do not share is a unified product requirements landscape. The gap between writing requirements for a residential miniature circuit breaker and writing requirements for a force-limited collaborative robot is not a matter of scale — it is a matter of fundamentally different engineering disciplines, regulatory frameworks, and verification methodologies.

The Functional Safety Obligation

IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems — is the foundational standard that underlies most of ABB’s safety obligations. It does not apply uniformly across all ABB products, but its influence is pervasive. IEC 61511 (process sector), IEC 61800-5-2 (drives), IEC 62061 (machinery), and IEC 62443 (industrial cybersecurity, increasingly intersecting with safety) all derive from or explicitly reference IEC 61508’s architecture.

What IEC 61508 demands, at its core, is documented evidence. Evidence that hazards were identified. Evidence that safety requirements were derived from hazard analyses. Evidence that designs implement those safety requirements. Evidence that verification confirmed the implementation. Evidence that changes to any of the above were assessed for impact on the SIL claim.

For a single product certified to SIL 2, this documentation burden is substantial but manageable. For a company like ABB, with hundreds of product families, thousands of product variants within those families, and ongoing software and hardware updates across all of them, the documentation burden is a continuous engineering operation — not a one-time certification activity.

Requirements reuse becomes both the obvious solution and the hidden trap. If ABB can establish a validated safety function in one product and reuse it across a product family — or across divisions — the certification cost per product drops dramatically. This is the logic behind IEC 61508’s concept of “proven-in-use” arguments and the use of pre-existing safety elements (PESEs). But reuse requires that the original requirements were written at a level of abstraction that genuinely transfers, that the new context has been analyzed for differences, and that traceability from reused element to new product context is maintained and auditable.

In practice, requirements reuse at ABB’s scale is one of the hardest systems engineering problems the company faces. A safety software module developed and certified for a drive application may seem reusable in a robotics context — but the operating environment, the diagnostic coverage requirements, the hardware architecture assumptions, and the systematic capability claims may all differ in ways that invalidate the original safety case. The engineering work required to establish that a reused element actually satisfies requirements in its new context is often underestimated until the first certification audit surfaces the gap.

Structuring Systems Engineering Across Product Families

ABB does not publish its internal systems engineering methodology in detail, which is appropriate for a competitive industrial company. But the structural challenges its engineering organizations face are visible from the outside, and they mirror challenges that any large multi-divisional industrial technology company confronts.

Variant management at scale is the first structural challenge. ABB’s low-voltage products alone span thousands of catalog entries. Behind each catalog entry is a product configuration that carries functional and safety requirements specific to its ratings, certifications, and intended markets. Managing this without explicit variant management infrastructure — whether through product line engineering practices, feature models, or configuration-aware requirements tooling — means that requirement updates propagate inconsistently. A safety requirement change that applies to all variants of a product family may be applied correctly to twenty variants and missed on the twenty-first.

Lifecycle asymmetry across divisions creates a second structural problem. A Motion division drive platform may be under active development for five years and then maintained in the field for fifteen. A Robotics division cobot may have a faster hardware iteration cycle but requires continuous safety re-assessment as new collaborative applications are certified. The Electrification division may ship hardware with 30-year expected service lives but update the embedded software much more frequently. These asymmetries mean that requirements management processes designed for one division’s lifecycle are poorly suited to another’s — yet ABB has legitimate reasons to want common engineering process infrastructure across divisions.

Cross-domain system integration is the third and most complex challenge. As ABB integrates its product portfolio under its Ability digital platform, and as customer solutions increasingly involve ABB products from multiple divisions working together — a drive controlled by a process automation system commanding a robot working alongside electrification infrastructure — the requirements for the integrated system do not naturally live in any single division’s requirements repository. Interface requirements, system-level safety functions, and cross-product diagnostic behaviors require an architectural view that spans divisional boundaries.

This is the use case where graph-based requirements models show their clearest advantages over document-based approaches. When a system safety requirement exists at the ABB solution level and must be allocated to requirements in three separate product-level requirements sets — each of which then traces to design, verification, and certification evidence in separate engineering environments — the traceability chain is only coherent if the relationships between nodes are first-class objects that can be queried, analyzed for completeness, and impact-assessed when any node changes. Document-based tools can store these relationships, but they cannot reason about them. Tools like Flow Engineering, which model requirements networks as connected graphs rather than hierarchical document structures, make cross-domain allocation and impact analysis tractable in a way that spreadsheet-backed document repositories fundamentally cannot.

The Requirements Change Problem

Nothing reveals the maturity of a requirements management practice faster than how an organization handles requirement changes on certified products. For ABB, change management is not a process step — it is a continuous operational reality.

An IEC 61508-certified software component that is modified for any reason — bug fix, performance improvement, new feature — triggers a change impact assessment. The assessment must determine whether the change affects any safety requirement, any element of the safety case, or any claim made in the functional safety assessment. If it does, the affected portions of the certification must be revisited. If the requirements that the software component implements are not clearly documented, or if the traceability from requirement to implementation to verification evidence is incomplete, the change impact assessment becomes a manual archaeology exercise rather than an engineering analysis.

At ABB’s scale — with drive firmware, robot safety software, DCS control applications, and protection device firmware all under concurrent development across multiple product families — the aggregate volume of change impact assessments across the portfolio is enormous. Organizations that have invested in rigorous requirements traceability absorb this burden more efficiently. Organizations that have not find that it accumulates as technical debt until a certification audit or a field safety event forces a reckoning.

What Scales and What Doesn’t

Several things work in ABB’s favor at this scale. The company has deep functional safety expertise built over decades. Its engineering organizations have worked under IEC 61508 and its sector derivatives long enough that safety lifecycle thinking is culturally embedded, not externally imposed. ABB’s size also means it can maintain dedicated functional safety competence centers — groups of experts whose sole focus is safety assessment methodology — that smaller companies cannot sustain.

What does not scale well is requirements management infrastructure that was designed for single-product or single-division use. Requirements tools that lack explicit variant management, that cannot represent cross-domain relationships as queryable structures, or that require manual synchronization when requirements change do not degrade gracefully as product portfolio complexity grows. They accumulate workarounds: shadow spreadsheets that capture what the official tool doesn’t, informal email threads that carry requirement decisions that never make it back to the authoritative record, and tribal knowledge about why certain requirements exist that lives in the heads of engineers who eventually leave.

The engineering challenge at a company like ABB is ultimately not about writing requirements. It is about maintaining living requirement networks — structures that evolve as products evolve, as regulations change, and as customer contexts shift — without losing the traceability that functional safety certification demands and that engineering integrity requires.

Honest Assessment

ABB’s systems engineering challenge is legitimate, large, and not fully solved by any tool or methodology currently on the market. The diversity of its product portfolio makes unified requirements management genuinely difficult, and the functional safety obligations across its divisions create a non-negotiable documentation burden that scales with portfolio breadth.

The engineering organizations that tend to manage this best — at ABB and at comparable industrial technology companies — share a few characteristics: they treat requirements traceability as a product asset rather than a compliance artifact, they invest in requirements infrastructure before they are forced to by audit findings, and they structure their systems engineering processes around the reality that products change throughout their lives and that change impact assessment is not an exception case but a routine engineering activity.

The companies that struggle tend to have built their requirements practices around the idea that requirements are written once, approved, and then consulted only when something goes wrong. At the scale ABB operates, that model breaks under its own weight.