Hardware–Software Co-Design with OVP and SystemC/TLM

From Virtual Platforms to Intelligent Embedded Systems

A Research and Engineering Framework for OBD-AI, Smart Inverters, Edge AI, RAG-LLM, ARM/RISC-V and Digital Twins

IAS-Research.com | KeenComputer.com | KeenDirect.com

Executive Summary

The increasing complexity of embedded and cyber-physical systems has fundamentally changed how hardware and software must be engineered.

Modern products such as automotive electronic control units, EV systems, smart inverters, distributed-energy-resource controllers, industrial IoT devices, robotics platforms and edge-AI systems are no longer purely hardware products with software added afterward. They are integrated hardware–software systems in which processor architecture, memory, communication, firmware, operating systems, AI algorithms, sensors, power electronics and cloud services interact continuously.

This creates a fundamental engineering challenge:

How can the architecture of a complex embedded system be validated before expensive hardware is built?

Open Virtual Platforms (OVP), SystemC and Transaction-Level Modeling (TLM) provide important building blocks for answering this question.

SystemC provides a C++-based system-level modeling environment that supports architectural exploration and hardware/software co-design. SystemC TLM provides standardized transaction-level interfaces for modeling communication and memory-mapped systems. The current SystemC standard is IEEE 1666-2023.

OVP provides virtual processor and platform modeling capabilities that allow software to execute against a virtual representation of an embedded system before the physical target is available. The OVP ecosystem has supported processor models, virtual platforms and software development environments.

This paper proposes an integrated methodology:

Requirements → MBSE → System Architecture → SystemC/TLM → OVP → Embedded Software → AI/ML → RAG-LLM → Co-Simulation → Hardware/Software Partitioning → FPGA/HIL → Physical Prototype → Product

Two flagship use cases demonstrate the approach:

  1. OBD-AI — an intelligent automotive diagnostic platform combining OBD-II/CAN, embedded computing, AI, RAG-LLM and knowledge graphs.
  2. Smart Inverter — an intelligent grid-edge platform combining power electronics, embedded control, FPGA/DSP, AI, RAG-LLM and digital-twin technologies.

The paper also defines complementary strategic roles:

  • IAS-Research.com — research, architecture, modeling and advanced R&D.
  • KeenComputer.com — software engineering, embedded systems, AI, integration and deployment.
  • KeenDirect.com — hardware, components, development platforms and physical prototyping.

The resulting ecosystem provides a path from research to architecture to engineering to hardware to commercial product.

1. Introduction

Embedded systems are becoming increasingly software-defined.

An automotive ECU, smart inverter, EV charger or industrial controller may contain:

  • ARM or RISC-V processors
  • microcontrollers
  • FPGA or DSP acceleration
  • memory subsystems
  • communication buses
  • sensors
  • actuators
  • real-time firmware
  • RTOS
  • Embedded Linux
  • AI/ML
  • cybersecurity
  • cloud connectivity
  • digital twins
  • domain-specific knowledge systems.

The traditional sequential model:

Hardware ↓ Prototype ↓ Firmware ↓ Software ↓ Integration

is increasingly inadequate.

A more appropriate approach is:

SYSTEM | +-------+-------+ | | Hardware Software | | +-------+-------+ | v Co-Design

The objective is to discover architectural problems early, when they are less expensive to correct.

2. The Hardware–Software Co-Design Challenge

Consider a new embedded product.

The engineering team must answer questions such as:

  • Which processor should be used?
  • ARM or RISC-V?
  • How much memory is required?
  • Which functions should execute in software?
  • Which functions require hardware acceleration?
  • Is an FPGA required?
  • Is an NPU required?
  • What communication architecture is required?
  • What is the expected latency?
  • How much CPU utilization will occur?
  • Can the RTOS meet deadlines?
  • Will Linux provide adequate performance?
  • How should AI inference be partitioned?
  • Where should data be processed?
  • What functions should run at the edge?
  • What functions should run in the cloud?

These questions are architectural questions.

They should ideally be answered before committing to production hardware.

3. Virtual Engineering

Virtual engineering changes the development sequence.

Instead of immediately building hardware:

Specification ↓ PCB ↓ Prototype ↓ Firmware ↓ Debug

the process becomes:

Specification ↓ Architecture ↓ Virtual Model ↓ Virtual Platform ↓ Software ↓ Performance Analysis ↓ Hardware Prototype

