Embedded Product Strategy, Governance and Emerging Research

Introduction and Context

An embedded product is not merely a circuit board running firmware. It is a socio-technical system whose commercial success depends on requirements, architecture, supply continuity, safety, cybersecurity, compliance, cost, serviceability, and responsible use. A technically excellent prototype may still fail if its processor becomes obsolete, its software cannot be maintained, its certification evidence is incomplete, or its environmental impact is unacceptable.

Embedded product strategy therefore connects engineering decisions with business objectives and public responsibilities. It addresses questions such as:

• What problem should the product solve, and for whom?
• Which requirements are essential, measurable, and traceable?
• Should the organization build, buy, license, or co-develop a platform?
• How should technical, supply-chain, safety, security, and market risks be governed?
• How can intellectual property, data, compliance evidence, and product knowledge be protected?
• How should products be sustained through long service lives and component obsolescence?
• How can emerging technologies such as RISC-V, chiplets, tinyML, and autonomous systems be evaluated rigorously?

This chapter presents an integrated framework for these decisions at postgraduate level. It treats governance not as administrative overhead but as an engineering control that improves decision quality, accountability, and system dependability.

Learning Objectives

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

1. Construct a lifecycle-oriented strategy for an embedded product.

2. Convert stakeholder needs into governed, verifiable requirements.

3. Evaluate build-versus-buy and platform decisions using technical, economic, and strategic criteria.

4. Establish risk, configuration, change, compliance, and intellectual-property governance.

5. Plan procurement, lifecycle support, obsolescence management, and multidisciplinary collaboration.

6. Critically evaluate ethical and sustainability issues in embedded systems.

7. Assess the opportunities and limitations of RISC-V, chiplets, tinyML, and autonomous systems.

8. Formulate research directions and evidence-based innovation strategies.

1. Product Strategy as a Systems-Engineering Activity

1.1 From product idea to product system

Product strategy defines the intended value proposition, target users, markets, constraints, lifecycle, and differentiation of a product. In embedded systems, the product system generally includes hardware, firmware, application software, cloud or network services, manufacturing processes, maintenance tools, documentation, and human operators.

A useful product strategy contains six linked elements:

1. Need and value: the user problem and measurable benefit.

2. System boundary: what is inside the product and what depends on external infrastructure.

3. Architecture: hardware, software, communications, power, security, and mechanical partitioning.

4. Lifecycle model: conception, development, verification, production, deployment, maintenance, retirement, and disposal.

5. Economic model: development cost, unit cost, support cost, revenue, and total cost of ownership.

6. Governance model: decision rights, evidence, approvals, escalation, and accountability.

A product roadmap should distinguish between committed releases, exploratory research, and assumptions requiring validation. Treating an unvalidated technology as a committed feature is a common source of schedule and cost failure.

1.2 Lifecycle models

The waterfall model emphasizes sequential stages and formal baselines. It is useful where requirements are stable, certification evidence is extensive, and late changes are expensive. Agile and incremental models deliver partial capabilities early and support learning through feedback. They are effective when user needs evolve, but they require disciplined architecture, definition of done, configuration control, and continuous verification.

Safety-critical and security-sensitive projects often use a hybrid lifecycle: iterative development within controlled phases, with formal reviews and evidence gates at system level. Typical gates include concept approval, requirements baseline, architecture review, design verification, production readiness, release approval, and post-deployment review.

No lifecycle model removes uncertainty. It determines when uncertainty is exposed and how changes are controlled. Early prototypes reduce uncertainty about feasibility; field trials reduce uncertainty about usability and operational performance; formal analysis reduces uncertainty about hazards and failure modes.

2. Requirements, Traceability, and Product Governance

2.1 Requirements as verifiable commitments

A requirement should state a necessary property in a manner that is unambiguous, feasible, consistent, traceable, and verifiable. “The device shall be reliable” is a goal, not a testable requirement. A stronger statement might specify operating conditions, mission duration, permitted failure behavior, and evidence required for acceptance.

