The PLM Blind Spot: Why Systems Built for CAD Cannot Govern Software-Defined Products

The Product Lifecycle Management industry generates over $50 billion in annual revenue. It is dominated by three companies: Dassault Systemes (CATIA, ENOVIA, 3DEXPERIENCE), Siemens Digital Industries (Teamcenter, Polarion), and PTC (Windchill, Codebeamer). Together, they serve the majority of automotive, aerospace, and industrial manufacturing companies worldwide.

These are not bad products. They are, in many cases, excellent products — for the problems they were designed to solve. The issue is that the problems have changed, and the platforms have not kept up.

The Origin Story Matters

To understand why PLM vendors struggle with software-defined products, you need to understand where they came from.

Dassault Systemes started with CATIA in 1977, a 3D CAD tool for aircraft design developed for Dassault Aviation (the fighter jet manufacturer). Everything Dassault built afterward — ENOVIA for data management, SIMULIA for simulation, DELMIA for manufacturing — radiates outward from 3D geometry as the core data model. The 3DEXPERIENCE platform is fundamentally a system organized around parts, assemblies, and geometric relationships.

Siemens acquired UGS (Unigraphics, NX) in 2007 and Teamcenter came as part of that acquisition. Teamcenter's data model is a bill of materials (BOM) — mechanical parts organized into assemblies with revision control. When Siemens acquired Polarion in 2016 for application lifecycle management (ALM), it was bolted onto Teamcenter, not integrated into it.

PTC started with Pro/ENGINEER (now Creo) in 1987. Windchill was built to manage CAD files and BOMs. When PTC acquired Integrity (now Codebeamer) for ALM, the same pattern repeated: a software-focused tool grafted onto a CAD-centric platform.

In every case, the platform's DNA is geometry and physical parts. Software, electronics, calibration parameters, and control logic were added later as extensions — because the market demanded it, not because the architecture was designed for it.

Why This Matters Now

Thirty years ago, a car was 90% mechanical and 10% electronics. The PLM model worked: manage the physical parts, and you manage the product.

Today, a modern vehicle contains 100+ million lines of software code, 100+ electronic control units, and thousands of calibration parameters. The software defines the product's behavior more than the mechanical design does. A Tesla Model 3 and a Toyota Camry may have similar mechanical architectures, but they are fundamentally different products because of their software.

The same shift is happening across industries:

• Medical devices: Software-defined diagnostics, AI-assisted imaging, connected health monitoring
• Aerospace: Fly-by-wire systems, autonomous flight control, mission-critical software
• Industrial equipment: IoT-connected machinery, predictive maintenance, digital twins driven by embedded software
• Electronics: Firmware-defined product behavior, over-the-air updates, configurable hardware

In all of these domains, the critical engineering decisions are about software, control logic, and system behavior — not about 3D geometry.

The SysML Detour

Recognizing this shift, PLM vendors invested heavily in SysML (Systems Modeling Language) as the answer. SysML extends UML to model system requirements, behavior, structure, and constraints using graphical notation — block diagrams, activity diagrams, sequence diagrams, and parametric diagrams.

In theory, SysML bridges the gap between mechanical and software engineering. In practice, its adoption has been limited:

• Steep learning curve: SysML requires significant training. Most practicing engineers — particularly in automotive Tier 2/3 suppliers, medical device companies, and industrial electronics firms — do not have SysML expertise and cannot justify the investment to acquire it.
• Overhead exceeds value for many teams: For a 20-person engineering team building an electronic control unit, maintaining a full SysML model alongside requirements, FMEA, test cases, and code is not practical. The modeling effort becomes an end in itself rather than a means to better engineering.
• Disconnected from code: SysML models describe intended behavior. The actual behavior is in the source code. These two representations drift apart over time, and keeping them synchronized requires manual effort that most teams cannot sustain.
• Vendor lock-in: SysML tools (Cameo, Rhapsody, Enterprise Architect) create proprietary model repositories that do not interoperate well, despite the standard's promise of interchange.

