15. Emerging PLM Practices and Future Directions

Introduction and Context

Product lifecycle management (PLM) has evolved from a system for storing computer-aided design files into an enterprise capability for governing product information, processes, decisions, and knowledge from concept through retirement. Earlier PLM implementations were commonly installed within an organisation’s information-technology infrastructure and were centred on engineering change management, configuration control, document management, and product data integration. Contemporary practice is broader. Products are now cyber-physical, software-intensive, service-enabled, globally engineered, and subject to increasingly demanding sustainability and regulatory requirements. Consequently, PLM must connect design, simulation, manufacturing, supply networks, field service, customer usage, recycling, and compliance.

The emerging practices examined in this chapter—software-as-a-service (SaaS) PLM, low-code development, knowledge graphs, extended reality (XR), additive manufacturing, autonomous engineering, and digital product passports—should not be regarded as isolated technologies. Each changes how product information is created, interpreted, governed, or acted upon. Their value depends on architecture, data quality, organisational capability, cybersecurity, standards, and the ability to integrate people with automated systems.

The central question is therefore not whether an organisation should adopt a particular fashionable technology. It is whether that technology improves lifecycle decisions while preserving traceability, safety, intellectual property, and accountability. This chapter evaluates that question through conceptual models, industry applications, limitations, and an illustrative case.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the strategic significance of emerging PLM practices.

2. Compare SaaS PLM with traditional on-premise and hybrid architectures.

3. Evaluate low-code platforms, knowledge graphs, XR, additive manufacturing, and autonomous engineering in lifecycle processes.

4. Explain the purpose and governance implications of digital product passports.

5. Analyse how standards, interoperability, cybersecurity, and responsible innovation affect PLM transformation.

6. Apply a structured framework to assess an emerging PLM investment.

7. Critically evaluate an industry scenario involving several converging technologies.

From Product Data Management to Intelligent Lifecycle Governance

A useful way to understand the future of PLM is to distinguish four layers. The first is the record layer, containing authoritative parts, documents, requirements, configurations, bills of material, and change records. The second is the process layer, which controls workflows such as design release, engineering change, supplier approval, non-conformance, and service feedback. The third is the digital-thread layer, which links information across lifecycle stages and organisational boundaries. The fourth is the intelligence layer, where analytics, simulation, machine learning, optimisation, and decision support operate on governed data.

Emerging PLM practices primarily strengthen the third and fourth layers. A knowledge graph can reveal relationships that are difficult to identify in tables. XR can make digital-thread information accessible in the physical work environment. Autonomous engineering can search design spaces or detect anomalies. A product passport can expose selected lifecycle information to regulators, customers, repairers, and recyclers. Yet these capabilities depend on a reliable record layer. Artificial intelligence cannot compensate for uncontrolled part numbers, ambiguous product structures, or incomplete change histories.

A second useful model is the lifecycle decision loop:

sense → interpret → decide → execute → verify → learn.

Sensors, service reports, supplier information, and market requirements provide signals. PLM interprets those signals in relation to product definitions and requirements. Engineers and authorised algorithms make decisions, which are implemented through design, manufacturing, or service processes. Verification establishes whether the change achieved its purpose, and the resulting knowledge becomes available for future decisions. Emerging technologies accelerate this loop, but governance determines whether acceleration creates value or merely increases the speed of error.

SaaS PLM: Platform, Service, and Operating Model

SaaS PLM delivers PLM functionality through a provider-managed cloud service, normally accessed through web interfaces and application programming interfaces (APIs). The customer subscribes to a service rather than purchasing and maintaining the complete application infrastructure. The provider commonly manages hosting, patches, availability, backup, and parts of the security environment.

The distinction between SaaS and cloud-hosted software is important. A privately hosted PLM system placed in a cloud data centre may still retain the operational characteristics of conventional software. SaaS generally implies standardised, provider-managed releases and a service relationship defined by availability, support, data protection, and exit provisions. Multi-tenant SaaS serves multiple customers on shared infrastructure with logical separation, whereas single-tenant or dedicated arrangements may provide greater isolation at additional cost.