Requirements may be classified as:

• stakeholder and business requirements;
• functional requirements;
• performance requirements;
• interface requirements;
• safety and security requirements;
• regulatory and environmental requirements;
• manufacturing, service, and disposal requirements.

Each requirement should have an owner, rationale, priority, source, verification method, and status. Verification methods commonly include inspection, analysis, demonstration, and test. Validation asks whether the right product has been built for its intended context; verification asks whether the product conforms to specified requirements.

2.2 Traceability

A traceability structure links needs to requirements, architecture, implementation, tests, anomalies, and release evidence. Bidirectional traceability is particularly important: every requirement should map to implementation and verification, while every significant design element should have a justified requirement.

Traceability supports impact analysis. If a processor, communication interface, or safety assumption changes, the team can identify affected requirements, tests, documents, suppliers, and certifications. Traceability is not necessarily a single large tool database; it may be implemented through integrated requirements, issue, version-control, test-management, and configuration systems.

2.3 Governance and decision rights

Governance defines who may make which decision, using what evidence, under what constraints. A useful governance structure includes:

• a product owner accountable for value and prioritization;
• a systems architect accountable for coherent technical boundaries;
• engineering leads for hardware, firmware, software, mechanical design, security, and verification;
• a safety or assurance authority with independence from delivery pressure;
• supply-chain, quality, regulatory, legal, and service representatives;
• a change-control board for baseline changes.

A governance board should not approve designs by authority alone. Its decisions should record alternatives considered, assumptions, residual risks, evidence, owner, due date, and conditions of approval.

3. Risk, Safety, Security, and Resilience

3.1 Risk concepts

Risk is commonly characterized by the combination of the likelihood of an event and its consequence. A simple qualitative matrix is useful for screening, but numerical risk scores can create false precision. A low-probability catastrophic event may deserve more attention than a frequent minor defect even if both receive similar scores.

Risk management consists of:

1. identifying hazards, threats, failures, and dependencies;

2. analyzing causes, effects, likelihood, and consequences;

3. evaluating acceptability against defined criteria;

4. selecting treatments;

5. monitoring residual risk and assumptions.

Treatment options include elimination, reduction through design, protective mechanisms, transfer through contracts or insurance, and informed acceptance. For embedded products, risk controls should follow a hierarchy: eliminate dangerous functions where possible, make the design inherently safer, add technical safeguards, provide warnings and procedures, and use protective equipment or operator training where relevant.

3.2 Safety and security co-engineering

Safety addresses unintended harm; security addresses malicious or unauthorized actions. They interact. A cyberattack can disable a safety function, while a safety mechanism can create a denial-of-service vulnerability. Security controls can also affect timing, power, usability, and functional safety.

A safety case organizes a structured argument supported by evidence that a system is acceptably safe in a defined context. A security case similarly explains threat assumptions, security claims, controls, testing, and residual exposure. Both require explicit assumptions and operational boundaries.

Important embedded security controls include secure boot, hardware-backed key storage, authenticated update, least privilege, memory protection, secure diagnostics, rollback protection, vulnerability response, and protection of debug interfaces. Security must include the manufacturing and provisioning environment, not only the deployed device.

3.3 Resilience and graceful degradation

An embedded product should define how it behaves when sensors fail, communication is lost, power quality deteriorates, or software becomes uncertain. Graceful degradation may involve a safe state, reduced functionality, local control, redundancy, or controlled shutdown. The appropriate response depends on the hazard and mission. “Fail-safe” is not universally equivalent to “power off”; for an aircraft, medical device, or industrial controller, abrupt loss of control may itself be hazardous.

4. Build-versus-Buy and Platform Decisions

4.1 Strategic alternatives

Organizations may:

• build a proprietary design;
• buy a commercial module or complete subsystem;
• license intellectual property;
• adopt an open-source platform;
• use contract design or manufacturing;
• form a joint development arrangement;
• combine these alternatives in a modular architecture.