The physical prototype remains essential.

The difference is that more architectural uncertainty is removed before the prototype is manufactured.

4. SystemC

SystemC is a system-level modeling language and methodology implemented in C++.

It supports modeling of:

  • processors
  • memories
  • buses
  • peripherals
  • communication systems
  • hardware accelerators
  • embedded software interactions
  • complete system architectures.

SystemC is particularly valuable because it allows engineers to work at abstraction levels above RTL.

A conceptual refinement process is:

Requirements ↓ Functional Architecture ↓ SystemC Model ↓ TLM Model ↓ Timed Model ↓ RTL ↓ FPGA / ASIC

This enables architecture to be explored before detailed implementation.

5. Transaction-Level Modeling

Transaction-Level Modeling abstracts communication into transactions rather than requiring every signal transition to be modeled.

Examples include:

READ WRITE DMA_TRANSFER PACKET_SEND PACKET_RECEIVE INTERRUPT

A simplified model is:

+--------+ | CPU | +---+----+ | | Transaction v +-----------+ | TLM Bus | +-----+-----+ | v +-----------+ | Peripheral| +-----------+

TLM therefore allows system architects to model communication and architectural behavior without immediately incurring the computational cost of detailed RTL simulation.

SystemC TLM provides standardized transaction-level interfaces and modeling styles for system-level communication.

6. Open Virtual Platforms

An Open Virtual Platform provides a software representation of a target embedded system.

A typical virtual platform may contain:

+------------------------------------+ | Virtual Platform | | | | CPU | | Memory | | Interrupt Controller | | Timer | | UART | | SPI | | I2C | | CAN | | GPIO | | Custom Peripherals | +------------------------------------+

Software can execute on the virtual processor.

This provides an environment for:

  • firmware development
  • driver development
  • operating-system bring-up
  • application development
  • automated testing
  • debugging
  • architectural experimentation.

7. OVP + SystemC/TLM Integration

The two technologies address complementary requirements.

Technology

Role

SystemC

System-level architecture

TLM

Transaction-level communication

OVP

Virtual processor/platform execution

QEMU

System/software virtualization

RTL

Detailed hardware modeling

FPGA

Physical hardware prototyping

RTOS

Deterministic embedded software

Linux

General-purpose embedded software

A combined environment can be represented as:

SYSTEM ARCHITECTURE | v SystemC / TLM | +-----------+-----------+ | | v v Virtual Hardware OVP | CPU Model | v Embedded Software | +----------+----------+ | | RTOS Linux

This creates a virtual laboratory for hardware/software co-design.

8. MBSE and System Architecture

Model-Based Systems Engineering can provide the architectural layer above SystemC/TLM.

A possible flow is:

Stakeholder Requirements ↓ Use Cases ↓ SysML ↓ System Architecture ↓ Hardware Architecture ↓ Software Architecture ↓ SystemC/TLM ↓ OVP Virtual Platform

A tool such as Sparx Enterprise Architect can be used to maintain:

  • requirements
  • use cases
  • system blocks
  • interfaces
  • hardware/software allocation
  • traceability
  • architecture documentation.

This creates a bridge between business requirements and executable technical models.

9. Hardware–Software Partitioning

One of the most important uses of virtual prototyping is determining which functions belong in hardware and which belong in software.

For example:

FUNCTION | +----------+----------+ | | v v SOFTWARE HARDWARE | | CPU FPGA / ASIC / DSP | | +----------+----------+ | v Interface

Candidate hardware functions may include:

  • signal processing
  • cryptography
  • FFT
  • filtering
  • PWM
  • AI acceleration
  • packet processing.

Candidate software functions may include:

  • configuration
  • diagnostics
  • networking
  • user interfaces
  • supervisory control
  • high-level decision logic.

SystemC/TLM allows alternatives to be evaluated before detailed RTL implementation.

10. Performance Modeling

Architectural exploration should consider:

  • latency
  • throughput
  • bandwidth
  • CPU utilization
  • memory traffic
  • communication overhead
  • interrupt rate
  • accelerator utilization.

A simplified system model can be expressed as:

Tsystem=Tcompute+Tmemory+Tcommunication+TsynchronizationT_{system} = T_{compute} + T_{memory} + T_{communication} + T_{synchronization}

For hardware acceleration:

Speedup=TsoftwareThardware+softwareSpeedup = \frac{T_{software}} {T_{hardware+software}}

These are architectural metrics rather than substitutes for final physical timing analysis.

11. The Intelligent Embedded-System Architecture

The next generation of embedded systems can be viewed as five interacting layers:

+---------------------------------------+ | Human / Engineering Interface | +---------------------------------------+ | AI / RAG / Knowledge Layer | +---------------------------------------+ | Embedded Software / RTOS / Linux | +---------------------------------------+ | Processor / FPGA / Hardware | +---------------------------------------+ | Physical System | +---------------------------------------+

The key innovation is connecting the physical system with engineering knowledge.

That is where OBD-AI and smart-inverter systems become particularly important.

12. Use Case I — OBD-AI

12.1 Overview

OBD-AI is a proposed intelligent automotive diagnostic platform combining:

  • OBD-II
  • CAN
  • embedded systems
  • ARM/RISC-V
  • RTOS/Linux
  • edge AI
  • RAG
  • LLM
  • vector databases
  • knowledge graphs
  • diagnostic agents.

The system can transform vehicle telemetry into evidence-grounded diagnostic assistance.

13. OBD-AI Architecture

VEHICLE | v OBD-II / CAN | v CAN / OBD Interface | v ARM / RISC-V ECU | +--------------+--------------+ | | v v Embedded SW Edge AI | | +--------------+--------------+ | v Diagnostic Gateway | +-------+-------+ | | v v Mobile/Web RAG Platform | +----------+----------+ | | v v Vector DB Graph DB | | +----------+----------+ | v LLM | v Diagnostic Assistant

14. OBD-AI Virtual ECU

The OBD-AI project can use an OVP virtual ECU.

+-----------------------------------------+ | OVP Virtual ECU | | | | ARM / RISC-V | | RAM | | Timer | | Interrupt Controller | | UART | | SPI | | I2C | | CAN | +-------------------+---------------------+ | v SystemC/TLM

The diagnostic firmware can execute against this virtual platform.

15. Virtual CAN and OBD Testing

A virtual vehicle environment can generate:

  • CAN frames
  • OBD requests
  • diagnostic responses
  • DTC events
  • sensor values
  • abnormal conditions.

For example:

Vehicle Model ↓ CAN Generator ↓ Virtual CAN Controller ↓ SystemC/TLM ↓ OVP CPU ↓ Diagnostic Firmware

This allows repeatable testing without requiring a physical vehicle for every software iteration.

16. OBD-AI Hardware–Software Partition

Potential edge functions:

  • CAN acquisition
  • OBD protocol
  • filtering
  • signal processing
  • local anomaly detection
  • data buffering
  • cybersecurity.

Potential server functions:

  • document retrieval
  • vector search
  • graph reasoning
  • LLM inference
  • historical analysis.

Thus:

Vehicle ↓ Edge Device ↓ Gateway ↓ RAG ↓ Knowledge Graph + Vector DB ↓ LLM ↓ Diagnostic Explanation

17. OBD-AI RAG Architecture

The RAG layer can combine:

Vector Search

For semantic retrieval from:

  • service manuals
  • technical documentation
  • troubleshooting procedures
  • component descriptions.

Knowledge Graph

For explicit relationships:

DTC | +-- caused_by --> Component | +-- measured_by --> Sensor | +-- related_to --> System | +-- tested_by --> Procedure

LLM

The LLM can generate explanations from retrieved evidence.

The resulting architecture is:

Vehicle Data | v Diagnostic Context | v Retriever | +---+---+ | | v v Vector Graph DB DB | | +---+---+ | v LLM | v Diagnostic Response

18. OBD-AI Agent Architecture

The RAG system can eventually become an agentic diagnostic system.

Diagnostic Agent | +----------------+----------------+ | | | v v v CAN Agent DTC Agent Manual Agent | | | +----------------+----------------+ | v Evidence Agent | v Diagnostic Report

Potential agents include:

  • CAN Agent
  • DTC Agent
  • Service Manual Agent
  • Component Agent
  • History Agent
  • Evidence Agent.

19. OBD-AI Digital Twin

A future OBD-AI architecture can maintain a vehicle digital twin.

Physical Vehicle | v Telemetry | v Vehicle Digital Twin | +-----+-----+ | | | State History Simulation | | | +-----+-----+ | v AI | v RAG-LLM | v Diagnostic Intelligence