SaaS PLM can reduce initial infrastructure expenditure and make advanced capabilities available to smaller suppliers. It supports geographically distributed collaboration, faster deployment, elastic computing for simulation-related workloads, and more frequent functional updates. It can also simplify acquisition of connected modules for requirements, quality, manufacturing, and service.

However, the economic and technical analysis must extend beyond subscription price. Important considerations include data migration, integration development, user training, network dependence, latency, regulatory location of data, provider lock-in, customisation limits, and the cost of adapting organisational processes to standard software. A highly customised legacy system may be expensive to migrate even when the target SaaS subscription appears attractive.

A robust SaaS PLM decision examines:

• data ownership, portability, retention, and deletion;
• service-level objectives and remedies for outages;
• identity management, encryption, tenant isolation, and incident response;
• integration through stable APIs and event mechanisms;
• validation of software changes in safety- or quality-critical workflows;
• subcontractor and data-centre transparency; and
• business continuity and exit procedures.

The most appropriate architecture is often hybrid. Highly sensitive intellectual property, specialised computation, or regulated records may remain in controlled environments, while collaboration, supplier portals, analytics, and selected lifecycle services operate through SaaS. Hybrid architecture, however, introduces synchronisation and master-data challenges. It must specify which system is authoritative for each object and how conflicts are resolved.

Low-Code PLM and the Democratization of Process Design

Low-code platforms provide visual tools, configurable data models, workflow builders, forms, rules, and integrations with limited conventional programming. In PLM, they can be used to create supplier qualification workflows, deviation requests, sustainability data collection, prototype approval forms, service-return processes, or dashboards.

Their principal benefit is proximity between process owners and solution development. A quality engineer may be able to configure a non-conformance workflow without waiting months for a software-release cycle. This can improve responsiveness and encourage experimentation. Low-code tools are also useful for temporary or local applications that should not become permanent modifications to the PLM core.

The main risk is uncontrolled application proliferation. If departments create independent definitions of a part, supplier, material, or approval status, the organisation acquires a collection of convenient but contradictory systems. This phenomenon is sometimes described as shadow IT. Low-code development therefore requires architectural guardrails: approved data objects, naming conventions, role-based access, version control, testing, audit trails, and a process for promoting applications into production.

A practical governance model differentiates between citizen development and professional development. Citizen developers may configure bounded workflows using approved components. Professional architects review data integration, security, performance, regulatory requirements, and long-term support. Every application should have an owner, a purpose statement, a retention policy, and an identified retirement condition.

Low-code is not a substitute for engineering judgement. It reduces the effort required to express a process, but it cannot determine whether the process is technically valid. A visually attractive workflow that allows a design change to bypass configuration impact analysis is a serious control failure.

Knowledge Graphs and the Semantics of the Digital Thread

Traditional PLM databases represent entities and transactions effectively, but relationships are often distributed across tables, documents, and disconnected systems. A knowledge graph represents entities as nodes and relationships as edges. Nodes may include requirements, parts, materials, manufacturing operations, suppliers, regulations, test results, software versions, and field failures. Edges express relationships such as “satisfies,” “is manufactured by,” “is compatible with,” “was changed by,” or “is restricted under.”

The significance of a knowledge graph lies in semantics rather than visual novelty. It can combine information from PLM, enterprise resource planning, manufacturing execution, internet-of-things, service, and compliance systems while preserving the meaning of relationships. Ontologies define concepts and permitted relationships; identifiers and mappings connect records that were previously named differently.

In engineering practice, a graph may answer questions such as: Which field failures involve a material lot used in a particular product configuration? Which requirements are affected by a software change? Which suppliers provide components containing a regulated substance? Which tests provide evidence for a safety claim? Graph-based reasoning can support impact analysis, configuration search, root-cause investigation, and compliance reporting.

