Introducing PTC Ignition

The architecture problem

Ask engineering leaders where their product architecture lives and you'll usually get an uncomfortable pause. Some of it is in a document that was accurate eighteen months ago. Some is in a spreadsheet or a SysML diagram of systems and subsystems. Some is implied by the CAD assembly structure. The interfaces — where complex products often malfunction — are scattered across documents, email threads and the memory of one engineer who has been there long enough to know.

Meanwhile the products themselves have changed. A product that was once mechanical with some control logic is now mechanical, electrical, electronic, software and connected. The number of disciplines that have to agree has increased. The number of places where a change in one engineering domain silently breaks another, has increased exponentially.

The formal answer to this has always been model-based systems engineering. And MBSE works — where it is adopted. It requires investment and expertise though, meaning adoption across the wider engineering population remains limited. Not because engineers disagree with the principles, but because the route in is steep: a modelling language to learn, a diagram taxonomy to internalise, a specialist tool to master, and a small population of people qualified to maintain the result. For many teams the cost of entry has simply been higher than the problem they were trying to solve.

That gap — between teams who need rigorous architecture and teams who can realistically adopt SysML-based MBSE — is where PTC Ignition sits.

PTC Ignition – a different approach

PTC Ignition is a web-based systems engineering application for defining functional architectures, building a multi-disciplinary product architecture, allocating functions to the components that realise them, and managing the interfaces between them — connected to the requirements, CAD, PLM, ECAD and software artifacts that make up the digital thread.

Deliberately, there are no SysML diagrams. There is no modelling language to learn. The experience is structured around five things engineers already recognise: functions, architecture, allocation, interfaces and the work that follows from them.

That's not a simplified MBSE tool. It's a different starting point — foundational systems engineering practice, made accessible to the engineers who were never going to become modelling specialists.

Five principles, and why each one matters

Start with what the system must do

Functions are captured as solution-neutral statements derived from requirements, then structured into a hierarchy from system level down to sub-function. Dependencies between functions are created directly; Satisfy links back to requirements are established through OSLC or REST.

The practical payoffs are a deep understanding of the capabilities and behavior a product must perform, and a clear view of requirements coverage. Before anyone commits to a design, you can see which requirements have no function behind them and which functions answer to nothing. Orphans and gaps are the cheapest defects you will ever fix.

Then describe the solution — all of it

Systems, subsystems, modules and components are first-class items, spanning mechanical, electrical/electronic and software disciplines. The hierarchy is flexible rather than rigid, and the out-of-the-box types can be extended to match how your organisation describes its products.

The important word is multi-disciplinary. Most architecture tooling is really domain tooling with a view onto other domains. Here the software module and the machined bracket are managed together, sitting in one governed structure.

Connect the two

Allocation is the step where architecture stops being descriptive and starts being a decision. Functions are allocated to the components that will realize them, which establishes both the chosen design solution and technical ownership.

It also surfaces important questions early: functions with no home, functions allocated to three places, components carrying more responsibility than their budget allows.

Make the dependencies explicit

Most system failures happen at the interfaces, not inside the components. With PTC Ignition, interfaces are treated as first-class items — owned by the architecture elements they belong to, classified by type (data or signal, power, fluid, mechanical, spatial), and constrained by real parameters: timing, bandwidth, pressure, tolerance, connector type.

Interface Links establish provider–consumer contracts. Interface Specifications can be generated to ensure stakeholders have access to all relevant information. And because interfaces are versioned and change-controlled, "what breaks if we change this?" becomes a query rather than a meeting.

Carry the numbers through

Properties capture engineering parameters — mass, power, cost, latency, reliability, criticality — and propagate them from parameterised requirements through to detailed design and test. A mass target set at system level decomposes into subsystem allowances; component estimates roll back up and show a breach against target long before anyone opens CAD.

That's the difference between an architecture you look at and an architecture that tells you something.

Architecture that turns into work

Defining the optimal architecture is only useful if the organisation acts on it. This is where being built on Windchill matters more than it might first appear.

PTC Ignition inherits enterprise capability from day one: lifecycles, teams and roles, baselines, design reviews, managed collections, subscriptions, configuration and change management — extended across suppliers and development partners. Architecture components can be linked to reusable existing designs or created as placeholders for planned new work, with ownership assigned. Variable architectures can be defined and variants created, enabling system-level product line engineering (PLE).

With this integrated approach, the product architecture becomes the plan. Each unallocated function is scope. Each placeholder component is a work package. Each interface is a contract with a name against it.

PTC Ignition doesn't replace MBSE — it complements it

Many organisations genuinely need deep behavioural modelling, formal analysis and simulation, and for them SysML-based MBSE in a tool such as PTC Modeler remains the right answer. PTC Ignition is designed to work alongside those tools: OSLC linking and synchronisation, with data exchange based on a SysML v2 subset and the Reusable Asset Specification.

The realistic picture in a large enterprise is both. A specialist team doing rigorous modelling where the complexity justifies it, and a much larger population of engineers who now have a governed place to define architecture, allocation and interfaces — instead of a slide deck or complex MBSE diagram.

Who this is for

If any of this sounds familiar, PTC Ignition was built with you in mind:

• Your product architecture exists, but not in one place, and not in a form everyone trusts
• Integration problems keep appearing late, and they're often interface problems
• You evaluated an MBSE tool and concluded the adoption cost was greater than the payoff
• You have a handful of modelling experts and several hundred engineers who aren't
• You need to know what a change involves before you commit to it

Part of an integrated engineering ecosystem

PTC provides a suite of tools to help companies engineer complex, multi-disciplinary products – we call this integrated product engineering (IPE). PTC Ignition provides a single source of truth for product functions and architecture, and is integrated with and complemented by these PTC solutions:

Product Relationship Explorer (PRE)

• Explore the digital thread with a consolidated, explorable view of your engineering product data & relationships, across PTC & 3rd party products.

Task and Change Collaboration (TCC)

• Co-ordinate, automate and synchronize change processes between PTC Ignition and Codebeamer.

PTC Jetstream

• A cloud-native collaboration environment for fast, secure, and traceable collaboration on product data — alongside formal product development processes.

Systems engineering has never suffered from a shortage of knowledge or good practice. It has suffered from a lack of effective software solutions that engineering teams can easily adopt.

For more information visit ptc.com, or contact
Patrick Ollerton ([email protected])