This creates a research platform for predictive maintenance and intelligent diagnostics.

20. Use Case II — Smart Inverter

20.1 Overview

The smart inverter extends the same methodology into:

  • renewable energy
  • photovoltaic systems
  • battery energy storage
  • EV charging
  • distributed energy resources
  • grid-edge computing
  • power-quality control
  • AI-based diagnostics.

The smart inverter is therefore a cyber-physical system in which high-speed electrical behavior interacts with digital computation.

21. Smart-Inverter Architecture

PV / BATTERY / EV | v DC Power Stage | v Inverter Bridge | v AC Filter | v GRID ^ | +----------+----------+ | Digital Controller | +----------+----------+ | +-----------+-----------+ | | v v CPU/SoC FPGA/DSP | | +-----------+-----------+ | SystemC/TLM | v OVP | v RTOS/Linux | +-----------+-----------+ | | AI Communications

22. Smart-Inverter Control Functions

A modern digital controller may contain:

  • PWM generation
  • ADC acquisition
  • current control
  • voltage control
  • PLL
  • DC-link control
  • active-power control
  • reactive-power control
  • power-factor control
  • fault detection
  • protection
  • communication
  • diagnostics.

These functions have different timing requirements.

23. Smart-Inverter Hardware–Software Partition

A possible allocation is:

Function

Candidate implementation

PWM

FPGA/hardware

ADC interface

FPGA/peripheral

Fast current loop

DSP/FPGA

PLL

DSP/FPGA

Protection

Hardware + firmware

Supervisory control

ARM/RISC-V

Communications

CPU

Diagnostics

CPU

AI inference

CPU/NPU/FPGA

RAG

Edge/cloud

Configuration

RTOS/Linux

The actual allocation should be established through system requirements and architectural analysis rather than assumed in advance.

24. SystemC/TLM Smart-Inverter Model

A virtual controller can contain:

+-------------------------------------+ | SystemC/TLM Inverter Model | | | | CPU | | Memory | | ADC | | PWM | | Timer | | Interrupt Controller | | Communication | | Control Algorithm | | AI Accelerator | +-------------------------------------+

This model can be connected to an electrical-system simulation.

25. Electrical and Digital Co-Simulation

The architecture becomes:

Electrical Model | V/I Measurements | v SystemC/TLM Controller | Control Commands | v Electrical Model

The closed loop is:

Electrical State→Measurement→Controller→Control→Electrical StateElectrical\ State \rightarrow Measurement \rightarrow Controller \rightarrow Control \rightarrow Electrical\ State

This allows control architecture to be evaluated together with the electrical system.

26. Smart-Inverter AI

AI can support:

  • anomaly detection
  • fault classification
  • predictive maintenance
  • power-quality classification
  • thermal prediction
  • component degradation detection
  • efficiency optimization.

A possible architecture is:

Voltage Current Temperature DC-Link Frequency | v Feature Extraction | v AI / ML | +--> Normal +--> Anomaly +--> Fault +--> Degradation

27. Smart-Inverter RAG

The RAG system can use:

  • inverter manuals
  • component specifications
  • grid documentation
  • commissioning procedures
  • maintenance procedures
  • test reports
  • engineering knowledge
  • historical fault records.

The architecture is:

Inverter Telemetry | v Diagnostic Context | v RAG Retriever | +-----+-----+ | | Vector Graph Database Database | | +-----+-----+ | v LLM | v Engineering Assistant

28. Smart-Inverter Knowledge Graph

Example relationships:

Fault | +-- affects --> Component | +-- detected_by --> Sensor | +-- occurs_under --> Operating Condition | +-- documented_in --> Manual | +-- tested_by --> Procedure | +-- may_require --> Maintenance

This allows the knowledge system to represent engineering relationships explicitly.

29. Smart-Inverter Digital Twin

The long-term architecture is:

Physical Inverter | Telemetry | v Digital Twin | +-----+-----+ | | | State History Simulation | | | +-----+-----+ | v AI | v RAG-LLM | v Engineering Intelligence

Potential applications include:

  • commissioning
  • monitoring
  • diagnostics
  • predictive maintenance
  • controller optimization
  • power-quality analysis.

30. Grid-Edge Architecture

The smart inverter can be expanded into a distributed grid-edge system.