SysML is valuable for complex systems-of-systems engineering at organizations with dedicated systems engineering departments — think Boeing, Airbus, or major OEMs. For the vast majority of companies building software-defined products, it adds complexity without proportional benefit.

The Real Gap

The actual need is simpler than what SysML addresses, but harder than what traditional PLM provides:

1. Requirements that connect to code: Not a 3D model, not a SysML block diagram — just a traceable link between what the system should do and what the code actually does.
2. Risk analysis integrated with requirements: FMEA should not be a separate spreadsheet maintained by a separate team using a separate tool. It should be linked to the requirements and updated when the design changes.
3. Traceability across the V-model: From stakeholder needs to system requirements to software requirements to code to test cases to FMEA — a complete chain that auditors can follow.
4. Version control native to software workflows: Engineers who work with code expect Git-based workflows — branches, commits, diffs, merge requests. PLM check-in/check-out is foreign to software teams.
5. Collaboration without heavyweight infrastructure: A web browser, not a desktop client. Real-time editing, not file locking. Comments and mentions, not email chains with attached spreadsheets.

A Different Starting Point

What if you started from the software and electronics side and worked outward, instead of starting from 3D geometry and trying to bolt on software support?

This is the approach NirmIQ takes. The platform was built for teams that develop control software, embedded systems, electronic hardware, and safety-critical firmware. The core data model is requirements, risk analysis, and code traceability — not parts, assemblies, and geometric relationships.

For mechanical traceability, NirmIQ connects to existing PLM systems through part numbers. If your organization uses Dassault 3DEXPERIENCE, Siemens Teamcenter, or PTC Windchill for mechanical design management, those part numbers can be referenced in NirmIQ requirements to establish cross-domain traceability. This means you do not need to replace your PLM system. You complement it.

The difference in architecture:

Traditional PLM platforms (Dassault, Siemens, PTC) organize everything around a mechanical BOM and add software support as an extension. This means:

• Requirements management is a module bolted onto BOM management
• FMEA is either absent or requires a third-party integration
• Code traceability requires yet another integration
• Every capability is an add-on with its own license cost

NirmIQ organizes everything around requirements, risk, and code — and links to mechanical systems through part references. This means:

• Requirements management is native, not an add-on
• FMEA is built-in with full AIAG-VDA support
• Code Intelligence connects source code to requirements and FMEA directly
• Mechanical traceability is achieved through part number linking to PLM systems

Who This Approach Serves

This architecture is a natural fit for:

• Automotive Tier 1/2 suppliers developing ECUs, sensors, and control software — companies that do the calibration, develop the embedded code, and need to prove compliance with ISO 26262 and ASPICE
• Medical device companies building software-defined diagnostics, connected devices, and combination products under IEC 62304 and FDA 21 CFR Part 11
• Aerospace software teams developing avionics software, flight control systems, and mission-critical firmware under DO-178C
• Industrial electronics companies building IoT devices, motor controllers, and power electronics with embedded firmware
• Any company where the product's value is defined more by its software than by its physical form

These are organizations where the engineering team spends 80% of its time on software, electronics, and system integration — not on 3D modeling. They need tools built for their workflow, not tools adapted from a different domain.

The Coexistence Model

This is not an either-or proposition. Large organizations will continue to use PLM for mechanical design management. The question is whether they also need a purpose-built platform for the software and electronics side — or whether they try to stretch their existing PLM to cover it.

The evidence suggests that stretching PLM has not worked well. After a decade of investment in ALM add-ons and SysML tools, most engineering teams still manage FMEA in Excel, maintain requirements in Word documents, and have no traceability between code and requirements.

A focused platform that does requirements, FMEA, and code traceability exceptionally well — and links to PLM for mechanical context — delivers more value than a PLM platform that does everything adequately but nothing exceptionally.

The products of the future are software-defined. The tools that govern them should be too.

Further Reading

• Migrating from IBM DOORS to NirmIQ — a practical migration guide for teams leaving legacy tools
• The Complete Guide to AIAG-VDA FMEA — the risk analysis methodology that PLM vendors treat as an add-on and NirmIQ treats as core
• NirmIQ Code Intelligence — how we connect source code to requirements and FMEA without SysML