Knowledge graphs do not eliminate data-quality problems. Incorrect mappings can create plausible but false relationships. Ontology development requires domain expertise, and the graph must represent uncertainty, provenance, time, and configuration validity. A relationship that was true for one product revision may be false for another. Accordingly, graph governance should include source provenance, effective dates, confidence levels, access control, and review responsibilities.

Extended Reality as a Lifecycle Interface

Extended reality includes virtual reality (VR), augmented reality (AR), and mixed reality (MR). In PLM, XR is best understood as an interface to lifecycle information rather than simply a visualisation device. A technician may view work instructions overlaid on a machine, an engineer may inspect a full-scale virtual prototype, and a service team may collaborate around a shared digital model.

XR applications include design review, ergonomic evaluation, assembly sequence validation, operator training, maintenance guidance, remote expert assistance, and inspection. They can expose configuration-specific information at the point of work, reducing the need to interpret paper manuals or search separate databases.

The value of XR depends on accurate spatial registration, suitable model simplification, low latency, human-factors design, and configuration control. A headset displaying an obsolete procedure is more dangerous than no headset at all. XR content therefore requires the same release, approval, and change-control discipline as other controlled product information.

Additional concerns include worker comfort, distraction, visual fatigue, privacy, recording of workplaces, and the risk that users over-trust an automated overlay. Effective implementation starts with a narrowly defined task and measurable outcome—for example, reduced assembly errors or shorter maintenance diagnosis time—rather than with the purchase of devices.

Additive Manufacturing and the Reconfiguration of the Lifecycle

Additive manufacturing (AM) builds parts layer by layer from digital models. It affects PLM because the product definition is no longer limited to geometry and conventional drawings. Material feedstock, build orientation, support structures, machine parameters, thermal history, post-processing, inspection data, and serialisation may all influence conformity.

AM enables geometrical complexity, lightweight structures, rapid prototyping, distributed production, customised products, and spare-parts manufacture on demand. It can shorten the path from design iteration to physical evaluation. In service networks, a validated digital part definition may support local manufacture where logistics would otherwise create long delays.

The lifecycle challenge is process qualification. Two parts with identical nominal geometry may have different properties because of machine condition, powder characteristics, environmental conditions, or parameter settings. PLM must therefore connect the design definition with the manufacturing recipe, machine identity, material batch, inspection evidence, and post-processing record. This is particularly important in aerospace, medical, energy, and other safety-critical sectors.

Design for additive manufacturing also changes engineering responsibilities. Engineers must consider anisotropy, residual stress, surface quality, lattice behaviour, thermal management, support removal, and inspection limitations. A conventional drawing-centric release process may be inadequate. A model-based definition with controlled manufacturing parameters and acceptance criteria is more suitable.

AM also raises intellectual-property and cybersecurity concerns. A digital build file can be copied or altered easily, and unauthorised production may create safety and liability risks. Access control, file signing, machine authentication, and verification of manufactured output are therefore part of PLM governance.

Autonomous Engineering and Human Accountability

Autonomous engineering refers to the use of algorithms, artificial intelligence, optimisation, simulation, and automation to perform or recommend engineering activities with limited direct intervention. Examples include generative design, automated design-space exploration, automatic tolerance allocation, simulation setup, requirements classification, anomaly detection, and predictive maintenance.

The term should be used carefully. Most current systems are assistive or semi-autonomous rather than fully autonomous. They generate alternatives, identify patterns, or recommend actions, while qualified professionals retain approval authority. Generative design, for example, can search thousands of geometries against stiffness, mass, manufacturing, and cost constraints. The resulting design still requires interpretation, verification, manufacturability assessment, and configuration release.

A trustworthy autonomous-engineering system requires four forms of assurance. First, data assurance addresses representativeness, completeness, bias, and provenance. Second, model assurance examines validation, uncertainty, boundary conditions, and failure modes. Third, process assurance defines when algorithmic output may influence a controlled decision. Fourth, human assurance ensures that responsible engineers understand the result sufficiently to challenge it.

