Een paar weken geleden schreef ik waarom ik aan een semantische fabrication kernel begon. Sindsdien heb ik er heel wat meer van gebouwd. De huidige versie kan je proberen op kernel.kubuz.net.
De reacties op dat eerste stuk waren nuttig. Ze dwongen me iets uit te leggen dat ik niet goed uitgelegd had: waarom überhaupt een geometry kernel bouwen?
Het antwoord is eenvoudiger dan het woord semantisch doet vermoeden. Ik wilde configuratoren voor producten die in een gewone werkplaats gemaakt worden. Geplooid plaatwerk, profielen, verstekken, gaten, uitsparingen en eenvoudige samenstellingen. Echte productdefinities, niets exotisch. En die producten moesten bijwerken terwijl iemand ze aan het configureren was. Dat bleek moeilijker dan ik had verwacht.
De twee gewone routes
Inventor, SolidWorks en de andere CAD-systemen kunnen dit allemaal modelleren. Ze kunnen veel meer dan wat ik aan het bouwen ben. Zodra die geometrie in een webconfigurator moet zitten, zijn er meestal twee routes. Je automatiseert CAD op een server, of je brengt een algemene geometry kernel via WebAssembly in de browser.
Beide zijn zinvol. Voor de producten waar ik mee bezig was, was dat allebei te veel installatie. Ik gebruikte voor dit werk geen volledig CAD-pakket.
Ik had een plaat nodig die een paar keer kon plooien, een profiel dat schuin afgesneden kon worden, een gat dat een gat bleef, en een paar stukken die samen een samenstelling vormden. Dat moest snel genoeg evalueren om in de interactie van een configurator te blijven.
De vraag waarmee ik begon: hoe klein kan die geometry engine zijn als hij alleen de fabricagebewerkingen begrijpt die ik echt nodig had? Daar is de kernel begonnen.
Een kleine fabricagetaal
De eerste versies waren heel beperkt. Een plaat had een vlak, een rand kon een flange worden, en een profiel had een sectie en een lengte. Toen dat werkte, groeide de woordenschat. Flanges kregen hoeken en gedeeltelijke lengtes. Hems kwamen erbij, een rand die omgezet wordt. Profielen kregen verstekken en bewerkingen. Rollen en transities volgden, en onderdelen konden samen in een samenstelling geplaatst worden.
Omdat de kernel in de browser draait via WebAssembly, betekent een parameter wijzigen niet dat er ergens een CAD-document opent en moet herrekenen. Het programma evalueert gewoon opnieuw.
Dat was het eerste belangrijke resultaat. Het tweede verraste me meer. De input was geen mesh, en ook geen losse anonieme vlakken. Er zat nog fabricagebetekenis in. Een flange bleef een flange, een hem bleef een hem, en een verstek bleef een verstek.
{
"op": "flange",
"on": "Top",
"edge": "e3",
"outside": 40,
"angleDeg": 90
}
Het interessante zit niet in het JSON-formaat. Het zit in het woord flange. Dat woord heeft een betekenis. De kernel weet wat hij ermee moet doen: hoe de bewerking de uitslag beïnvloedt, hoe de plaat plooit, en welke geometrie eruit moet komen.
Daar begon het woord semantisch voor mij te kloppen. JSON is alleen een handig formaat, en de kernel begrijpt het volledige product niet. Het programma zegt nog welk soort fabricagebewerking iets is, in plaats van alleen de eindvorm te beschrijven.
Waar de kernel stopt
Tijdens het bouwen werd de grens ook duidelijker.
Ik wil nog altijd een model dat weet wat onderdelen betekenen en hoe ze zich tot elkaar verhouden. Daarover schreef ik in geometrie is niet het productmodel. Die kennis hoort niet allemaal in de geometry kernel.
Een product kan weten dat een stuk de achterregel van een tafel is, dat de lengte afhangt van de tafelbreedte, dat er boven een bepaalde overspanning een schoor nodig is, en dat een optie een extra onderdeel toevoegt. Dat is productkennis. Die hoort in de CPQ of in het productmodel.
Tegen de tijd dat de geometry kernel het stuk ziet, is de vraag concreet. Het productmodel kan zeggen dat dit de achterregel van de tafel is. Het fabricageprogramma zegt dat het een RHS 40 × 40 × 2 is, 842 mm lang, met deze eindsnede en deze gaten. De kernel maakt daar geometrie van.
Hetzelfde onderscheid zie je op één profiel. Een verstek blijft in het programma een verstek, niet alleen een solid met een schuin vlak.
Het productmodel beschrijft het product. Het fabricageprogramma beschrijft hoe de stukken gemaakt worden. De kernel evalueert dat programma, en geometrie is één van de resultaten.
Ik wil niet dat geometrie het productmodel is. Ik wil dat ze uit een betekenisvollere beschrijving komt.
Zonder CAD-rebuild
Een eerlijke vergelijking is DriveWorks of KBEWorks. Die tools koppelen productregels al aan CAD, en ze lossen echte problemen op. Dit experiment neemt een andere route.
In plaats van CAD als rekenmotor achter de configurator te gebruiken, vraag ik of sommige producten die stap tijdens het configureren kunnen overslaan. De flow wordt dan: configuratie, fabricageprogramma, kernel, resultaat. De andere flow is: configuratie, CAD-model, rebuild, resultaat.
Er draait geen CAD-toepassing op de achtergrond, en er is geen CAD-document dat moet openen, herrekenen en opslaan. De kernel hoeft niet alles te kunnen wat een engineer ooit zou willen modelleren. Hij moet alleen een kleinere set fabricagebewerkingen begrijpen.
Die beperking is het hele idee. De meeste bedrijven die CAD gebruiken, gebruiken maar een beperkt deel ervan, vaak zoiets als 10 tot 20 procent van wat de software kan.
Hoe meer ik bouw, hoe interessanter die afweging wordt. Profielen, schuine snedes, bewerkingen, rollen, transities en grotere samenstellingen passen nu in dezelfde kleine taal.
Er komt een punt waar dit niet meer het juiste gereedschap is en volledig CAD de betere keuze wordt. Ik weet nog niet waar dat punt ligt.
Meer dan het 3D-beeld
Als dit alleen meshes uit parameters maakte, was het gewoon een 3D-configurator. Het 3D-beeld is één output. Hetzelfde programma kan ook de uitslag, plooi-informatie, materiaalgebruik en andere fabricagematen geven.
De laatste tijd laat ik de geometrie ook eenvoudige vragen over zichzelf beantwoorden.
- Lopen twee stukken door elkaar?
- Zit er een spleet waar twee gemaakte uiteinden elkaar zouden moeten raken?
- Botst een geplooide plaat met zichzelf?
- Raken onderdelen elkaar zoals het programma verwacht?
Dat zijn geometriecontroles, geen engineeringgoedkeuring. Daar wordt het interessant. Eerst liep de flow vooral in één richting: programma erin, geometrie eruit. Het begint een lus te worden. Het programma gaat erin, de geometrie komt eruit, en de controles komen terug. Software kan over het resultaat redeneren, niet alleen het tonen.
Wat een agent kan zeggen
Daarom denk ik nog altijd dat het gestructureerde programma bruikbaar kan zijn voor AI. Ik zou dat nu anders uitleggen. Dat taalmodellen vlot JSON lezen, is niet de reden. JSON is alleen een handig formaat.
Wat telt is dat de taal klein en expliciet is. Een model hoeft niet te weten hoe je een correcte uitslag berekent. Het kan zeggen: zet hier een flange. De kernel blijft verantwoordelijk voor de geometrie. Het model werkt met intentie, en de kernel blijft deterministisch.
Na de evaluatie kan het resultaat opnieuw gecontroleerd worden. Dat geeft een agent een lus die hij echt kan gebruiken: het programma aanpassen, evalueren, het resultaat bekijken, en corrigeren.
Ander engineeringswerk beweegt in een gelijkaardige richting, met een kleiner gestructureerd model voor de intentie en deterministische software voor de output. Ik denk niet dat het belangrijke idee is dat engineering plots in JSON geschreven moet worden. Het interessantere patroon is een kleine domeintaal voor de intentie, en een deterministische engine die daar engineeringoutput van maakt. Ik wil zien hoe ver dat patroon kan gaan voor mechanische fabricage.
SysML v2 hielp me de lagen ook te plaatsen. Een systeemmodel kan eisen, relaties en functies vasthouden. GD&T kan een andere betekenis toevoegen, door toelaatbare variatie te beschrijven. Geen van beide vervangt iets dat fabricage-intentie in geometrie kan omzetten. Ze lossen andere problemen op, en ze kunnen naast elkaar staan.
Hoe ver dit kan gaan
De scheiding is duidelijker nu er meer van de kernel staat. Erboven zit een productmodel. Tussen het product en de geometrie zit een fabricageprogramma. Een kleine engine begrijpt dat programma goed genoeg om er geometrie en fabricagefeedback van te maken.
Kort: productbetekenis, dan fabricage-intentie, dan geometrie.
De oorspronkelijke reden was praktisch. Ik wilde lichte fabricagegeometrie rechtstreeks in de browser. De semantische laag kwam daarna in beeld, omdat die kleine fabricagetaal een bruikbare grens bleek tussen productkennis en geometrie. De AI-hoek kwam nog later, omdat een kleine expliciete taal voor een software-agent makkelijker is dan willekeurige geometrie.
De vraag die me het meest interesseert, blijft open. Hoeveel configureerbare fabricage kan je zo beschrijven voor je echt volledig CAD nodig hebt?
Ik ken het antwoord nog niet. Ik heb genoeg van de kernel gebouwd om te denken dat de vraag de moeite waard is. De volgende stap is ermee ontwerpen.