Research White Paper

IAS-Research.com · KeenComputer.com · KeenDirect.com

Finding the Hidden Questions in Hardware–Software Co-Design

Applying The Craft of Research to Electronic System-Level Design, Model-Based Systems Engineering, Embedded Computing, FPGA Design, and Engineering Innovation

Prepared for IAS-Research.com, KeenComputer.com and KeenDirect.com · Author: IASR-KEEN · October 2026

Abstract

Hardware–software co-design is often presented as a technical optimization problem: select a processor, write firmware, implement hardware accelerators, simulate the design, and integrate the resulting components. However, this sequence can begin too late. Before selecting a processor, an FPGA, an RTOS, an embedded Linux distribution, a simulation environment, or a systems-engineering tool, the engineering team must establish what problem it is actually trying to solve, what evidence would demonstrate success, and which assumptions are driving its architectural decisions.

This white paper applies the research-question and argument-building approach of Wayne C. Booth, Gregory G. Colomb, Joseph M. Williams, Joseph Bizup, and William T. FitzGerald's The Craft of Research to hardware–software co-design. It combines that approach with model-based systems engineering (MBSE), electronic system-level (ESL) design, design-space exploration, behavioral-driven development (BDD), domain-driven design (DDD), virtual platforms, hardware description languages, embedded operating systems, simulation, and verification.

The central proposition is that successful co-design begins by discovering and testing the hidden questions and assumptions behind the engineering problem—not by choosing tools first.

The paper develops a systematic method for identifying those questions, converting them into testable hypotheses, mapping each question to appropriate engineering tools, and producing traceable evidence from requirements through physical validation. Two illustrative systems—an AI-assisted automotive diagnostics platform (OBD-AI) and a smart inverter for distributed energy resources—demonstrate how the methodology can be applied to embedded, electrical, AI, and cyber-physical systems.

The paper also establishes complementary roles for IAS-Research.com as the research and systems-architecture partner, KeenComputer.com as the software, integration, and deployment partner, and KeenDirect.com as the planned hardware and computing-supply channel.

Keywords: Hardware–software co-design, Craft of Research, hidden research questions, engineering assumptions, MBSE, SysML, electronic system-level design, SystemC/TLM, FPGA, ARM, RISC-V, QEMU, Renode, RTOS, Yocto, BDD, DDD, verification, digital twins, OBD-AI, smart inverters, engineering innovation.

1. Introduction: Why the Hidden Question Matters

1.1 The difference between building a system and solving a problem

Imagine an engineering team tasked with designing an embedded controller for a smart inverter. The team immediately discusses:

  • Which ARM or RISC-V processor should be used?
  • Should the design include an FPGA?
  • Should firmware run on FreeRTOS, Zephyr, or embedded Linux?
  • Should the team use MATLAB/Simulink, SystemC/TLM, QEMU, or Renode?
  • Should the project use Sparx Systems Enterprise Architect, Git, and automated CI?
  • Should the controller incorporate an AI model?

These are legitimate engineering questions, but they may conceal the more important questions:

  • What exact control problem must the inverter solve?
  • What are the required control-loop deadlines and worst-case execution times?
  • Which functions require deterministic execution?
  • What happens if communication fails or sensor data becomes invalid?
  • Which functions require hardware acceleration, and which can run on a processor?
  • What evidence would demonstrate that the design meets its safety, performance, and cost requirements?
  • Is AI necessary for the core control function, or would a conventional control algorithm be safer and more economical?

The initial tool-selection discussion assumes that the system's essential problem, constraints, and success criteria are already understood. Frequently, they are not.

A technically impressive prototype may therefore solve the wrong problem. Conversely, a modest implementation may produce greater commercial value if it addresses the actual operational need with lower cost, risk, and maintenance effort.

1.2 Applying The Craft of Research

Primary methodological foundation

The Craft of Research

The fourth edition's research framework encourages researchers to move from a topic to a research question, from that question to a consequential problem, and from that problem to a claim supported by reasons and evidence.

Applied to co-design, this means that the team should explain not only what it proposes to build, but also why the problem matters, what remains uncertain, how the proposed investigation will reduce that uncertainty, and what evidence could disprove its preferred solution.

This approach changes the engineering workflow. Rather than treating tools as the starting point, the team treats tools as instruments selected to answer specific questions.

The paper uses The Craft of Research as a methodological foundation. The co-design examples, tool mappings, hypotheses, and organizational recommendations that follow are engineering applications of that framework, not claims that the book itself prescribes particular hardware or software products.

1.3 The central research question

How can a systematic method for discovering hidden questions and testing architectural assumptions improve the correctness, performance, safety, cost, and commercial viability of hardware–software co-designed systems?

This overarching question leads to several subquestions:

  1. How can engineering teams distinguish stakeholder needs from assumed solutions?
  2. How can requirements be converted into measurable and verifiable criteria?
  3. How can teams decide which functions belong in software, FPGA logic, dedicated hardware, or a combination?
  4. Which tools are necessary to investigate each class of uncertainty?
  5. How can virtual prototypes and simulation provide credible evidence without creating false confidence?
  6. How can architectural decisions remain traceable to their original research questions?
  7. How can the resulting engineering evidence support commercialization, maintenance, and future innovation?

The objective is not to maximize the number of tools used. It is to minimize consequential uncertainty before expensive design commitments are made.

2. The Research Problem: From Topic to Testable Engineering Claim

2.1 Topic, question, problem, claim, and evidence

A useful interpretation of The Craft of Research separates five elements that are often confused in engineering projects.

1. Topic — What are we studying?

Hardware–software co-design for embedded systems.

2. Research question — What do we need to discover?

Under what workload, timing, power, and cost constraints does an FPGA accelerator outperform a processor-only implementation?

3. Research problem — Why does the answer matter?

Choosing the wrong architecture can increase latency, power consumption, verification effort, manufacturing cost, and maintenance burden.

4. Claim — What do we propose?

Select the hardware–software partition using representative workloads, explicit constraints, measured performance, and lifecycle cost rather than intuition alone.

5. Evidence — How will we know?

Compare reproducible processor-only, FPGA-accelerated, and hybrid implementations against the same acceptance criteria.

