LLM4HW
Lokale LLM’s met hardware-in-the-loop voor PCB-verificatie, board bring-up en firmwareontwikkeling
Hoe kunnen lokale large language models (LLM’s) ingenieurs helpen om een echte PCB te begrijpen, werkend te krijgen en grondig te testen? Met LLM4HW willen we deze taalmodellen via agents toegang geven tot schema’s, broncode, meetinstrumenten en de print zelf. Zo onderzoeken we ondersteuning die rekening houdt met wat de hardware werkelijk doet, van het verklaren van een meetresultaat tot het schrijven en beproeven van firmware.
VIVES Mechatronics bereidt hiervoor een SPARK-projectvoorstel voor. We zoeken Vlaamse bedrijven die elektronica en embedded systemen ontwikkelen of testen en mee willen bepalen welke problemen we aanpakken.
Van schema tot werkende print:
lokale LLM’s verbonden met code, meetinstrumenten en echte hardware,
voor inzicht, board bring-up en herhaalbare verificatie,
onder controle van de ingenieur.
Projectsituering
De PCB is geleverd. Werkt ze ook zoals bedoeld?
Een print krijgt voeding, maar start niet op. Een sensor antwoordt, maar geeft onverwachte waarden. Een verbinding werkt op de ene PCB wel en op de andere niet. De oorzaak kan in de bestukking of de signalen zitten, maar evengoed in een verkeerde registerinstelling, driver of firmwareversie. Dat onderscheid maken vraagt inzicht in zowel elektronica als embedded software.
De nodige informatie is vaak verspreid over schema’s, datasheets, errata, SDK’s, broncode en metingen. De uitdaging is die informatie samen te brengen en te beslissen welke proef werkelijk iets over de oorzaak vertelt. Een algemene codeassistent heeft die context niet vanzelf: een bruikbaar voorstel moet passen bij de chipvariant, boardrevisie en softwareversie op de werkbank.
Dat is het vertrekpunt van LLM4HW. De focus ligt op hardwareverificatie en firmware die de hardware aanstuurt, zowel bij een eerste prototype als bij uitbreidingen en terugkerende tests van bestaande producten.
Een LLM met toegang tot echte hardware
Een LLM-agent combineert een taalmodel met toegang tot kennisbronnen en softwaretools. Zo kan hij documentatie opzoeken, testcode voorbereiden, een meting laten uitvoeren en het resultaat gebruiken om een volgende stap voor te stellen. In LLM4HW willen we die werkwijze verbinden met de fysieke werkbank van de ingenieur.
Daarvoor brengen we drie onderdelen samen:
- Kennis van de print: schema’s, componentgegevens, verbindingen, datasheets en de bijbehorende firmware en SDK’s.
- Ontwikkel- en meetgereedschap: compilers, programmeer- en debuginterfaces, logic analyzers, oscilloscopen en andere geschikte instrumenten.
- Fysieke feedback: signalen en meetresultaten van de werkelijke PCB, naast buildlogs en software-uitvoer.
Een fixture vormt de verbinding met de print: een testharnas dat de relevante I/O en testpunten bereikbaar maakt. Daarmee kunnen we niet alleen firmware bouwen, flashen en uitvoeren, maar ook bekende inputs aanbieden en outputs onafhankelijk meten. Denk aan een analoog testsignaal op een ingang, een vastgelegd patroon op een bus of een meting van de voeding tijdens het opstarten. Welke functies zo getest kunnen worden, hangt af van de print en de opstelling.
Zo krijgt hardware-in-the-loop een concrete betekenis: de agent kan een hypothese toetsen aan de echte print en op basis van de meetfeedback een volgende proef of codewijziging voorstellen. De ingenieur bepaalt welke stappen de agent mag uitvoeren en waar goedkeuring nodig is.
We bouwen voort op bestaande technologie. Zo maakt Saleae Logic 2 meetopnames en protocolanalyse toegankelijk voor agents. Internationaal onderzoek, zoals de preprint IoT-SkillsBench, onderzoekt hoe gerichte expertkennis agents helpt bij embedded taken op echte hardware. Zulke bouwstenen geven ons een vertrekpunt. Met LLM4HW willen we uitzoeken hoe we ze bruikbaar maken voor bedrijfsspecifieke printen en welke aanvullende kennis, integratie en validatie daarvoor nodig zijn.
Voor wie?
Voor Vlaamse bedrijven die elektronica en embedded systemen ontwikkelen of testen. We richten ons op elektronica- en firmware-ingenieurs, testteams en technische verantwoordelijken in engineering en R&D. Zowel teams die hun eerste stappen zetten met LLM’s als bedrijven met ervaring kunnen hun vragen inbrengen.
Hoe pakken we het aan?
Onze centrale onderzoeksvraag is: hoe ondersteunen lokale LLM-agents de ingenieur betrouwbaar, en welke mate van autonomie is verantwoord voor welke taak? Een geslaagde build zegt nog niet of een signaal elektrisch correct is. Ook een overtuigende verklaring moet te herleiden zijn tot documentatie, code en metingen.
We onderzoeken verschillende vormen van ondersteuning:
- Begrijpen en uitleggen: documentatie, code en meetresultaten helpen interpreteren. De ingenieur voert zelf wijzigingen en tests uit.
- Voorstellen en voorbereiden: een diagnoseplan, testprogramma of firmwarewijziging uitwerken die de ingenieur kan beoordelen.
- Uitvoeren onder toezicht: code wijzigen, bouwen en testen, instrumenten uitlezen en hardwareacties uitvoeren binnen verleende bevoegdheden.
- Begrensd zelfstandig onderzoeken: binnen een vastgelegde opdracht hypotheses toetsen, vervolgstappen kiezen en itereren op code en tests.
Meer autonomie is niet automatisch beter. Inzicht zonder automatische codewijzigingen kan al veel betekenen. Een agent kan ook zelfstandig code bouwen, maar toestemming nodig hebben om die te flashen. De juiste combinatie hangt af van de taak, de risico’s en de werkwijze van het bedrijf.
We willen zichtbaar maken wat elke ingreep oplevert: helpt extra documentatie, verbetert fysieke feedback de diagnose en biedt fine-tuning nog meerwaarde? Daarvoor vergelijken we verschillende configuraties van dezelfde modellen en de bestaande werkwijze met ingenieurs en testautomatisering. We kijken naar correct gevonden én gemiste fouten, onterechte goedkeuringen en de tijd voor voorbereiding, uitvoering en controle. Ook de robuustheid telt: blijft de aanpak bruikbaar bij ontbrekende informatie of een onbekende boardrevisie?
Autonomie koppelen we aan grenzen die de tool- en testomgeving afdwingen, zoals toegestane acties en limieten voor voeding of beweging. Testcriteria worden onafhankelijk van de agent vastgelegd. Tijdkritische besturing en beveiliging blijven buiten de LLM.
Wat levert het project op?
De beoogde opbrengst is praktische kennis voor engineeringteams: werkende demonstratoren, herbruikbare testaanpakken en onderbouwde keuzes over tools, modelspecialisatie en autonomie. Waar bestaande oplossingen tekortschieten, willen we eigen software en koppelingen ontwikkelen. De demonstratoren moeten zowel de mogelijkheden als de grenzen zichtbaar maken, zodat bedrijven een eigen toepassing beter kunnen voorbereiden.
Waarom lokale LLM’s?
Schema’s, firmware en meetdata bevatten waardevolle bedrijfskennis. Daarom zetten we in op modellen die op eigen infrastructuur draaien: een lokale werkcomputer, server of cluster. Het taalmodel hoeft dus niet op de microcontroller van de onderzochte PCB te passen.
De inzet is datasouvereiniteit en operationele autonomie. We richten de omgeving zo in dat vertrouwelijke ontwikkelinformatie lokaal verwerkt kan worden. Bedrijven beheren zelf hun modelversies en gereedschap, kunnen een geteste configuratie behouden en updates eerst op eigen tests beoordelen. Ze bepalen welke bronnen en hardwareacties beschikbaar zijn en verminderen hun afhankelijkheid van externe modeldiensten.
We bouwen hierbij voort op de ervaring van VIVES Mechatronics met lokale AI en de Versatile Edge Clusters. We onderzoeken verschillende modellen waarvan de gewichten beschikbaar zijn voor lokale uitvoering, zonder ons aan één leverancier te binden. De vraag is hoe ver we ermee komen met de juiste kennis en gereedschappen. Lokale verwerking geeft meer controle over de omgeving, maar vraagt nog steeds beveiliging, onderhoud en toetsing van de antwoorden.
Ook bedrijven die commerciële cloudmodellen of codingassistenten gebruiken, zijn welkom. De kennis over documentatieontsluiting, testopstellingen, agentic loops en kwaliteitsbewaking kan ook voor hen bruikbaar zijn.
Onderzoekspistes en mogelijke toepassingen
Onderstaande pistes zijn het vertrekpunt voor gesprekken met bedrijven, geen vastgelegde lijst demonstratoren. We beginnen bij de fysieke print en bouwen op naar firmware, diagnose en herhaalbare tests. Modelspecialisatie en lokale infrastructuur ondersteunen die toepassingen. Samen selecteren we problemen die relevant zijn voor meerdere bedrijven. Andere voorstellen binnen deze hardwaregerichte scope zijn even welkom.
1. De fysieke PCB begrijpen en verifiëren
Na productie moet duidelijk worden of de print elektrisch doet wat het ontwerp beoogt. Een mogelijke toepassing is de agent gerichte tests te laten voorbereiden en uitvoeren, bijvoorbeeld van voedingsrails, resetgedrag, signaalpaden en analoge of digitale I/O. Een fixture en testfirmware maken de relevante toestanden en meetpunten toegankelijk.
Daarvoor is kennis van de concrete print essentieel. We onderzoeken hoe schema’s, netlists en componentgegevens uit bijvoorbeeld KiCad, Altium Designer of Autodesk Fusion bruikbare context kunnen leveren. Kan de agent een verband leggen tussen een meting, een component en de juiste passage uit de datasheet? Het doel is een bestaande print beter te begrijpen en te verifiëren, niet een nieuwe PCB vanaf nul te ontwerpen.
2. Signaalintegriteit en EMC onderzoeken
Een correct ontvangen bericht bewijst nog niet dat de signaalkwaliteit goed is. Bij signaalintegriteit onderzoeken we hoe een agent testpatronen kan voorbereiden en oscilloscoopmetingen van bijvoorbeeld timing, overshoot of ringing kan helpen interpreteren.
Bij elektromagnetische compatibiliteit (EMC) kan testfirmware bepaalde schakelpatronen, belastingen en bedrijfsmodi oproepen. We willen nagaan of een agent die toestanden kan koppelen aan meetresultaten over emissies of gevoeligheid voor storingen en zinvolle vervolgproeven kan voorstellen. Beide onderwerpen vragen geschikte instrumenten en een gecontroleerde meetopstelling. Het gaat om ondersteuning bij metingen en diagnose, niet om het vervangen van formele EMC-beoordeling.
3. Peripherals werkend krijgen en firmware ontwikkelen
Van de juiste pin- en klokconfiguratie tot een werkende driver: board bring-up vraagt kennis van het platform én van de aangesloten elektronica. Deze piste richt zich op SDK’s, hardware abstraction layers en peripheral-API’s. Denk aan STM32 HAL of ESP-IDF, bare-metalfirmware en real-time operating systems, maar ook aan device trees, kerneldrivers en boardondersteuning in embedded Linux met Yocto of Buildroot.
De fysieke werking blijft het toetsingspunt. Werkt de SPI-sensor met de verwachte timing? Blijft Ethernet betrouwbaar onder belasting? Ook een display of motorsturing kan een interessante toepassing zijn. Bij motion control kunnen encoder- of trillingsmetingen laten zien wat een firmwarewijziging werkelijk doet. De focus blijft op hardwaregerichte firmware, niet op algemene webapps of bedrijfssoftware op het toestel.
4. Hardware- en firmwareproblemen onderscheiden
Bij complexe firmware is het soms onduidelijk of een probleem in de applicatie, de driver of de elektronica zit. Een agent kan helpen die lagen uit elkaar te halen: een peripheral isoleren met minimale testfirmware, bekende inputs aanbieden en de respons vergelijken met de verwachte werking. Zo onderzoeken we hoe doelgericht gekozen proeven kunnen helpen om de oorzaak te lokaliseren en een vermoedelijke foutlaag uit te sluiten.
Een andere mogelijkheid is een goede en een verdachte print onder dezelfde omstandigheden vergelijken, of oude en nieuwe firmware naast elkaar testen. We onderzoeken of dat tot een onderbouwde oorzaakdiagnose leidt en of de agent herkent wanneer extra metingen nodig zijn. Het doel is niet alleen dat een functie weer werkt, maar ook dat de ingenieur begrijpt waarom ze eerder faalde.
5. Herhaalbare tests en foutanalyse in productie
Een geslaagde bring-up is het begin van een reeks terugkerende controles. Bij een firmwarewijziging, een nieuwe boardrevisie of een productiebatch moeten relevante eigenschappen opnieuw getest worden. We willen LLM’s inzetten bij het ontwikkelen van herhaalbare testsuites, duurtests en productiecontroles, van steekproeven tot tests op iedere print.
Daarbij hoeft niet elke meting door een taalmodel beoordeeld te worden. Een gevalideerde testsuite kan vaste controles uitvoeren, terwijl de agent helpt bij testontwikkeling en het onderzoeken van afwijkingen. Waarom valt deze print uit en de referentieprint niet? Welke bijkomende proef kan de oorzaak verduidelijken? Zo verbinden we voorspelbare testuitvoering met ondersteuning bij de minder voorspelbare foutanalyse.
6. Lokale modellen gericht specialiseren
Een model dat goed programmeert, kent niet vanzelf de juiste API van een specifieke SDK-versie of de errata van een microcontroller. We onderzoeken hoe lokale documentatie, codevoorbeelden en gerichte tools die kenniskloof kunnen verkleinen. Met retrieval-augmented generation (RAG) kan een agent relevante passages opzoeken en als context gebruiken. Gestructureerde pin- en registerinformatie en zoekfuncties in broncode vullen dat aan.
Daarnaast onderzoeken we gerichte fine-tuning: bestaande modellen verder specialiseren met trainingsmateriaal uit documentatie en gecontroleerde voorbeelden van firmware- en toolgebruik. Levert dat meerwaarde bovenop dezelfde bronnen en tools zonder fine-tuning? En blijft die winst behouden bij een ander board of een nieuwe SDK-versie? Daarbij tellen ook de inspanning voor goede trainingsdata en het onderhoud van de specialisatie mee.
7. Een volledig lokale, eventueel offline engineeringomgeving
Voor sommige bedrijven moet ook de ondersteuning bij ontwikkeling en debugging binnen het eigen netwerk blijven. Een mogelijke demonstrator is daarom een omgeving waarin model, documentatie, broncode, SDK’s en meetgereedschap lokaal beschikbaar zijn en zonder internet samenwerken.
Dat gaat verder dan alleen het model lokaal starten. We willen onderzoeken hoe ook het opzoeken van kennis, bouwen van firmware, uitvoeren van tests en bewaren van resultaten lokaal kunnen verlopen. Welke voorbereiding en welk onderhoud vraagt dat? Wat gebeurt er wanneer documentatie of een softwareafhankelijkheid ontbreekt? De agent moet dat zichtbaar maken, zonder ongemerkt naar een externe dienst uit te wijken.
Interesse en contact
Ontwikkelt of test uw bedrijf eigen elektronica? Werkt uw team aan firmware, board bring-up of terugkerende hardwareproblemen? Dan horen we graag welke vragen bij u leven. We richten ons op elektronica- en firmware-ingenieurs, testteams en technische verantwoordelijken in engineering en R&D.
Laat ons via e-mail weten welke onderzoekspistes relevant zijn en welke problemen of platformen u graag zou inbrengen. Een volledig uitgewerkte toepassing is daarvoor niet nodig. Die gesprekken helpen ons het voorstel aan te scherpen en prioriteiten te kiezen. Het gaat in deze fase om interesse in een projectvoorstel, nog niet om een definitieve toezegging tot deelname.
Bespreek uw interesse via e-mail
Vragen of liever eerst even overleggen?
Alexander D’hoore · VIVES Mechatronics