Explainability has a practical engineering meaning. It need not always expose every internal mathematical operation, but it should provide the input data, constraints, assumptions, version of the model, confidence or uncertainty, and evidence supporting the recommendation. The system should also preserve a decision record showing who accepted, rejected, or modified the output.

Automation can create new failure modes: optimisation against the wrong objective, reinforcement of historical design bias, hidden correlations, data poisoning, and automation complacency. In safety-related applications, autonomous recommendations should pass through independent verification and clearly defined authority boundaries.

Digital Product Passports and Lifecycle Transparency

A digital product passport (DPP) is a structured digital record associated with a product or component that provides authorised stakeholders with information about its identity, composition, performance, origin, use, repair, and end-of-life characteristics. The precise content depends on the product category and applicable regulation. A passport is not simply a QR code; the code is an access mechanism, while the passport is a governed information service.

DPPs can support material traceability, repair, reuse, remanufacturing, recycling, conformity assessment, and sustainability claims. They may contain a product identifier, manufacturer information, critical materials, recycled content, carbon-related data, repair instructions, spare-part information, and disassembly guidance. Different users require different views: a consumer may need durability and repair information, whereas a recycler may require material composition and safe-processing data.

The design challenge is selective transparency. Full disclosure of proprietary formulations or supplier information may be commercially unacceptable, while insufficient information undermines the passport’s purpose. Access rights, data minimisation, authentication, version history, and responsibility for updates must be defined. A passport that remains unchanged after a repair or component replacement is not a reliable lifecycle record.

DPP implementation is closely connected to circular-economy strategies. It can enable product-as-a-service models, condition-based resale, remanufacturing decisions, and improved recovery of valuable materials. Nevertheless, it cannot by itself create circularity. Business models, reverse logistics, repair skills, recycling capacity, and economically viable secondary markets remain necessary.

Standards and Interoperability as Strategic Infrastructure

Emerging PLM practices are constrained or enabled by standards. Product data exchange standards, configuration and change-management practices, quality-management requirements, cybersecurity frameworks, identification systems, and sustainability reporting rules all influence implementation. Standards do not guarantee interoperability, because organisations may interpret them differently or implement only subsets. Nevertheless, common semantics and exchange structures reduce dependence on proprietary interfaces.

Interoperability has at least three dimensions. Syntactic interoperability allows systems to exchange data in an agreed format. Semantic interoperability ensures that exchanged data has the same meaning. Organisational interoperability aligns responsibilities, policies, and processes across companies. A supplier portal may achieve syntactic exchange while still failing semantically if “released,” “approved,” and “production-ready” mean different things to different organisations.

Standards strategy should therefore identify authoritative identifiers, data dictionaries, product-structure rules, API policies, and evidence requirements. It should also monitor evolving regulation relating to cybersecurity, artificial intelligence, sustainability, data protection, and product safety. Standards management is a continuing capability, not a one-time compliance project.

An Assessment Framework for Emerging PLM Investments

A balanced evaluation can use six questions:

1. Lifecycle value: Which decision, delay, error, cost, risk, or sustainability problem is being addressed?

2. Data readiness: Are the required records accurate, connected, current, and sufficiently governed?

3. Technical fit: Can the technology integrate with existing PLM, ERP, manufacturing, service, and analytics systems?

4. Assurance: How will safety, quality, cybersecurity, privacy, intellectual property, and regulatory obligations be demonstrated?

5. Organisational adoption: Do roles, skills, incentives, and leadership support the changed way of working?

6. Economic durability: Are total lifecycle costs, vendor dependence, scalability, and exit options acceptable?

A pilot should be designed as a decision experiment. It should define a baseline, measurable outcomes, excluded uses, data owners, acceptance criteria, and a route to scale. A successful demonstration that cannot be governed or integrated is not a successful PLM transformation.

Illustrative Case: A Hybrid PLM Transformation for an Electric-Drive Manufacturer

Background