The correct choice depends on differentiation, required control, time to market, volume, certification, internal capability, supplier stability, and lifecycle obligations.

4.2 Total cost of ownership

Unit purchase price is only one component of cost. A simplified total-cost model is:

\[

C_{TCO}=C_{NRE}+N C_{unit}+C_{integration}+C_{verification}+C_{certification}+C_{support}+C_{end}

\]

where \(C_{NRE}\) is non-recurring engineering cost, \(N\) is planned quantity, \(C_{unit}\) is per-unit acquisition and manufacturing cost, and the remaining terms represent integration, verification, certification, support, and end-of-life costs. The model is useful for comparing alternatives over the same scope and planning horizon. It should include uncertainty, warranty exposure, inventory, tooling, software licenses, and supplier-management effort where material.

For example, suppose a 10,000-unit product has two alternatives. Build requires $900,000 NRE and $42 per unit; buy requires $180,000 integration and $96 per unit. Ignoring other costs, build cost is:

\[

900{,}000+10{,}000(42)=1{,}320{,}000.

\]

Buy cost is:

\[

180{,}000+10{,}000(96)=1{,}140{,}000.

\]

On these assumptions, buy is $180,000 cheaper. However, if the bought module causes an additional $300,000 certification and lifecycle-support cost, the conclusion reverses. The calculation therefore informs rather than replaces strategic judgment.

4.3 Platform evaluation criteria

A platform should be evaluated against:

• computational, memory, real-time, power, and thermal margins;
• software ecosystem, tools, documentation, and workforce availability;
• security architecture and update mechanisms;
• safety evidence and certification reuse;
• supply continuity, second sources, package availability, and lead times;
• licensing, export controls, patents, and open-source obligations;
• customization, interoperability, and migration cost;
• long-term vendor commitment and end-of-life policy.

Platform reuse can reduce development time, but it can also create common-mode vulnerabilities and strategic dependence. Architectural modularity, abstraction layers, documented interfaces, and migration plans reduce lock-in.

5. Procurement, Supply Chain, and Obsolescence

5.1 Procurement as engineering

Procurement specifications should define functional, quality, environmental, security, traceability, change-notification, and lifecycle requirements. A supplier contract should address counterfeit avoidance, authorized sources, process changes, vulnerability disclosure, software bill of materials, data rights, audit rights, warranty, failure analysis, and last-time-buy procedures.

Supplier selection should not rely solely on price. Relevant evidence includes process capability, field history, financial stability, quality-system maturity, geographic and geopolitical exposure, capacity, and responsiveness to corrective actions.

5.2 Obsolescence management

Obsolescence may affect processors, memories, sensors, operating systems, tools, batteries, connectors, and manufacturing equipment. It is a lifecycle risk from the beginning, not an event at the end.

A practical obsolescence plan includes:

1. identifying critical components and single-source dependencies;

2. recording expected availability and manufacturer lifecycle status;

3. qualifying alternatives or form-fit-function substitutes;

4. maintaining design margins and interface abstractions;

5. preserving programming, test, and manufacturing capability;

6. planning last-time buys using forecast demand and shelf-life limits;

7. defining redesign triggers and customer communication.

Inventory alone is not a solution: stored components may age, and demand forecasts may be wrong. A qualified alternate design can have greater strategic value than a large stockpile.

6. Compliance, Intellectual Property, and Configuration Control

6.1 Compliance by design

Compliance obligations depend on product function, jurisdiction, environment, and market. They may include electromagnetic compatibility, radio requirements, electrical safety, functional safety, cybersecurity, privacy, environmental restrictions, medical or automotive rules, and export controls. Standards provide methods and evidence expectations, but legal applicability must be determined for the specific product and market.

Compliance should be integrated into requirements and architecture. Examples include creepage and clearance, isolation, emissions control, secure update, fault logging, material declarations, accessibility, and retention of test records. Certification performed only at the end often reveals architectural defects that are expensive to correct.

6.2 Intellectual property

