Prescriptive Engineering How AI is Embedded in Robust Engineering Processes

Related Vendors

Taiwan Machine Tool & Accessory Builders' Association (TMBA)

SIMTOS (Seoul International Machine Tool Show)

AI detects anomalies, prioritizes information, or provides predictions. However, it usually does not intervene in the processes where decisions about requirements, variants, changes, and approvals are made. This is precisely where prescriptive engineering becomes relevant.

Especially in engineering, it is not sufficient to use AI in isolation as an analysis tool, because development structurally functions differently than classic data analysis. Decisions arise along dependencies between requirements, system architecture, software versions, test cases, and configurations. Changes rarely affect only a single element but impact multiple levels and must be technically as well as regulatorily traceable and secured. This is particularly evident in software-defined products, where hardware, software, variant logic, and supply chain are closely interconnected.

Prescriptive Engineering describes a methodological framework in which AI does not stop at analysis but derives concrete action recommendations for the further development process from data, rules, and technical context and integrates them into controlled workflows.

Why Isolated Use Cases Don't Sale

Many AI projects in engineering remain small because they are introduced as standalone solutions. One model analyzes field data, another prioritizes requirements, and a third identifies anomalies in test data. Each of these use cases can be meaningful. However, a consistent engineering process does not emerge from this. The reason lies not in the quality of the individual model but in the lack of integration between AI results and the structures where technical decisions are actually made.

A typical example is the analysis of sensor data from the field. If a model detects thermal anomalies in a control unit component, it is initially just a signal. As long as this signal is not linked to the affected requirements, the specific software version, the installed hardware, the associated test cases, and possible change processes, it remains isolated. It provides insight but not a reliable basis for a technical action.

What Architecture Prescriptive Engineering Requires

The actual scaling question is therefore architectural. In most companies, requirements reside in ALM, bills of materials and configurations in PLM, delivery information in ERP, and operational data in IoT or service systems. As long as this information exists only side by side, AI also remains fragmented. Prescriptive engineering requires that relevant objects are consistently linked across system boundaries and that changes can be evaluated within their technical context.

This does not require a monolithic platform but rather an integration architecture with stable object IDs, versionable data models, bidirectional references, and clearly defined handover points between ALM, PLM, ERP, and service systems. Only when requirements, configurations, changes, test setups, and field data can be analyzed within a shared context can AI reliably assess impacts. This is precisely where the Intelligent Product Lifecycle (IPL) becomes the crucial foundation.

It links the relevant information throughout the entire product lifecycle, from the initial requirement through the system model, software status, and bill of materials to field operations. Changes can thus be assessed not in isolation but in the context of a specific product configuration. This is the prerequisite for turning an analysis into a technically actionable recommendation.

How Analysis Turns into Concrete Next Steps

Prescriptive Engineering builds on this structure. While traditional AI primarily identifies patterns, Prescriptive Engineering links insights with requirements, implemented functions, variant statuses, test cases, and change processes. This not only allows deviations to be identified but also determines which next steps are technically appropriate.

For example, if a performance deviation is detected in the field, the mere indication of the deviation is not enough. What matters is whether it could be attributed to a specific software version, a hardware revision, a faulty requirement, an insufficient test case, or a modified supplier part. Prescriptive engineering places such signals in the technical context and derives traceable action proposals from them, such as a change request, adjustment of a requirement, additional tests, or evaluation of alternative components.

What Role Agentic AI plays in this

For this approach to work in practice, context must be consolidated across multiple systems. This is where the role of Agentic AI comes into play. AI agents do not replace formal engineering decisions but handle the context-based orchestration of information along the toolchain. They link data from various sources, assess its relevance to the specific case, and create structured decision templates from it.

An AI agent can, for example, correlate maintenance data of a module with the functional requirements in ALM, the physical configuration in the PLM bill of materials, and the current delivery status in ERP. Based on this, it becomes possible to evaluate whether a deviation points more towards a design issue, a specific configuration, or an available substitute in the supply chain. Without this form of orchestration, prescriptive engineering would remain a theoretical framework. Only through cross-system context integration does the approach become operationally usable.

Why ALM Structures Provide Operational Assurance

Recommendations in engineering are not made reliable by being generated quickly but by being processed in a controlled manner. Therefore, ALM structures play a central role. They form the workspace where requirements, changes, reviews, test cases, and traceability converge. An AI-prepared suggestion is not implemented automatically but is transferred as a requirement update or change request into a regulated process, for example, in ALM systems like Codebeamer.

This is where the practical value of process-integrated AI becomes evident. If a change to software parameters is proposed, the affected safety requirements, test cases, and approval steps can be immediately identified. The formal decision remains within the engineering process. AI prioritizes, correlates, and recommends, while approval remains tied to established review and change structures. This allows change cycles to be shortened without compromising traceability, compliance, or technical discipline.

Prescriptive Engineering as a Response to Complex Product Development

The more software-defined, variant-rich, and interconnected products become, the less isolated AI experiments and fragmented data landscapes contribute. Prescriptive engineering is therefore not an add-on to existing analysis tools but a methodological response to the question of how AI can be embedded into reliable engineering processes. The decisive lever lies not in the individual model but in the architecture that enables context, traceability, and controlled processing.

Companies that establish this continuity use AI not only to monitor complex systems but also to prepare technical decisions thoroughly. This is precisely the difference between isolated automation and process-effective AI in engineering.

*Arian van Hülsen is Director Solutions Consulting & Global AI Champion at PTC