Consider ElectraMotion, an illustrative global manufacturer of electric-drive modules for commercial vehicles. Its engineering sites use different PLM releases, suppliers exchange inconsistent spreadsheets, service teams have limited access to design information, and regulatory customers increasingly request evidence about materials, software versions, repair, and recycling.

Situation and Problem

The company proposes a cloud-based PLM platform, a low-code supplier workflow, a knowledge graph linking requirements and field failures, XR maintenance instructions, additive manufacturing for selected spare parts, and a product passport. Some executives describe the programme as an autonomous digital thread. Engineering leaders are concerned about intellectual property, cloud dependency, and the possibility of incorrect AI-generated recommendations.

Analysis

An initial assessment finds that the principal problem is not a lack of advanced technology. Product identifiers differ between engineering, purchasing, and service. Several critical components lack complete configuration histories. Supplier material data is frequently received as unverified documents. Therefore, immediate deployment of AI or passports would risk distributing unreliable information.

The company maps authoritative sources for product structures, requirements, software versions, material declarations, and service events. It establishes a common identifier policy and defines which records must remain under engineering approval. A hybrid architecture is selected: collaborative workflows and supplier interaction use SaaS, while a controlled repository retains selected sensitive design data and validated release evidence.

Approach and Solution

The first pilot addresses a high-volume drive-module variant. A low-code workflow collects supplier declarations, but submission does not equal approval; a materials engineer reviews evidence before it becomes authoritative. A knowledge graph links requirements, components, software releases, test results, suppliers, and field incidents. The graph stores provenance and effective configuration dates.

The service department then develops XR instructions for one maintenance operation. The instructions are generated only from released service content and display the applicable product configuration. For a difficult-to-source bracket, the company evaluates additive manufacture. The digital build file is access-controlled, the machine and material batch are recorded, and inspection results are linked to the manufactured serial number.

A passport prototype exposes different views to customers, repair partners, and recyclers. It includes identity, approved repair information, selected material data, software version, and end-of-life guidance. It excludes confidential supplier formulations. An analytics model recommends likely causes of selected field failures, but engineers approve all corrective changes.

Outcome

The pilot demonstrates improved traceability and faster investigation of field issues, but it also reveals that integration and data cleansing require more effort than device procurement. The organisation postpones wider autonomous decision-making until model validation and change-control procedures are established. It scales the passport only for product categories with clear data ownership and regulatory relevance.

Learning Points

First, emerging PLM technologies produce value when connected to a defined lifecycle decision. Second, governance must precede scale. Third, the digital thread is a socio-technical arrangement involving identifiers, processes, standards, skills, and accountability. Fourth, human approval remains essential where errors could affect safety, compliance, or customer trust. Finally, a staged hybrid strategy may be more resilient than an attempt to replace every existing system at once.

Risks, Ethics, and Professional Responsibility

The major risks of emerging PLM include cybersecurity attacks on product definitions and manufacturing files; unauthorised access to supplier or customer information; biased or unvalidated AI recommendations; inaccurate sustainability claims; excessive surveillance of workers; vendor lock-in; and the loss of engineering skills through over-automation. Connected products also create ambiguity about responsibility when a software update, supplier change, or algorithmic decision contributes to failure.

Professional responsibility requires traceability of significant decisions, competence to evaluate automated outputs, protection of confidential information, and prioritisation of public safety. Organisations should apply least-privilege access, secure software development, threat modelling, backup and recovery testing, model validation, independent review, and incident learning. They should distinguish verified facts from estimates and disclose material uncertainty in environmental or performance claims.

Ethical governance also concerns inclusion and work design. XR may exclude users with particular physical or sensory needs; automated screening may disadvantage suppliers whose data is less digitised; and algorithmic productivity monitoring may undermine trust. Responsible PLM considers affected stakeholders, not only the technology purchaser.

Current Directions and Best Practices