Embedded intellectual property includes circuit designs, mask layouts, firmware, algorithms, test methods, datasets, documentation, trademarks, patents, and trade secrets. Governance should distinguish ownership, rights to modify, rights to sublicense, confidentiality, employee and contractor contributions, and rights to reuse background technology.

Open-source software can accelerate development and improve transparency, but licenses impose different obligations. A software bill of materials and license inventory help identify dependencies and manage vulnerability response. Open hardware and open instruction sets can reduce barriers to innovation, but openness does not eliminate verification, security, or compliance responsibilities.

6.3 Configuration and change control

A configuration item is a product element placed under controlled identification and change management. Baselines may include requirements, schematics, bills of materials, source code, binaries, tool versions, test procedures, and manufacturing data. Every released artifact should be reproducible from an identified configuration.

Change control should assess technical impact, safety and security impact, certification impact, supply impact, cost, schedule, and customer communication. Emergency changes require expedited review but should still be recorded and retrospectively evaluated.

7. Multidisciplinary Teams and Organizational Capability

Embedded products require cooperation among electrical, computer, software, mechanical, manufacturing, reliability, cybersecurity, safety, human-factors, regulatory, procurement, legal, and service specialists. Integration failures frequently occur at boundaries rather than within disciplines.

Effective teams establish shared architecture models, interface control documents, common terminology, design reviews, and explicit ownership. Interface requirements should define timing, electrical conditions, data semantics, error behavior, security assumptions, and version compatibility.

A useful review culture separates criticism of an artifact from criticism of a person. Independent review is particularly valuable for safety claims, threat models, supplier assumptions, and release decisions. Teams should also manage cognitive and organizational risks: unrealistic schedules, authority gradients, incentive conflicts, normalization of deviance, and loss of specialist knowledge.

8. Ethics and Sustainability

8.1 Ethical responsibility

Embedded systems increasingly influence health, mobility, employment, privacy, access to services, and physical safety. Ethical engineering requires more than legal compliance. Designers should consider foreseeable misuse, unequal impact, informed consent, explainability where decisions affect people, data minimization, accessibility, and the ability to contest automated decisions.

A product that continuously collects data should justify each data element, limit retention, protect identities, and communicate use in understandable language. Autonomous functions require clear responsibility allocation among manufacturer, operator, owner, and software provider. Human oversight must be meaningful rather than nominal: the human must have sufficient information, authority, time, and competence to intervene.

8.2 Sustainability

Sustainability includes energy during operation, embodied energy and materials, manufacturing waste, logistics, repairability, software-induced replacement, and end-of-life recovery. Design strategies include low-power operation, durable components, modular repair, replaceable batteries, long software support, recycled materials where appropriate, and responsible recycling.

A narrow optimization of energy per computation may increase total environmental impact if it shortens product life or increases manufacturing complexity. Lifecycle assessment should therefore consider the full system boundary and realistic usage patterns. Sustainability claims should be supported by transparent assumptions rather than marketing language.

9. Emerging Technology and Research Directions

9.1 RISC-V

RISC-V is an open instruction-set architecture with a small base and optional extensions. Its value lies in instruction-set flexibility, custom accelerators, educational accessibility, and reduced dependence on a single proprietary ISA provider. It does not automatically provide a processor core, verified implementation, secure boot, safety certification, software ecosystem, or commercial support.

Research and engineering questions include formal verification of cores, secure extension design, trusted execution, coherent heterogeneous systems, compiler quality, vector and matrix acceleration, real-time determinism, and certification evidence. The strategic assessment must distinguish openness of the ISA from openness of a particular core or system-on-chip.

9.2 Chiplets and heterogeneous integration

Chiplets partition a system into dies connected within an advanced package. Potential advantages include reuse of specialized dies, improved manufacturing yield for large systems, technology mixing, and faster product variation. Challenges include die-to-die protocols, latency, power delivery, thermal management, test and repair, package reliability, security of interconnects, and ownership of multi-vendor integration evidence.