ELECTRIC GRID | +-------------+-------------+ | | | PV Battery EV | | | +-------------+-------------+ | Smart Inverter | Edge Controller | +------+------+ | | AI Grid Communications | | +------+------+ | Cloud/RAG

This architecture can support intelligent distributed energy resources.

31. EV Charging Extension

The same co-design architecture applies to EV charging.

EV Battery | Power Converter | Digital Controller | +---+---+ | | CPU FPGA/DSP | | +---+---+ | AI / Optimization | Grid

Potential intelligent functions include:

  • charging optimization
  • anomaly detection
  • thermal management
  • battery diagnostics
  • grid-response functions.

32. Power-Quality Analysis

The platform can also analyze:

  • harmonics
  • voltage sag
  • voltage swell
  • transients
  • frequency disturbances
  • unbalance.

A possible architecture is:

Voltage / Current | v High-Speed Acquisition | v DSP / FPGA | v Feature Extraction | v AI Classifier | v Power-Quality Event | v RAG-LLM Assistant

33. Hardware-in-the-Loop

Virtual prototyping can evolve toward Hardware-in-the-Loop testing.

Real Controller | v HIL Interface | v Real-Time Plant Model | v Simulated Grid

A complete validation progression becomes:

SystemC/TLM ↓ OVP ↓ Co-Simulation ↓ HIL ↓ FPGA ↓ Physical Prototype ↓ Production

34. Common Architecture of OBD-AI and Smart Inverters

Although the two applications operate in different industries, they share the same fundamental architecture.

Layer

OBD-AI

Smart Inverter

Physical system

Vehicle

Electrical grid

Sensors

Vehicle sensors

Voltage/current/temp

Interface

CAN/OBD-II

ADC/grid interface

Processor

ARM/RISC-V

ARM/RISC-V/DSP

Fast processing

CAN/edge AI

FPGA/DSP

Virtual platform

OVP

OVP

System model

SystemC/TLM

SystemC/TLM

AI

Diagnostics

Anomaly/predictive

Knowledge

Service manuals

Engineering documents

RAG

Diagnostic assistant

Engineering assistant

Graph

Vehicle components

Power components

Digital twin

Vehicle

Inverter

Prototype

ECU/device

Controller/inverter

This suggests a reusable engineering methodology rather than two isolated projects.

35. The IAS-Research Virtual Co-Design Framework

The two use cases support development of a common platform:

+--------------------------------------------------+ | IAS-Research Virtual Co-Design Lab | +--------------------------------------------------+ | MBSE / SysML | | System Architecture | | SystemC / TLM | | OVP / Virtual Platforms | | ARM / RISC-V | | RTOS / Embedded Linux | | FPGA / DSP | | AI / ML | | Vector Database | | Knowledge Graph | | RAG / LLM | | Digital Twin | | HIL | +--------------------------------------------------+ | | v v OBD-AI Smart Inverter

The same infrastructure can subsequently be reused for other intelligent embedded systems.

36. Additional Application Domains

The framework can extend to:

Industrial IoT

Machine → Edge Controller → AI → RAG → Engineer

Robotics

Sensors → Robot Controller → AI → Knowledge → Operator

Telecommunications

Telemetry → Edge Processing → AI → RAG → Network Engineer

Energy Storage

Battery → BMS → AI → Digital Twin → RAG

Aerospace and Defense Research

Sensors → Embedded Controller → Virtual Platform → AI

The exact safety, regulatory and validation requirements will differ by domain.

37. Verification Pyramid

A mature engineering methodology should verify the system progressively.

Production System ^ | Physical Test ^ | HIL/FPGA ^ | RTL Model ^ | SystemC/TLM Model ^ | OVP Virtual Platform ^ | Architecture ^ | Requirements

Each layer addresses different questions.

38. Automated Regression

Virtual platforms can become part of CI/CD.

Git Commit ↓ Build ↓ Start Virtual Platform ↓ Execute Firmware ↓ Generate CAN / Sensor Tests ↓ Collect Results ↓ Performance Analysis ↓ Regression Report

This makes virtual hardware part of the software-development lifecycle.

KeenComputer can implement the automation infrastructure while IAS-Research develops the architecture and test methodology.

39. Development Toolchain

A reference laboratory can combine:

Architecture

  • Sparx Enterprise Architect
  • UML
  • SysML
  • MBSE.