The distinction matters because a design decision is not evidence. An architecture diagram demonstrates a proposed structure, not that the structure meets its requirements. A successful simulation demonstrates behavior under the modeled conditions, not necessarily correct behavior on physical hardware.

2.2 A practical example: FPGA or software?

Consider a streaming signal-processing workload.

A weak engineering argument might be:

The algorithm is computationally intensive, so it should be implemented in an FPGA.

This conclusion contains several unstated assumptions:

  • The processor cannot meet the deadline.
  • The algorithm maps efficiently to parallel hardware.
  • Data-transfer overhead will not erase the acceleration benefit.
  • FPGA development and verification costs are acceptable.
  • The workload is sufficiently stable to justify hardware specialization.
  • The selected FPGA is available and supported by the toolchain.
  • The complete system, rather than only the kernel, will benefit.

A research-driven argument is more defensible:

If the representative workload exceeds the processor's timing or power budget, and an FPGA implementation meets the same functional requirements with acceptable end-to-end latency, energy consumption, verification effort, and lifecycle cost, then FPGA acceleration is justified.

The difference is that the second statement specifies conditions that can be investigated and potentially disproved.

3. The Hidden-Question Method

3.1 What is a hidden question?

A hidden question is an unresolved issue that materially affects the choice, correctness, or value of an engineering solution but has not yet been explicitly formulated.

It may be hidden inside a requirement, an architecture diagram, a proposed technology, a procurement decision, a software interface, or an assumption about the operating environment.

For example, the statement “the controller must respond in real time” conceals several questions:

  • What is the maximum permissible response time?
  • Is the deadline a hard real-time constraint or a performance target?
  • Is the requirement an average, a percentile, or a worst-case bound?
  • Does the timing budget include sensor acquisition, computation, communication, and actuator response?
  • Under what processor load, interrupt conditions, and fault scenarios must the deadline be met?

Until these questions are resolved, “real time” is an aspiration rather than a verifiable requirement.

3.2 Seven classes of hidden questions

1. Problem-definition questions

What operational problem exists? Who experiences it? What happens if it is not solved? What is the actual need, rather than the requested product?

2. Architectural questions

Which functions belong in software, programmable logic, dedicated hardware, or external services? Which interfaces and dependencies determine the partition?

3. Performance and physical questions

Can the design satisfy timing, power, memory, thermal, bandwidth, and physical-interface constraints under realistic conditions?

4. Verification questions

What constitutes sufficient evidence? Which properties can be tested in simulation, which require formal analysis, and which require physical measurements?

5. Safety, security, and reliability questions

What happens when sensors, communications, firmware, power supplies, or external dependencies fail? What must remain safe when normal operation becomes impossible?

6. Lifecycle and commercial questions

Who maintains the system? Are components available? What are the engineering, manufacturing, support, certification, and upgrade costs?

7. Knowledge and evidence questions

Which claims are documented facts, which are estimates, and which are untested assumptions? What experiment would change the decision?

These categories form a discovery checklist. They are not mutually exclusive: one unresolved timing assumption may affect the architecture, safety case, verification plan, and commercial cost simultaneously.

3.3 From a hidden assumption to a research experiment

Consider the assumption:

An RTOS is sufficient for the complete control system.

A disciplined investigation proceeds through the following steps.

  1. State the assumption. The selected processor and RTOS can meet all required deadlines.
  2. Define the operating conditions. Specify interrupt rates, concurrent tasks, communication traffic, memory pressure, and fault conditions.
  3. Establish measurable criteria. Define deadlines, jitter limits, worst-case execution-time targets, and acceptable failure behavior.
  4. Select the appropriate evidence. Use scheduling analysis, profiling, simulation, stress testing, and measurements on representative hardware.
  5. Compare alternatives. Evaluate an optimized RTOS implementation, hardware acceleration, or a hybrid architecture if the baseline fails.
  6. Record the result. Link the decision to the requirement, test evidence, limitations, and conditions under which it must be reconsidered.

The outcome may be that the RTOS is sufficient, that selected functions need FPGA acceleration, or that the entire architecture should be reconsidered. The method does not predetermine the answer.

4. A Taxonomy of Assumptions in Hardware–Software Co-Design

The following table identifies assumptions that commonly deserve explicit investigation. They are candidate risks, not assertions that every project contains these defects.

Assumption

Hidden research question

Evidence required

The requirements are complete

Which operating conditions and failure modes are omitted?

Stakeholder analysis, operational scenarios, requirements reviews

Average latency is sufficient

Must the system meet a deadline under worst-case conditions?

Timing analysis, worst-case measurements, stress tests

More parallelism means better performance

Does parallel execution outweigh synchronization and transfer overhead?

End-to-end profiling and workload benchmarks

An FPGA is necessary

Can a processor meet performance, power, and cost requirements?

Comparable processor-only and FPGA-accelerated prototypes

A virtual platform is accurate

Which timing, peripheral, and fault behaviors does it model?

Model validation against reference hardware or independent evidence

Simulation proves correctness

Which properties remain untested in physical hardware?

Coverage analysis, formal checks, hardware-in-the-loop tests

AI improves diagnosis or control

Does AI improve outcomes beyond a conventional baseline?

Representative datasets, comparative evaluation, uncertainty analysis

Linux is always preferable

Does the workload need its services, and can it meet the timing constraints?

Workload analysis, scheduling design, latency and resource measurements

The interface is stable

What happens when data, timing, units, or protocol versions change?

Interface contracts, conformance tests, version-compatibility tests

Components remain available

Can the architecture be maintained and reproduced over its lifecycle?

Supply-chain review, support policy, replacement and migration plan

Security can be added later

Which trust boundaries and attack surfaces originate in the architecture?

Threat modeling, security requirements, design and penetration testing

The prototype represents the product

Which manufacturing, thermal, electrical, regulatory, and deployment constraints are absent?

Representative hardware testing and production-readiness review

4.1 The assumption register

Each project should maintain a structured register rather than leaving assumptions in meeting notes.