Chiplets are attractive where monolithic integration is costly or where heterogeneous process technologies provide clear value. They are not automatically economical for low-volume or thermally constrained products.

9.3 TinyML and edge intelligence

TinyML places machine-learning inference near sensors on resource-constrained devices. Benefits include low latency, reduced bandwidth, offline operation, and improved privacy. Constraints include memory, energy, model accuracy under distribution shift, sensor variability, update mechanisms, and explainability.

A sound TinyML workflow includes representative data collection, labeling governance, model selection, quantization or pruning where justified, hardware-aware benchmarking, validation under environmental variation, secure deployment, and drift monitoring. Accuracy alone is insufficient; false positives, false negatives, latency, energy per inference, and failure behavior must be evaluated in context.

9.4 Autonomous systems

Autonomy involves perception, localization, planning, control, communication, and human interaction under uncertainty. Research challenges include rare-event validation, adversarial conditions, uncertain sensors, changing environments, shared control, formal assurance, and responsibility allocation.

Simulation is valuable but cannot fully replace physical testing. Scenario-based testing should include nominal, degraded, adversarial, and previously unseen conditions. Safety envelopes, runtime monitors, fallback behaviors, and logged evidence are central to responsible deployment.

10. Applied Case: Illustrative Smart Infusion Pump Platform Decision

Background

A fictional medical-device company is developing a connected infusion pump intended for hospitals. The pump must control dosage accurately, operate during network outages, support secure software updates, and remain serviceable for twelve years. The company is deciding whether to build its control platform around a proprietary microcontroller design or buy a safety-oriented commercial compute module.

Problem

The proprietary design offers control over the bill of materials and long-term customization but requires substantial verification and certification work. The commercial module has existing safety documentation and a mature development ecosystem, but its manufacturer provides only a five-year availability commitment and restricts some low-level access.

Analysis

The team identifies safety hazards including incorrect dosage, uncontrolled flow, occlusion response failure, battery depletion, and corrupted software update. Security threats include unauthorized parameter changes, malicious updates, and compromised service tools. Supply risks include memory obsolescence and dependence on one module supplier.

A decision matrix is created, with criteria for safety evidence, lifecycle availability, security, cost, performance, customization, and supplier dependence. Weights are agreed before scoring to reduce political bias. The team also performs a total-cost comparison that includes certification, software maintenance, tooling, alternate qualification, and expected redesign.

Approach and solution

The team selects the commercial module for the first product generation, but rejects an unmodified black-box integration. It negotiates access to security documentation, authenticated update support, change notification, and a ten-year last-time-buy option. A hardware abstraction layer and a qualified alternate module are developed. The dosage-control safety function is isolated from the hospital network and remains capable of safe local operation.

A formal configuration baseline is established. Every software release has a software bill of materials, threat-model update, regression evidence, and approval by quality and safety authorities. The product roadmap includes a future RISC-V-based platform investigation, but only after ecosystem maturity and certification evidence meet defined criteria.

Outcome

The commercial module reduces initial development risk and shortens the verification schedule. The abstraction layer and alternate-source plan reduce lock-in. The project cost is higher than a simple component comparison would suggest, but lifecycle risk is substantially lower. The organization also discovers that service-tool security and hospital network assumptions are as important as the pump controller itself.

Learning points

1. Platform decisions must include certification and lifecycle evidence, not only price and processor performance.

2. A purchased subsystem still requires system-level assurance.

3. Architectural abstraction creates strategic options.

4. Safety, cybersecurity, procurement, and service engineering must participate early.

5. Emerging technology should be evaluated through staged evidence rather than enthusiasm.

11. Challenges, Limitations, and Best Practices

Strategic decisions are limited by uncertain forecasts, incomplete supplier information, changing regulation, immature standards, and organizational bias. Quantitative scoring models can conceal disagreements about assumptions. Cost models can omit opportunity cost and failure consequences. Technology roadmaps can become self-fulfilling narratives rather than evidence-based plans.