System Modeling

  • SystemC
  • TLM
  • C++
  • SystemC CCI.

Virtual Platforms

  • OVP
  • processor models
  • virtual peripherals.

Embedded Software

  • C/C++
  • ARM toolchains
  • RISC-V toolchains
  • FreeRTOS
  • Embedded Linux
  • Yocto.

Simulation

  • QEMU
  • Verilator
  • SystemC
  • MATLAB/Simulink
  • PSCAD
  • ngspice.

Hardware

  • STM32
  • ARM development platforms
  • RISC-V
  • FPGA
  • SoC FPGA.

AI

  • Python
  • ML frameworks
  • vector databases
  • knowledge graphs
  • RAG
  • LLMs.

Infrastructure

  • Git
  • Docker
  • CI/CD
  • Linux.

40. Research Opportunities

The combined methodology creates several research opportunities.

40.1 AI-Assisted Architecture Exploration

AI can potentially evaluate alternative:

  • processors
  • buses
  • memory systems
  • accelerators
  • hardware/software partitions.

40.2 Automated Model Generation

A future workflow could move toward:

Requirements ↓ Architecture ↓ SystemC/TLM ↓ Virtual Platform

40.3 AI Accelerator Co-Design

SystemC/TLM models can investigate:

  • CPU-only implementation
  • FPGA acceleration
  • DSP acceleration
  • NPU acceleration.

40.4 Digital Twins

Virtual platforms can evolve from development tools into lifecycle engineering models.

40.5 RAG-Based Engineering Assistants

Domain knowledge can be connected directly to telemetry and simulation results.

41. IAS-Research.com Strategic Role

IAS-Research should occupy the research and architecture layer.

Its potential responsibilities include:

Research

  • SystemC/TLM
  • OVP
  • ARM/RISC-V
  • embedded architecture
  • AI hardware
  • digital twins
  • MBSE
  • edge AI.

Architecture

  • system requirements
  • reference architectures
  • hardware/software partitioning
  • virtual platforms
  • co-simulation.

Advanced R&D

  • OBD-AI
  • smart inverters
  • AI accelerators
  • grid-edge systems
  • intelligent embedded systems.

Knowledge

IAS-Research can publish:

  • research papers
  • white papers
  • reference architectures
  • technical tutorials
  • engineering methodologies.

42. KeenComputer.com Strategic Role

KeenComputer should serve as the engineering and implementation layer.

Its capabilities can include:

  • embedded software
  • Linux
  • RTOS
  • device drivers
  • middleware
  • CAN
  • Ethernet
  • MQTT
  • APIs
  • cloud/edge systems
  • AI integration
  • RAG implementation
  • cybersecurity
  • CI/CD
  • system integration.

The relationship can be summarized as:

IAS-Research designs the architecture; KeenComputer engineers and integrates the solution.

43. KeenDirect.com Strategic Role

KeenDirect provides the physical engineering bridge.

Potential product categories include:

  • ARM development boards
  • RISC-V boards
  • STM32 platforms
  • FPGA boards
  • CAN interfaces
  • sensors
  • embedded computers
  • networking hardware
  • power-electronics development equipment
  • development accessories
  • electronic components.

The role is:

Connect virtual engineering with physical prototyping.

44. Research-to-Product Ecosystem

The three organizations can therefore operate as a coordinated pipeline:

CUSTOMER | v IAS-RESEARCH.COM Research / Architecture | v SystemC / TLM | v OVP | v Virtual Prototype | v KEENCOMPUTER.COM Software / Engineering | v FPGA / HIL / Prototype | v KEENDIRECT.COM Hardware / Components | v PRODUCT

45. Commercial Service Model

This architecture can support several service offerings.

Virtual Prototype Feasibility Study

Evaluate an embedded-system concept before hardware development.

Hardware/Software Partitioning Study

Determine candidate allocation of functions.

SystemC/TLM Modeling

Develop system-level and transaction-level models.

OVP Virtual Platform

Create a software-executable virtual target.

Embedded Software Development

Develop:

  • BSP
  • firmware
  • drivers
  • RTOS
  • Linux.

AI/RAG Engineering

Build domain-specific AI systems.

FPGA Prototyping

Transition selected functions into hardware.

Digital Twin Development

Connect virtual and physical systems.

46. Proposed Research Lab

IAS-Research and KeenComputer can establish a:

Virtual Hardware–Software Co-Design Lab

The laboratory can focus on:

MBSE | v Architecture | +------+------+ | | v v SystemC/TLM OVP | | +------+------+ | v Virtual Platform | +--------+--------+ | | v v OBD-AI Smart Inverter | | v v AI AI | | RAG RAG | | +--------+--------+ | v FPGA / HIL | v Hardware

This can become a reusable research and demonstration environment.

47. Proposed OBD-AI Development Roadmap

Phase 1 — Virtual CAN

Develop:

  • CAN transaction generator
  • ECU model
  • OBD scenarios.

Phase 2 — Virtual ECU

Integrate:

  • ARM/RISC-V
  • memory
  • CAN
  • interrupts
  • UART.

Phase 3 — Firmware

Develop:

  • CAN driver
  • OBD protocol
  • diagnostics.

Phase 4 — AI

Implement:

  • anomaly detection
  • DTC analysis
  • feature extraction.

Phase 5 — RAG

Implement:

  • document ingestion
  • vector database
  • knowledge graph
  • retrieval
  • LLM.

Phase 6 — Agentic System

Implement specialized diagnostic agents.

Phase 7 — Hardware

Transition to:

  • STM32
  • ARM
  • RISC-V
  • FPGA.

Phase 8 — Vehicle Validation

Move from virtual scenarios to controlled physical CAN/OBD testing.

48. Proposed Smart-Inverter Development Roadmap

Phase 1 — Electrical Model

Develop:

  • inverter
  • grid
  • PV
  • battery
  • load models.

Phase 2 — Digital Controller

Develop:

  • ADC
  • PWM
  • CPU
  • DSP/FPGA models.

Phase 3 — SystemC/TLM

Develop the virtual controller architecture.

Phase 4 — OVP

Execute controller firmware on the virtual processor.

Phase 5 — Co-Simulation

Connect electrical and digital models.

Phase 6 — AI

Implement:

  • anomaly detection
  • predictive maintenance
  • power-quality classification.

Phase 7 — RAG

Connect engineering documentation and knowledge graphs.

Phase 8 — HIL

Connect the controller to a real-time plant model.

Phase 9 — FPGA/Physical Prototype

Move toward real controller hardware.

49. The Unified Engineering Lifecycle

The two projects demonstrate the same lifecycle:

REQUIREMENTS | v MBSE | v ARCHITECTURE | v SYSTEMC / TLM | v OVP | v VIRTUAL PLATFORM | +----------+----------+ | | v v SOFTWARE HARDWARE | | v v AI FPGA/RTL | | +----------+----------+ | v RAG/LLM | v DIGITAL TWIN | v HIL | v PROTOTYPE | v PRODUCT

50. Strategic Differentiation

The value of this approach is not any individual tool.

The strategic value comes from integrating the tools into a coherent engineering methodology.

The proposition is:

Do not start with the PCB. Start with the architecture.

Then:

Do not wait for hardware to start software. Start with the virtual platform.

Then:

Do not treat AI as an isolated application. Integrate AI into the system architecture.

Finally:

Do not treat engineering knowledge as static documentation. Connect it to the digital system through RAG and knowledge graphs.

51. From Simulation to Intelligent Engineering

The traditional simulation workflow is:

Model ↓ Simulate ↓ Measure

The proposed intelligent workflow is:

Model ↓ Simulate ↓ Measure ↓ Store Knowledge ↓ Retrieve Evidence ↓ AI Reasoning ↓ Engineering Decision

This is an important evolution.

The virtual platform becomes not merely a simulation environment but an engineering knowledge-generation environment.

52. Long-Term Vision

The long-term vision is an intelligent virtual engineering environment in which:

  1. requirements are represented through MBSE;
  2. architecture is represented through SystemC/TLM;
  3. processors and platforms execute through OVP;
  4. firmware and operating systems execute virtually;
  5. AI workloads are evaluated;
  6. engineering knowledge is indexed;
  7. RAG retrieves relevant evidence;
  8. knowledge graphs represent relationships;
  9. digital twins connect virtual and physical systems;
  10. FPGA and HIL provide progressively more realistic validation.

The result is:

Requirements ↓ Model ↓ Execute ↓ Measure ↓ Analyze ↓ Learn ↓ Reason ↓ Prototype ↓ Deploy

53. Final Conclusions