Recommended fields:

  • Assumption ID and description
  • Origin and responsible owner
  • Why the assumption matters
  • Affected requirements and architectural decisions
  • Confidence level and supporting evidence
  • Consequence if the assumption is false
  • Planned experiment or analysis
  • Acceptance criteria
  • Decision date and review trigger

An assumption with low confidence and severe consequences deserves early investigation. An assumption with low consequences may reasonably remain open until more information becomes available.

This is the engineering equivalent of asking whether the evidence actually supports the claim and whether the reasoning depends on a premise that readers or stakeholders might reject. The fourth edition of The Craft of Research treats claims, reasons, evidence, and warrants as distinct elements of a defensible argument.

bibliovault.org

+1

5. Using the Craft of Research to Build an Engineering Argument

5.1 The argument structure

The methodology can be translated into an engineering decision chain.

Question

What uncertainty prevents a defensible design decision?

Problem

Why does that uncertainty matter to cost, safety, performance, or value?

Claim and rationale

Which design approach is proposed, and why should it work?

Evidence

Which calculations, models, tests, or measurements support the claim?

Decision and qualification

What can be concluded, what remains uncertain, and under what conditions is the decision valid?

This chain prevents a common engineering error: treating a tool's output as proof of the entire system's correctness.

For example, a simulation may show that an algorithm performs correctly with ideal sensor data. That does not establish that the physical sensors have adequate accuracy, that communication latency is acceptable, or that the controller remains safe during a sensor failure.

5.2 Warrants: the reasoning between evidence and decision

A warrant is the reasoning that connects evidence to a claim. It is particularly useful for reviewing architecture proposals.

Consider the following argument:

  • Claim: Move a signal-processing function into FPGA logic.
  • Reason: The current processor implementation misses its deadline.
  • Evidence: Repeatable timing measurements show deadline violations under the defined peak workload.
  • Warrant: A hardware implementation can reduce the relevant execution time enough to meet the deadline.
  • Qualification: The improvement must persist after accounting for data movement, synchronization, resource use, and system integration.

The warrant is the crucial part. A faster FPGA kernel does not necessarily produce a faster complete system. The architecture must be evaluated end to end.

An alternative argument may show that an optimized algorithm, DMA configuration, or scheduling policy solves the timing problem without an FPGA. The team should investigate this possibility before committing to specialized hardware.

5.3 Counterarguments are design inputs

A strong engineering proposal anticipates objections instead of ignoring them.

Proposal

Important counterquestion

Use an FPGA accelerator

Can optimization or a different processor meet the requirement more cheaply?

Use embedded Linux

Does the critical workload require bounded timing, and how will deadlines be guaranteed?

Use a virtual platform

How will its peripheral behavior and timing accuracy be validated?

Use AI for diagnostics

Does the model outperform a rule-based baseline on previously unseen faults?

Use a digital twin

Which real-world measurements keep the twin synchronized with the physical system?

Build a custom board

Does the performance or power benefit justify nonrecurring engineering and supply-chain risks?

The aim is not to eliminate engineering judgment. It is to make the judgment explicit, challengeable, and supported by evidence.

6. Research Questions That Drive the Co-Design Architecture

The following research agenda turns the broad problem into investigations that can guide actual development.

RQ1 — Requirements and operational context

How can stakeholder needs be converted into measurable, traceable requirements before implementation decisions are made?

Hidden assumptions to investigate:

  • Stakeholders agree on the meaning of “fast,” “reliable,” and “safe.”
  • Normal operating scenarios adequately represent real-world use.
  • All relevant fault conditions have been identified.
  • The acceptance criteria can be objectively measured.

Evidence should include stakeholder interviews, operational scenarios, use cases, requirements reviews, measurable acceptance criteria, and traceability to verification activities.

RQ2 — Hardware–software partitioning

Which allocation of functions across processors, FPGA logic, peripherals, and software best satisfies the complete set of system constraints?

The investigation should compare plausible architectures against the same workload and acceptance criteria.

Relevant measurements include:

  • End-to-end latency and jitter
  • Throughput and queueing delay
  • CPU, memory, and FPGA resource utilization
  • Data-transfer and synchronization overhead
  • Power and thermal behavior
  • Development, verification, and lifecycle cost

The optimal architecture is not necessarily the one with the fastest individual function. It is the one that satisfies the requirements with an acceptable overall cost and risk.

RQ3 — Model fidelity and virtual platforms

How accurately can simulation and virtual platforms predict behavior that matters to the target implementation?

The hidden assumption is that a model is sufficiently faithful to support the decision being made.

The answer depends on the question. An instruction-set emulator may be useful for firmware development but inadequate for predicting a specific peripheral's electrical timing. A transaction-level model may be appropriate for architectural throughput exploration but insufficient for detailed signal-integrity analysis.

The team must specify which properties the model represents, which it abstracts, and which require separate verification.

RQ4 — Real-time behavior and fault response

Can the selected architecture meet timing constraints under realistic workload and fault conditions?

This question requires a timing budget spanning the complete path from input acquisition through processing, communication, and actuation.

For safety-relevant functions, the investigation should also consider missed deadlines, stale data, interrupt overload, watchdog behavior, recovery time, and defined safe states.

RQ5 — Verification and evidence quality

What combination of analysis, simulation, software testing, hardware testing, and system-level validation is sufficient for the project's risks?

There is no single universal answer. The required evidence depends on the system's criticality, applicable standards, architecture, operating environment, and failure consequences.

The test strategy must identify the properties that each verification method can establish and explicitly record the gaps between modeled and physical behavior.

RQ6 — Maintainability and commercialization

Can the selected architecture be supported, reproduced, upgraded, and economically delivered over its intended lifecycle?

Research should include component availability, toolchain maturity, license obligations, staffing, maintenance effort, update mechanisms, manufacturing cost, certification needs, and product support.

This question connects technical design to engineering innovation and business viability. A technically feasible system may still be commercially unsuitable if it cannot be manufactured, supported, or maintained economically.

7. The Engineering Toolchain: Why Each Tool Is Needed

The most important tool-selection principle is:

Choose a tool because it answers a defined research question, produces required evidence, or reduces a consequential engineering risk. Do not introduce a tool merely because it is popular.