Best practices include:

• define product success using measurable technical, user, commercial, and societal outcomes;
• maintain a living risk register linked to requirements and decisions;
• use independent review for safety, security, and major supplier assumptions;
• make lifecycle and end-of-life requirements explicit;
• evaluate total cost and uncertainty, not purchase price alone;
• design interfaces and abstractions to enable migration;
• preserve reproducible build and test environments;
• maintain software bills of materials and vulnerability response capability;
• include operators, maintainers, affected communities, and service personnel in validation;
• use prototypes and pilots to test assumptions before committing to scale;
• record rejected alternatives and the evidence behind major decisions;
• treat ethics and sustainability as design criteria rather than post-release communications.

Chapter Summary

Embedded product strategy integrates user value, architecture, lifecycle, economics, compliance, risk, and organizational capability. Requirements must be precise, traceable, owned, and verifiable. Governance establishes decision rights, evidence, baselines, and accountability. Risk management must address safety, cybersecurity, supply continuity, human factors, and graceful degradation.

Build-versus-buy decisions require total-cost and lifecycle analysis, while platform selection must consider ecosystems, certification, security, lock-in, and migration. Procurement contracts should protect quality, continuity, data rights, vulnerability response, and change visibility. Obsolescence management begins during architecture and includes alternatives, abstractions, inventory strategy, and redesign triggers.

Intellectual-property and configuration governance protect both innovation and reproducibility. Multidisciplinary collaboration is essential because failures often occur at interfaces. Ethical and sustainable design requires attention to privacy, autonomy, accessibility, environmental impact, repairability, and end-of-life. RISC-V, chiplets, tinyML, and autonomous systems offer significant research opportunities but introduce evidence, integration, assurance, and lifecycle challenges. Responsible innovation is therefore a staged process of forming hypotheses, testing them, governing risks, and learning from operational evidence.

Key Terms

Product strategy: A plan linking customer value, architecture, lifecycle, resources, and competitive purpose.

Lifecycle: The sequence from conception through development, production, operation, maintenance, and retirement.

Requirement: A necessary, testable statement of a system property or constraint.

Traceability: The ability to link needs, requirements, design, implementation, tests, and evidence.

Governance: The allocation of authority, accountability, decisions, and oversight.

Risk: The potential effect of uncertainty on objectives, including harmful events and consequences.

Safety case: A structured argument and evidence supporting acceptable safety.

Threat model: An analysis of assets, attackers, vulnerabilities, threats, and controls.

Total cost of ownership: The complete cost of acquiring, integrating, operating, supporting, and retiring an option.

Platform: A reusable hardware and software foundation for one or more products.

Obsolescence: Loss of availability, support, or usability of a product component or technology.

Configuration item: A controlled product element with an identified version and change history.

Baseline: An approved configuration used as a reference for development or release.

Intellectual property: Legally or commercially protected creations, designs, code, data, and know-how.

Software bill of materials: An inventory of software components and dependencies in a product.

RISC-V: An open standard instruction-set architecture supporting base and optional extensions.

Chiplet: A separately fabricated die integrated with other dies in a package.

TinyML: Machine-learning inference implemented on resource-constrained embedded hardware.

Autonomous system: A system that senses, decides, and acts with limited direct human control.

Graceful degradation: Controlled reduction of capability while maintaining safe or useful behavior.

Review Questions

Short Answer Questions

1. Why is product strategy broader than selecting a processor and writing firmware?

2. Distinguish verification from validation in embedded product development.

3. Identify four elements that should be included in a supplier contract.

4. Why does a bought subsystem still require system-level assurance?

5. State two benefits and two challenges of TinyML.

Long Answer Questions

1. Explain how requirements traceability supports change impact analysis, compliance, and lifecycle maintenance.

2. Discuss a hybrid lifecycle model for a safety- and security-sensitive embedded product.

3. Compare build, buy, license, and open-platform strategies using technical and strategic criteria.