OVP and SystemC/TLM provide complementary foundations for hardware–software co-design.

SystemC/TLM enables system-level architecture, transaction-level communication modeling and architectural exploration.

OVP provides a virtual execution environment in which embedded software can interact with modeled processor and platform components.

Together, they can shift important engineering activities from the physical prototype into a virtual environment.

The OBD-AI project demonstrates this methodology in automotive diagnostics:

Vehicle → CAN/OBD → Embedded Processor → AI → RAG → Knowledge Graph → LLM → Diagnostic Intelligence

The smart-inverter project demonstrates it in energy systems:

PV/Battery/EV → Power Electronics → Digital Controller → SystemC/TLM → OVP → AI → RAG → Digital Twin → Grid Intelligence

These use cases demonstrate that the methodology is not limited to a single industry.

The same architecture can support:

  • automotive
  • EV
  • renewable energy
  • smart grid
  • industrial IoT
  • robotics
  • edge AI
  • energy storage
  • intelligent controllers.

The strategic roles of the three organizations are complementary:

IAS-Research.com

Research + Architecture + Innovation

KeenComputer.com

Engineering + Software + Integration + Deployment

KeenDirect.com

Hardware + Components + Prototyping

Together:

IAS-RESEARCH | RESEARCH / ARCHITECTURE | v SYSTEMC / TLM / OVP | v VIRTUAL PROTOTYPE | +----------+----------+ | | v v OBD-AI SMART INVERTER | | v v AI AI | | RAG RAG | | +----------+----------+ | v KEENCOMPUTER | ENGINEERING / INTEGRATION | v FPGA / HIL | v KEENDIRECT | HARDWARE / COMPONENTS | v PRODUCT

The resulting proposition is a complete research-to-product hardware–software co-design ecosystem.

Its fundamental engineering philosophy is:

Research the architecture. Model the system. Execute the software virtually. Explore the hardware/software boundary. Integrate AI and engineering knowledge. Validate progressively. Build the physical prototype only after the architecture has been sufficiently explored.

This provides IAS-Research, KeenComputer and KeenDirect with a common technological foundation for developing the next generation of intelligent embedded and cyber-physical systems.

References and Further Reading

  1. Accellera Systems Initiative — SystemC. SystemC standards, language resources and reference implementations.
  2. IEEE 1666-2023 — IEEE Standard for Standard SystemC Language Reference Manual. The IEEE standard governing the SystemC language.
  3. SystemC Transaction-Level Modeling. Accellera/SystemC resources describing TLM concepts and interfaces.
  4. Open Virtual Platforms. OVP processor modeling, virtual-platform and software-development resources.
  5. IAS-Research — Open Virtual Platforms and ESL Design and Development. IAS-Research material concerning OVP and electronic-system-level design.
  6. IAS-Research — Virtual Platforms in Embedded Systems Research and Development. Virtual-platform methodologies for embedded-system development.

Appendix A — Reference Architecture

CUSTOMER | v REQUIREMENTS | v MBSE | v SYSTEM ARCHITECTURE | +--------------+--------------+ | | v v SOFTWARE HARDWARE | | v v OVP SystemC/TLM | | +--------------+--------------+ | v VIRTUAL PLATFORM | +----------+----------+ | | v v OBD-AI SMART INVERTER | | v v CAN ADC/PWM | | v v ARM/RISC-V ARM/RISC-V | | +----------+----------+ | v AI | v RAG / LLM | v KNOWLEDGE GRAPH | v DIGITAL TWIN | v HIL | v FPGA | v PHYSICAL HARDWARE | v PRODUCT

Appendix B — IAS-Research / KeenComputer / KeenDirect Value Chain

IAS-RESEARCH | +-- Research +-- MBSE +-- System Architecture +-- SystemC/TLM +-- OVP +-- AI Architecture +-- Digital Twins | v KEENCOMPUTER | +-- Embedded Software +-- RTOS +-- Linux +-- Drivers +-- AI/RAG +-- Cloud/Edge +-- Integration +-- Cybersecurity | v KEENDIRECT | +-- ARM +-- RISC-V +-- STM32 +-- FPGA +-- CAN +-- Sensors +-- Embedded Computers +-- Components | v PHYSICAL PRODUCT

Core proposition:

IAS-Research thinks and models. KeenComputer engineers and integrates. KeenDirect supplies and enables the physical platform.