The same tool may support several research questions, and one question may require several tools. The following reference architecture distinguishes complementary tools rather than treating them as interchangeable alternatives.

7.1 Tool-selection matrix

Tool or technology

Hidden question it helps answer

Why it is needed

What it does not prove by itself

Sparx Enterprise Architect (EA)

Are requirements, architecture, behavior, and verification connected?

Maintains models, relationships, traceability, and architectural decisions

That the implementation is correct

SysML / MBSE

What must the complete system do, and how are its parts related?

Models requirements, structure, behavior, interfaces, constraints, and verification

That the modeled design meets physical requirements

UML

How should software structure, interactions, and state behavior be represented?

Documents classes, components, sequences, and state machines

That runtime behavior matches the model

BDD / Gherkin / Cucumber

What observable behavior must software demonstrate?

Turns examples and acceptance criteria into executable tests when appropriately implemented

Electrical timing, hardware correctness, or complete safety

DDD

Which business and engineering concepts have distinct meanings and responsibilities?

Defines bounded contexts, domain models, ownership, and software boundaries

Processor selection or electrical performance

SystemC / TLM

Which architecture and communication model best fits the workload?

Enables system-level modeling, architectural exploration, and virtual prototyping

Pin-level timing or physical-board correctness unless separately modeled and validated

MATLAB / Simulink

Does the algorithm or control model behave as expected across operating scenarios?

Supports mathematical modeling, control design, numerical simulation, and relevant code-generation workflows

That generated code or physical hardware automatically meets every requirement

Verilog / SystemVerilog / VHDL

Can the required digital behavior be implemented in programmable logic?

Describes hardware behavior and structure for simulation, synthesis, and verification

That a design meets timing and resource constraints before implementation analysis

Yosys / nextpnr

Can supported FPGA designs be synthesized, placed, routed, and analyzed?

Provides open-source FPGA implementation flows for supported devices

Support for every FPGA family or guaranteed production timing

QEMU

Can firmware or an operating-system image run in a modeled processor and machine environment?

Supports instruction execution, system emulation, debugging, and software development

Accurate behavior of every peripheral or physical timing

Renode

Can embedded firmware and modeled peripherals be tested together?

Supports virtual embedded platforms, automation, and repeatable testing

Complete physical electrical behavior or every target-board fault

Zephyr / FreeRTOS

How should embedded tasks, interrupts, synchronization, and drivers be implemented?

Provides RTOS services for appropriately constrained embedded applications

That deadlines are met without workload analysis and target measurements

Yocto Project / OpenEmbedded

How can a maintainable, reproducible embedded Linux image be built for the target?

Provides build recipes, configuration, image generation, and integration mechanisms

That Linux is the correct choice for a particular real-time function

Git

Can design changes and evidence be traced to exact source revisions?

Provides version control, branching, review history, and reproducible change records

That a particular revision is correct

CI and automated testing

Does every relevant change trigger the required checks?

Automates builds, tests, static analysis, and release gates

That untested conditions or physical failures cannot occur

Hardware-in-the-loop (HIL)

Does the integrated controller behave correctly against real I/O and representative physical dynamics?

Exercises the target controller in a controlled system-level environment

All possible field conditions or full certification

Oscilloscope, logic analyzer, power instrumentation

Does the physical implementation meet electrical, timing, and power expectations?

Provides measured evidence from real hardware

Behavior outside the measured conditions

SPICE / electrical simulation

Do circuit-level assumptions hold under modeled electrical conditions?

Investigates analog, switching, and component-level behavior

Perfect correspondence with physical components and parasitics

SystemC and TLM are particularly useful when architectural decisions need to be evaluated before low-level implementation. Their standardized interfaces support model exchange and virtual-prototype workflows.

systemc.org

+1

QEMU and Renode serve different purposes: QEMU provides machine and processor emulation, while Renode emphasizes virtual embedded platforms and automated testing.

QEMU documentation

+1

Similarly, Zephyr supplies embedded operating-system facilities, whereas Yocto provides infrastructure for creating customized embedded Linux distributions. They solve different problems and should not be treated as competing versions of the same tool.

docs.zephyrproject.org

+1

7.2 Enterprise Architect as the research traceability repository

For a project using Sparx Enterprise Architect, the most valuable role is not simply drawing UML diagrams. It is maintaining traceability across the engineering argument.

A proposed relationship chain is:

1. Stakeholder need

2. Research question

3. System requirement

4. Architecture element

5. Allocated hardware/software function

6. Implementation and test

7. Evidence and decision

For example, a requirement stating that a controller must respond within a defined deadline should link to:

  1. The operational scenario that creates the deadline.
  2. The timing budget and its assumptions.
  3. The architectural components allocated to the control path.
  4. The relevant firmware tasks or FPGA logic.
  5. The simulation and physical tests.
  6. The recorded measurements and acceptance decision.

EA can serve as the model repository, while Git stores source code and versioned artifacts, and the CI system records build and test results. The integrations should use explicit identifiers, controlled baselines, and documented synchronization rules.

Important distinction: SysML and UML are modeling languages; EA is a modeling environment. BDD is a behavior-specification and testing approach; Cucumber is one possible implementation tool. SystemC/TLM, QEMU, Renode, and Yocto have different technical responsibilities. Treating these distinctions correctly helps prevent an unnecessarily complicated toolchain.

7.3 When is a tool actually necessary?

A tool should be introduced when its expected benefit justifies its setup, learning, integration, and maintenance cost.

Use the following decision test:

  • Is there a research question that cannot be answered adequately with the current tools?
  • Does the proposed tool provide a distinct capability or materially improve the quality of evidence?
  • Can its outputs be connected to the project requirements and source revisions?
  • Can the team validate its models and results?
  • Will the tool remain supportable throughout the project lifecycle?

If a lightweight Python benchmark can answer a processor-performance question, a full virtual platform may not yet be justified. If the project involves multiple processors, modeled peripherals, complex communication, and early firmware development, a virtual platform may provide substantial value.

Likewise, not every project requires FPGA acceleration, custom Linux, HIL, or a comprehensive MBSE repository. The requirements and risk profile determine the necessary toolchain.

8. Case Study A: OBD-AI — Automotive Diagnostics and Embedded Intelligence