Several directions are likely to shape PLM practice. Product development is becoming increasingly software-defined, requiring closer integration between systems engineering, software configuration, cybersecurity, and service operations. Digital twins are moving from isolated engineering simulations toward connected representations updated by operational evidence. AI assistants will increasingly support search, classification, requirements analysis, and design exploration, while regulated applications will demand stronger evidence and human oversight. Circularity will increase the importance of material traceability, repair information, and passport architectures.

Organisations preparing for these developments should:

• establish a governed product and asset-identity strategy;
• treat data quality and semantics as engineering work;
• use open interfaces and portable representations where practical;
• begin with high-value, bounded lifecycle decisions;
• separate experimentation from controlled production release;
• retain provenance, uncertainty, and configuration context;
• design security and privacy into architecture rather than adding them later;
• define human authority over automated recommendations; and
• measure operational outcomes, not merely numbers of users or connected records.

Chapter Summary

Emerging PLM practices extend lifecycle management from controlled product information toward connected, intelligent, and increasingly transparent decision systems. SaaS PLM improves access and scalability but requires careful attention to data ownership, integration, security, and exit strategies. Low-code platforms accelerate process development while creating risks of shadow systems and inconsistent data. Knowledge graphs strengthen semantic relationships across the digital thread, provided that provenance, configuration, and ontology governance are maintained.

XR provides a point-of-work interface for design, training, assembly, and service, but its content must remain configuration-controlled. Additive manufacturing expands design freedom and distributed production while requiring traceability of material, machine, process, and inspection evidence. Autonomous engineering can enhance exploration and prediction, yet human accountability, model validation, and uncertainty management remain essential. Digital product passports support traceability, repair, reuse, recycling, and regulatory transparency, but they depend on trustworthy data and viable circular systems.

The strategic lesson is that emerging technology does not replace PLM fundamentals. It amplifies the consequences of good or poor governance. Successful organisations combine interoperable architecture, lifecycle-oriented processes, skilled people, standards awareness, cybersecurity, and disciplined experimentation.

Key Terms

Software-as-a-Service PLM: A provider-managed PLM capability delivered through subscription-based cloud services.

Hybrid PLM: An architecture combining cloud services with controlled on-premise or private environments.

Low-code platform: A development environment using visual configuration and limited conventional programming.

Shadow IT: Unauthorised or poorly governed technology applications created outside formal information-technology control.

Knowledge graph: A semantic network of entities and relationships used to connect and reason over distributed information.

Ontology: A formal description of concepts, categories, properties, and relationships within a domain.

Digital thread: A connected flow of lifecycle information linking product data, processes, decisions, and evidence.

Extended reality: The collective term for virtual, augmented, and mixed reality technologies.

Additive manufacturing: Production in which material is deposited or solidified layer by layer from digital instructions.

Process qualification: Demonstration that a manufacturing process consistently produces conforming output.

Autonomous engineering: Algorithm-supported or automated performance of engineering analysis, generation, or decision activities.

Generative design: Computational creation and evaluation of design alternatives against specified constraints.

Digital product passport: A governed digital record providing authorised lifecycle information about a product or component.

Semantic interoperability: The ability of systems to exchange information while preserving its intended meaning.

Data provenance: Evidence of the origin, transformation, ownership, and history of a data item.

Model assurance: Evaluation of an analytical or AI model’s validity, limitations, uncertainty, and performance.

Configuration control: Formal management of product versions, baselines, changes, and their approval status.

Human-in-the-loop: An operating arrangement in which a person reviews, supervises, or authorises automated output.

Review Questions

Short Answer Questions

1. What distinguishes SaaS PLM from merely hosting conventional PLM software in a cloud environment?

2. Why is semantic interoperability important in a digital thread?

3. Identify two governance risks associated with low-code PLM development.

4. What information must be controlled in an additive-manufacturing lifecycle record?

5. Why is a digital product passport more than a QR code?

Long Answer Questions

1. Critically compare SaaS, on-premise, and hybrid PLM architectures for a multinational engineering organisation.

2. Explain how knowledge graphs can support configuration impact analysis and compliance management.

3. Discuss the opportunities and limitations of XR across design, manufacturing, and service.