4. Explain how safety and cybersecurity should be co-engineered in a connected embedded system.

5. Evaluate the opportunities and limitations of RISC-V and chiplet-based architectures.

Analytical / Application Questions

1. An organization plans to sell 20,000 units. Option A requires $1.2 million NRE and costs $35 per unit; Option B requires $250,000 integration and costs $82 per unit. Calculate the direct five-year acquisition and development cost of each option, then identify additional lifecycle variables that could change the decision.

2. Design a governance and evidence plan for an autonomous industrial inspection robot operating with intermittent communication. Include requirements, risk, cybersecurity, human oversight, testing, and incident response.

3. Develop an obsolescence and sustainability strategy for a medical embedded product expected to operate for fifteen years. Explain how architecture, procurement, software maintenance, repairability, and end-of-life recovery should interact.

Multiple Choice Questions with Answers

Question 1

Which statement best describes product governance in an embedded-system organization?

A. It is limited to approving the final circuit schematic.

B. It defines decision rights, evidence, accountability, and controlled changes.

C. It replaces engineering testing with management review.

D. It focuses only on reducing the unit purchase price.

Correct Answer: B. It defines decision rights, evidence, accountability, and controlled changes.

Question 2

Which activity primarily distinguishes validation from verification?

A. Checking whether implementation conforms to a specified requirement

B. Inspecting source-code formatting

C. Determining whether the product solves the intended user problem in context

D. Confirming that a component has a part number

Correct Answer: C. Determining whether the product solves the intended user problem in context

Question 3

A product has NRE of $900,000 and a unit cost of $42 for 10,000 units. What is the corresponding direct cost?

A. $1,032,000

B. $1,320,000

C. $1,380,000

D. $4,200,000

Correct Answer: B. $1,320,000

Question 4

Which is the strongest reason to maintain a hardware abstraction layer?

A. It guarantees that no component can fail.

B. It eliminates the need for system testing.

C. It can reduce migration cost when the underlying platform changes.

D. It prevents all software vulnerabilities.

Correct Answer: C. It can reduce migration cost when the underlying platform changes.

Question 5

Which statement about RISC-V is correct?

A. An open ISA automatically provides a certified processor implementation.

B. RISC-V is an open instruction-set architecture with optional extensions.

C. RISC-V can only be used in desktop computers.

D. RISC-V eliminates the need for compilers and verification.

Correct Answer: B. RISC-V is an open instruction-set architecture with optional extensions.

Question 6

Which practice most directly supports software supply-chain visibility?

A. Removing version numbers from releases

B. Maintaining a software bill of materials

C. Disabling authenticated updates

D. Using only proprietary variable names

Correct Answer: B. Maintaining a software bill of materials

Question 7

Why can inventory alone fail as an obsolescence strategy?

A. Stored components never require environmental control.

B. Demand, shelf life, and future manufacturing capability may remain uncertain.

C. Inventory always increases software performance.

D. Inventory removes the need for alternate qualification.

Correct Answer: B. Demand, shelf life, and future manufacturing capability may remain uncertain.

Question 8

A principal benefit of TinyML is that it can provide:

A. Unlimited model memory on a microcontroller

B. Local inference with reduced latency and communication dependence

C. Perfect accuracy under distribution shift

D. Automatic ethical approval for data collection

Correct Answer: B. Local inference with reduced latency and communication dependence

Question 9

Which approach is most appropriate for an autonomous system operating under uncertainty?

A. Test only nominal scenarios in simulation

B. Remove all human oversight after deployment

C. Use scenario-based testing, runtime monitoring, and fallback behavior

D. Treat communication loss as impossible

Correct Answer: C. Use scenario-based testing, runtime monitoring, and fallback behavior

Question 10

Which item is an example of a configuration item?

A. An informal conversation about a possible feature

B. An approved firmware binary identified for a release

C. An unrecorded personal preference of a developer

D. A marketing slogan without technical content

Correct Answer: B. An approved firmware binary identified for a release