8.1 The initial problem

OBD-AI is a proposed IAS-Research/KeenComputer system for automotive diagnostics, integrating vehicle telemetry, diagnostic trouble codes (DTCs), technical service information, AI-assisted reasoning, and technician-facing recommendations.

A superficial formulation might be:

Build a mobile application connected to an OBD-II adapter and add an LLM to diagnose vehicle faults.

This statement assumes that the main challenge is integrating an AI model. In practice, the system must address multiple independent questions:

  • Is the vehicle data accurate, complete, and correctly interpreted?
  • Does the adapter support the required protocols and parameters?
  • Which faults can be inferred from available measurements?
  • How will the system distinguish a measured fact from a probabilistic hypothesis?
  • How will technical service information be linked to a particular vehicle configuration?
  • What should happen when the data is incomplete or contradictory?
  • Which functions must operate locally, and which can depend on a remote AI service?
  • How will a technician verify a recommendation before acting on it?

These questions define the engineering and research problem more clearly than the choice of an LLM or vector database.

8.2 Hidden assumptions and how to test them

Hidden assumption

Research question

Suitable tools or methods

DTCs identify the failed component

How often does a code identify a symptom rather than a root cause?

Diagnostic datasets, service manuals, expert-reviewed test cases

A generic model understands vehicle-specific data

Does the model correctly interpret the selected vehicle's parameters, codes, and service procedures?

Reference datasets, protocol decoders, controlled evaluation

RAG prevents hallucinations

Are generated recommendations actually supported by retrieved documents and measurements?

RAG evaluation, source attribution, adversarial tests, expert review

A knowledge graph improves diagnosis

Does graph-based reasoning improve accuracy or explainability over a strong baseline?

Comparative experiments, graph database, controlled diagnostic tasks

Remote AI is always available

What functions remain usable during network outages or service failures?

Network fault injection, offline tests, service simulation

A diagnostic recommendation is safe

Can the system distinguish low-risk maintenance advice from actions requiring professional verification?

Hazard analysis, safety rules, human review, acceptance tests

The proposed architecture must separate raw telemetry, protocol interpretation, diagnostic reasoning, knowledge retrieval, and user-facing recommendations. This separation makes it possible to test each claim independently.

8.3 Proposed architecture

Vehicle and OBD-II interface

ECU data · DTCs · supported parameters

Telemetry and protocol layer

Validation · timestamps · units · vehicle context

Diagnostic engine

Rules · fault hypotheses · signal analysis

Knowledge services

Service manuals · vector retrieval · knowledge graph

Evidence-grounded advisory layer

Ranked hypotheses · supporting evidence · uncertainty · next tests

Technician review and feedback

Confirm · reject · collect more evidence · document outcome

This architecture is a proposed design, not a validated implementation. Actual interfaces, data availability, supported vehicles, and diagnostic coverage must be established through prototype testing.

8.4 Why each tool is needed in OBD-AI

  • Enterprise Architect and SysML: model system boundaries, vehicle interfaces, diagnostic workflows, fault scenarios, and requirement traceability.
  • UML and DDD: define software interactions and separate telemetry, diagnostic reasoning, knowledge, and fleet-management responsibilities.
  • BDD and Cucumber: express acceptance scenarios such as “given an invalid sensor value, when diagnosis is requested, then the system must flag the data and avoid presenting an unsupported conclusion.”
  • QEMU or Renode: investigate embedded firmware and modeled interfaces where the target processor and platform are supported.
  • SystemC/TLM: explore a virtual ECU or hardware/software architecture if processor, peripheral, and communication trade-offs warrant system-level modeling.
  • Docker or Podman: create repeatable development and integration environments for the backend, databases, and AI services.
  • RAGFlow or another retrieval pipeline: investigate retrieval quality, source traceability, and grounded response generation.
  • Vector database and graph database: test whether semantic retrieval and explicit relationships improve diagnostic tasks over simpler baselines.
  • Git and CI: version diagnostic rules, prompts, datasets, software, and test results.
  • Physical OBD-II hardware: validate actual protocol behavior and data collection rather than relying exclusively on emulated interfaces.

Not all of these components are mandatory for the first prototype. The initial research should determine whether the additional complexity improves diagnostic quality, reproducibility, or maintainability.

8.5 A testable OBD-AI hypothesis

Hypothesis H1: A diagnostic system combining validated vehicle telemetry, explicit diagnostic rules, relevant service-manual retrieval, and evidence-linked AI recommendations will produce more useful and auditable diagnostic outcomes than an LLM-only baseline on a defined evaluation set.

To test H1:

  1. Construct a representative dataset of diagnostic cases.
  2. Establish expert-reviewed reference conclusions and acceptable alternative hypotheses.
  3. Compare rule-based, LLM-only, retrieval-augmented, and hybrid approaches.
  4. Measure diagnostic accuracy, unsupported-claim rate, evidence coverage, calibration, and time to a useful next test.
  5. Separate development cases from evaluation cases to reduce data leakage.
  6. Report failures, limitations, and cases requiring human judgment.

The hypothesis must remain provisional until measured results support or reject it.

9. Case Study B: Smart Inverter and Distributed Energy Resources

9.1 The initial problem

A smart inverter connects electrical power conversion with embedded control, sensing, communication, and potentially supervisory optimization or AI-assisted monitoring.

A superficial formulation might be:

Design an AI-enabled smart inverter using an ARM processor and FPGA.

This already commits to several technologies without establishing whether they are needed.

The hidden questions include:

  • What grid-support and power-quality functions are required?
  • Which electrical operating conditions must be handled?
  • What are the control-loop deadlines?
  • Which control functions require deterministic execution?
  • Can the selected processor meet the control budget?
  • Would FPGA logic improve the relevant timing or interface requirements?
  • How do switching behavior, sampling, delays, and sensor errors affect stability?
  • Which failures require protective action independent of supervisory AI?
  • How will the model be validated against the actual power stage?

For a safety- or grid-relevant controller, these questions must be resolved before claims about performance, protection, or compliance are made.

9.2 Hidden assumptions and research methods

Hidden assumption

Research question

Evidence or method