4. Analyse the assurance requirements for autonomous engineering in a safety-critical industry.

5. Explain how standards and organisational governance influence the success of digital product passports.

Analytical / Application Questions

1. A manufacturer wants to deploy an AI system that recommends engineering changes from field-failure data. Develop an assurance and governance plan before production use.

2. An organisation has inconsistent part identifiers across PLM, ERP, and service systems. Which technologies should it postpone, and what foundational actions should it take first? Justify your answer.

3. Design a pilot project combining SaaS PLM, XR, and additive manufacturing for a spare-parts operation. Specify the lifecycle problem, data requirements, controls, measures, and scale-up conditions.

22. Multiple Choice Questions with Answers

Question 1

Which condition most strongly determines whether a SaaS PLM migration will succeed?

A. The number of available dashboard colours

B. Clear data ownership, integration, security, and exit provisions

C. Elimination of all engineering approval activities

D. Maximum customisation of every workflow

Correct Answer: B. Clear data ownership, integration, security, and exit provisions

Question 2

What is the principal semantic benefit of a knowledge graph in PLM?

A. It removes the need for product configuration control

B. It stores every document as an image

C. It represents meaningful relationships among lifecycle entities

D. It guarantees that all source data is accurate

Correct Answer: C. It represents meaningful relationships among lifecycle entities

Question 3

A low-code PLM application allows a design change to bypass impact analysis. This illustrates which risk?

A. Excessive physical prototyping

B. Uncontrolled process configuration

C. Insufficient XR immersion

D. Additive-manufacturing anisotropy

Correct Answer: B. Uncontrolled process configuration

Question 4

Why must XR work instructions be configuration-controlled?

A. Headsets cannot display technical information otherwise

B. An obsolete instruction may cause an incorrect or unsafe operation

C. XR systems are only useful for entertainment

D. Configuration control reduces spatial registration accuracy

Correct Answer: B. An obsolete instruction may cause an incorrect or unsafe operation

Question 5

Which additional information is particularly important for qualifying an additive-manufactured safety-critical part?

A. Only the nominal CAD geometry

B. The colour of the user interface

C. Material batch, machine, process parameters, and inspection evidence

D. The number of employees using the PLM system

Correct Answer: C. Material batch, machine, process parameters, and inspection evidence

Question 6

What is the most appropriate role of human engineers in many current autonomous-engineering applications?

A. They approve outputs without examining assumptions

B. They retain authority to evaluate, verify, and approve relevant outputs

C. They are removed from all safety decisions

D. They replace all algorithmic searches with manual drafting

Correct Answer: B. They retain authority to evaluate, verify, and approve relevant outputs

Question 7

Which statement best describes a digital product passport?

A. A barcode with no associated lifecycle governance

B. A public database containing all confidential supplier information

C. A governed digital record providing authorised product lifecycle information

D. A replacement for reverse logistics and recycling infrastructure

Correct Answer: C. A governed digital record providing authorised product lifecycle information

Question 8

An organisation’s systems exchange data successfully, but different departments interpret “released” differently. Which interoperability dimension is deficient?

A. Syntactic interoperability

B. Semantic interoperability

C. Network interoperability

D. Mechanical interoperability

Correct Answer: B. Semantic interoperability

Question 9

What should an organisation do before scaling an AI-enabled digital thread across the enterprise?

A. Ignore data quality because AI will correct it

B. Define authoritative data, provenance, controls, and measurable lifecycle outcomes

C. Remove all human approval gates

D. Replace every existing system immediately

Correct Answer: B. Define authoritative data, provenance, controls, and measurable lifecycle outcomes

Question 10

In the illustrative ElectraMotion case, why was immediate autonomous decision-making postponed?

A. The company had no interest in service information

B. The pilot showed that model validation and change-control procedures were not yet mature

C. Additive manufacturing was prohibited for all parts

D. SaaS PLM cannot support supplier workflows

Correct Answer: B. The pilot showed that model validation and change-control procedures were not yet mature