The controller is fast enough

Can the full sampling-to-actuation path meet the required timing budget?

Control-loop analysis, target measurements, timing instrumentation

Simulation predicts the physical system

Are component models, switching behavior, delays, and parasitics sufficiently representative?

Model calibration and comparison against hardware measurements

AI improves control

Does AI improve an explicitly defined objective without compromising stability or protection?

Comparative simulations, bounded experiments, independent safety mechanisms

FPGA is required

Does the selected processor fail a measurable requirement?

Baseline implementation and controlled partition exploration

Communication is reliable

What happens when messages are delayed, stale, lost, or corrupted?

Fault injection, interface tests, network simulations

A digital twin is trustworthy

Which measurements and uncertainty bounds establish agreement with the physical plant?

Calibration, residual analysis, model-validity monitoring

Passing a simulation proves compliance

Which standards, tests, and certification evidence apply to the product?

Requirements mapping, laboratory testing, compliance assessment

9.3 Proposed architecture

Electrical power stage

DC link · switching devices · filter · grid/load interface

Measurement and actuation

ADC · sensing · PWM · gate-drive interface · protection signals

Real-time controller

Processor and/or FPGA control functions

Supervisory layer

Monitoring · communication · diagnostics · optimization

Verification and operational evidence

Simulation · target timing · HIL · physical measurements · fault testing

The architecture deliberately separates fast control and protection responsibilities from supervisory analysis. The actual partition must follow the required control rates, safety analysis, hardware capabilities, and applicable grid requirements.

9.4 Why each tool is needed in the inverter project

  • MATLAB/Simulink: develop and analyze control algorithms, electrical models, operating scenarios, and disturbance responses.
  • SPICE: investigate selected circuit-level behavior where detailed electrical modeling is needed.
  • SystemC/TLM: evaluate processor/peripheral architecture, communication, and hardware/software partitioning at a suitable abstraction level.
  • Enterprise Architect and SysML: connect grid-service requirements, operating modes, physical subsystems, software functions, and verification evidence.
  • SystemVerilog or VHDL: implement and verify digital logic such as selected timing-sensitive control, capture, or interface functions.
  • Yosys and nextpnr, where supported: synthesize and implement designs for compatible FPGA devices.
  • Zephyr, FreeRTOS, or another appropriate RTOS: implement embedded tasks and peripheral services when the chosen controller and requirements support that approach.
  • Yocto Project: create a customized embedded Linux platform for supervisory functions where Linux services and maintainable image construction are justified.
  • QEMU or Renode: develop and test supported firmware components and modeled platform interactions before physical integration.
  • HIL and laboratory instrumentation: verify controller behavior against representative dynamics and measure physical timing and electrical performance.

The key research objective is not to use every tool. It is to determine the minimum combination that provides credible evidence for each critical claim.

9.5 A testable inverter hypothesis

Hypothesis H2: An explicitly partitioned architecture, with timing-critical functions allocated according to measured deadlines and supervisory functions separated from the fast control path, can meet the project's defined performance and verification requirements with lower integration risk than a partition chosen without workload analysis.

Test H2 by:

  1. Establishing the electrical, control, protection, and communication requirements.
  2. Building a baseline model and validating it against available reference measurements.
  3. Comparing processor-only and candidate accelerated architectures where applicable.
  4. Measuring the complete control path, not just individual functions.
  5. Testing disturbances, sensor faults, communication loss, and recovery scenarios.
  6. Verifying the controller using HIL and physical testing as appropriate.
  7. Documenting which claims remain unverified and what additional evidence is required.

Neither H1 nor H2 is presented as a demonstrated result. They are research hypotheses intended to guide experiments.

10. The Unified Workflow: From Research Question to Physical Prototype

A repeatable engineering process should connect research, architecture, implementation, and evidence.

01

Discover

Interview stakeholders, examine the operational environment, identify hidden questions, and establish the consequences of getting the problem wrong.

02

Specify

Define use cases, measurable requirements, acceptance criteria, failure conditions, and system boundaries.

03

Model

Create system structure, behavior, interfaces, constraints, and traceability in MBSE/UML/SysML as appropriate.

04

Explore

Use analytical calculations, algorithm models, SystemC/TLM, and virtual platforms where they can resolve architectural uncertainty.

05

Partition

Compare processor, RTOS, embedded Linux, FPGA, and dedicated-hardware options against common criteria.

06

Implement

Develop software, RTL, device drivers, interfaces, and reproducible builds under version control.

07

Verify

Run unit, integration, BDD, model-based, static-analysis, simulation, and fault-injection tests.

08

Validate

Compare model results with target hardware; use HIL, physical instrumentation, and representative workloads.

09

Decide

Review evidence, counterarguments, unresolved risks, lifecycle cost, and acceptance criteria before approving the design.

10

Maintain

Monitor operational behavior, preserve evidence, manage updates, and reopen assumptions when conditions change.

This workflow is iterative. If hardware measurements contradict the model, the team returns to the relevant assumptions, model parameters, architecture, or requirements. A discrepancy is useful evidence: it identifies a gap between the current understanding and the physical system.

10.1 What constitutes sufficient evidence?

The evidence required should be defined before testing, not after results are obtained.

Evidence level

Example

Appropriate conclusion

Conceptual

Architecture proposal and rationale

The design is plausible enough to investigate

Analytical

Timing budget, resource estimate, stability analysis

The proposal satisfies the modeled or calculated conditions

Simulated

Repeatable test cases with stated model assumptions

The model behaves as expected under the tested conditions

Emulated or virtualized

Firmware runs against a modeled processor and peripherals

The tested software/platform interactions work within the model's fidelity

Prototyped

Target processor or FPGA implementation

The prototype meets measured criteria under the tested conditions

System validated

Integrated system tested against representative scenarios

The specified system requirements are supported by the accumulated evidence

Production and compliance

Manufacturing tests, required assessments, operational evidence

Claims can be made within the actual scope of completed assessments

These levels are not a substitute for a project-specific verification plan. A safety-critical design may require formal methods, independent assessment, or prescribed compliance evidence much earlier in the lifecycle.

11. Measuring the Value of the Method

The methodology should itself be evaluated. Otherwise, “research-driven co-design” risks becoming another untested management claim.

11.1 Proposed metrics

Metric

What it measures

Requirements traceability

Proportion of applicable requirements linked to architecture and verification evidence

Assumption closure

Number and importance of high-risk assumptions resolved before design freeze

First-pass verification rate

Proportion of tests passing at the first designated verification stage

Defect discovery stage

When consequential defects are detected in the lifecycle

Prediction error

Difference between model predictions and corresponding physical measurements

Performance margin

Distance between measured or justified worst-case behavior and the requirement limit

Integration rework

Effort spent correcting architectural or interface problems

Reproducibility

Ability to reproduce a build, test, or reported result from controlled inputs

Lifecycle cost

Development, manufacturing, maintenance, licensing, and support costs

Operational effectiveness

Whether the deployed system achieves its intended real-world outcome

These metrics need explicit definitions, collection methods, and baselines. For example, a model's prediction error should specify the measured quantity, operating conditions, reference instrument, and acceptable tolerance.

11.2 Evaluating whether hidden-question analysis works

A suitable study would compare two groups of comparable projects or two carefully controlled development approaches:

  • Baseline approach: conventional requirements, architecture, implementation, and verification practices.
  • Research-driven approach: explicit hidden-question discovery, assumption registers, evidence-linked decisions, and predefined verification criteria.

The study should control, where possible, for project size, team experience, hardware complexity, and risk level.

Potential outcomes include earlier discovery of architectural defects, reduced rework, better traceability, improved prediction accuracy, and clearer release decisions. The results must be measured; the methodology should not be assumed to produce improvements merely because it appears systematic.

12. Strategic Roles of IAS-Research.com, KeenComputer.com, and KeenDirect.com

The methodology creates an opportunity to connect academic research with practical engineering and commercialization.

IAS-Research.com — Research, innovation, and systems architecture

IAS-Research can lead research-question formulation, requirements analysis, MBSE, architecture exploration, literature reviews, engineering models, experimental design, technical evaluation, and white papers.

Its central contribution is to help determine what should be investigated, which assumptions matter, and what evidence would justify a technical decision.

KeenComputer.com — Implementation, integration, and managed engineering

KeenComputer can translate the selected architecture into software, embedded Linux builds, automation, virtualized development environments, backend services, integration testing, deployment, and lifecycle support.

Its contribution is to turn a defensible design into a maintainable, reproducible implementation.

KeenDirect.com — Hardware sourcing and product enablement

KeenDirect is positioned as the planned hardware and computing-supply channel. It can help identify suitable development boards, processors, FPGA platforms, interfaces, storage, and supporting equipment.

Its contribution is to connect the validated engineering requirements with procurement, product availability, and practical implementation needs.

12.1 A joint research-to-market model

The three organizations can support a common lifecycle:

  1. Discover: identify the customer's operational problem and the unanswered engineering questions.
  2. Research: evaluate technical alternatives and formulate testable hypotheses.
  3. Architect: define requirements, interfaces, hardware/software allocation, and verification strategy.
  4. Prototype: develop the minimum system needed to test the most consequential assumptions.
  5. Validate: gather simulation, target-hardware, and system-level evidence.
  6. Commercialize: develop a costed implementation, deployment plan, and support model.
  7. Maintain: use operational evidence to improve reliability, update the system, and identify new research opportunities.

This arrangement can help small and medium-sized enterprises avoid investing prematurely in unnecessary hardware, software platforms, or AI capabilities. It can also provide a structured route for engineering research to progress toward prototypes, commercial products, and potential employment opportunities for STEM graduates.

Commercial success, however, requires customer validation, realistic costing, delivery capability, and evidence of value—not only a technically sound architecture.

13. Implementation Roadmap

The following is a proposed roadmap, not a report of work already completed.

Phase 1

Weeks 1–4: Research framing and requirements

  • Select one bounded OBD-AI or smart-inverter use case.
  • Identify stakeholders, operational scenarios, and hidden questions.
  • Create the assumption register and initial risk analysis.
  • Define acceptance criteria and the baseline architecture.
  • Establish requirement and decision identifiers in the engineering repository.

Deliverables: research brief, requirements baseline, assumption register, initial architecture.

Phase 2

Weeks 5–8: Models and architectural experiments

  • Build a behavioral or mathematical model.
  • Evaluate candidate processors, operating systems, and interfaces.
  • Introduce SystemC/TLM, QEMU, Renode, or FPGA tools only where justified.
  • Compare at least one credible baseline with the proposed alternative.
  • Define which model results need hardware validation.

Deliverables: model, experiment results, architecture trade-off report.

Phase 3

Weeks 9–12: Integrated prototype

  • Implement the selected hardware/software boundary.
  • Create reproducible builds and automated tests.
  • Verify critical interfaces and failure scenarios.
  • Measure the prototype under representative workloads.
  • Update the model and assumption register using observed discrepancies.

Deliverables: prototype, test suite, measurements, updated architecture.

Phase 4

Weeks 13–16: Validation and commercialization review

  • Compare measured results against predefined criteria.
  • Record limitations, unresolved assumptions, and required additional tests.
  • Estimate lifecycle cost, support burden, and supply-chain risks.
  • Prepare a technical decision report and next-stage business case.

Deliverables: validation report, evidence package, risk register, commercialization recommendation.

The schedule is indicative. FPGA board procurement, complex electrical simulation, physical inverter construction, automotive test access, and formal compliance activities may require substantially more time.

14. Limitations and Research Ethics

Several limitations must be recognized.

First, the methodology cannot eliminate uncertainty. It can expose uncertainty, prioritize it, and improve the evidence used in decisions. It cannot guarantee that all relevant questions have been discovered.

Second, models are selective representations. SystemC/TLM, QEMU, Renode, Simulink, and circuit simulators each represent different aspects of a system. Their validity depends on the model, configuration, assumptions, and intended use.

Third, tools do not replace expertise. An automated test, generated diagram, or AI-generated explanation may be incomplete or misleading. Important claims require independent checks appropriate to their consequences.

Fourth, safety and security require explicit treatment. An AI recommendation should not bypass required protective functions. Security-sensitive interfaces, software dependencies, update mechanisms, and data provenance should be considered from the beginning.

Fifth, research results must be reported honestly. Failed experiments, negative results, missing evidence, model limitations, and contradictory findings should be documented. Performance improvements should not be claimed without reproducible measurements and a suitable baseline.

Finally, the proposed OBD-AI and smart-inverter studies remain illustrative until experiments have been completed. This paper does not claim validated hardware, demonstrated performance gains, certification, or measured commercial outcomes.

15. Conclusion

Applying The Craft of Research to hardware–software co-design changes the central engineering question from “Which tool should we use?” to “What do we need to know before we can make a defensible design decision?”

That change has practical consequences.

  • Requirements become questions that can be investigated and criteria that can be verified.
  • Architectural preferences become hypotheses that can be compared with alternatives.
  • Tool choices become responses to defined evidence needs.
  • Simulations become bounded sources of evidence rather than substitutes for physical validation.
  • Architecture decisions become traceable arguments that can be reviewed, challenged, and revised.
  • Research becomes a disciplined route from uncertainty to a prototype and from a prototype to a commercially credible system.

The most important principle is that the value of a hardware–software co-design toolchain lies not in its size or sophistication, but in the quality of the engineering questions it helps answer and the reliability of the evidence it produces.

For IAS-Research.com, this provides a foundation for research and systems-architecture services. For KeenComputer.com, it provides a method for implementation, integration, and lifecycle engineering. For KeenDirect.com, it provides a requirements-driven route to appropriate hardware and computing products.

Together, the organizations can use a research-led engineering process to connect customer problems, STEM research, system architecture, implementation, verification, and commercialization.

References and Further Reading

The following sources provide the methodological and technical foundations for implementing the proposed framework. The references support the stated research method and tool capabilities; they do not establish that the illustrative hypotheses have already been proven.

A. Research methodology

1. Booth, W. C., Colomb, G. G., Williams, J. M., Bizup, J., and FitzGerald, W. T. The Craft of Research. 4th ed. University of Chicago Press, 2016. Chapters on developing research questions, identifying consequential problems, evaluating sources, constructing claims, presenting evidence, and examining warrants. Publisher information and contents.

bibliovault.org

+1

2. Booth, W. C., Colomb, G. G., Williams, J. M., Bizup, J., and FitzGerald, W. T. The Craft of Research. 5th ed. University of Chicago Press. Consult the publisher's current edition page for the updated treatment of research questions, evidence, warrants, and argument construction. Publisher page.

University of Chicago Press

B. System-level design and virtual platforms

3. Accellera Systems Initiative. SystemC and SystemC TLM. Overview of system-level modeling, architectural exploration, and transaction-level modeling. SystemC overview.

systemc.org

4. Accellera Systems Initiative. SystemC Transaction Level Modeling. Standardized interfaces and modeling styles for virtual prototyping and system architecture analysis. SystemC TLM.

systemc.org

5. QEMU Project. QEMU System Emulation Documentation. Machine emulation, device models, debugging, and system execution. Official documentation.

QEMU documentation

6. Antmicro and the Renode community. Renode Documentation. Virtual embedded platforms, supported peripherals, firmware execution, and automated testing. Official documentation.

documentation

C. Embedded software and FPGA implementation

7. Zephyr Project. Zephyr Documentation. Kernel services, scheduling, drivers, device-tree configuration, and testing facilities. Official documentation.

docs.zephyrproject.org

8. The Yocto Project. Technical Overview. Custom embedded Linux build systems, recipes, configuration, image generation, and related development infrastructure. Official overview.

The Yocto Project

9. YosysHQ. nextpnr Documentation and FAQ. FPGA implementation concepts, device-family support, and toolchain selection. Official project documentation.

GitHub

D. Modeling, requirements, and verification

10. Friedenthal, S., Moore, A., and Steiner, R. A Practical Guide to SysML: The Systems Modeling Language. 3rd ed. Morgan Kaufmann, 2014. A practical foundation for requirements, structural and behavioral modeling, parametric analysis, and systems engineering traceability.

11. ISO/IEC/IEEE 15288. Systems and Software Engineering—System Life Cycle Processes. Use the applicable edition when defining lifecycle processes and project tailoring.

12. ISO/IEC/IEEE 29148. Systems and Software Engineering—Life Cycle Processes—Requirements Engineering. Use the applicable edition to guide requirements definition and management.

13. IEEE 1012. Standard for System, Software, and Hardware Verification and Validation. Consult the applicable edition and project-specific requirements for verification and validation planning.

14. Accellera Systems Initiative. Universal Verification Methodology (UVM). A verification methodology relevant to suitable digital hardware verification projects. Accellera.

15. Cucumber. BDD Documentation. Specification by example and executable behavior specifications. Official documentation.

E. Further application-specific sources

16. MathWorks. MATLAB and Simulink Documentation. Modeling, simulation, control design, and relevant embedded implementation workflows. Official documentation.

17. ISO 26262. Road Vehicles—Functional Safety. Relevant to automotive electrical/electronic systems when the project falls within its scope.

18. IEC 61508. Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems. Relevant to the assessment and development of applicable safety-related systems.

19. IEC 61800-5-2 and IEC 62443 series. Consult the applicable standards for functional safety of relevant drive systems and industrial automation/control-system cybersecurity, respectively.

20. Relevant local grid codes, inverter product standards, and applicable UL, CSA, or other conformity requirements must be identified for the actual smart-inverter product and intended market. A generic architecture or simulation result is not evidence of compliance.

Proposed next research deliverable

The next step is to turn this methodology into a practical MBSE and hardware–software co-design workbook containing:

  • A hidden-question and assumption register.
  • An Enterprise Architect requirements and traceability model.
  • SysML and UML modeling templates.
  • A hardware/software allocation matrix.
  • A tool-selection decision matrix.
  • BDD/Gherkin acceptance scenarios.
  • SystemC/TLM and virtual-platform experiment templates.
  • An OBD-AI or smart-inverter verification matrix.
  • A results and evidence report template.

This would make the paper directly usable as a working method for an engineering team rather than only as a conceptual research document.