In het begin kan het lijken op een lijst parameters met wat regels ertussen. Breedte, hoogte, materiaal, motor, kleur. Voeg een paar if/then-regels toe en je hebt een configurator.
Daar kom je verrassend ver mee.
Maar zodra hetzelfde model ook engineering, pricing, geometrie of manufacturing moet ondersteunen, is een lijst opties niet meer genoeg. Het model moet duidelijker uitleggen waaruit het product bestaat, wat mag variëren, wat geldig moet blijven en welke output van die keuzes afhangt.
Daarom vind ik het nuttig om de begrippen in het model uit elkaar te houden.
Productstructuur
Het eerste is structuur.
Een product is zelden één vlakke lijst eigenschappen. Het bestaat uit assemblies, componenten, modules en features die elk een rol hebben.
Een werktafel kan een frame, poten, een werkblad en leggers bevatten. Een deur kan een deurblad, lagen, slot, scharnieren en frame bevatten. Een machine kan functionele modules bevatten die alleen bij bepaalde varianten aanwezig zijn.
Die structuur is belangrijk omdat veel rules eigenlijk over relaties tussen onderdelen gaan.
Het is veel duidelijker om te zeggen dat een legger binnen een frame hoort, of dat een slot bij een bepaalde deurbladopbouw hoort, wanneer die begrippen expliciet in het model bestaan.
Parameters
Parameters beschrijven wat kan variëren of wat berekend moet worden.
Sommige zijn klantkeuzes: breedte, materiaal, uitvoering.
Andere zijn engineeringwaarden: profielmaat, plaatdikte, motorkoppel.
Nog andere zijn afgeleide waarden die de gebruiker nooit rechtstreeks aanpast.
Ik geef parameters liever een duidelijk type en betekenis dan ze als willekeurige variabelen te behandelen.
Een breedte in millimeter is iets anders dan een materiaal-ID. Een boolean optie is iets anders dan een berekende kracht. Dat onderscheid helpt zowel mensen als software om het model te begrijpen.
Domains
Een parameter heeft een domain nodig: de waarden die hij zinvol kan aannemen.
Dat kan een numeriek bereik zijn, een lijst materialen, een set modules of een andere begrensde ruimte.
Het domain is al nuttig voor er één rule bestaat.
Het vertelt het systeem wat in principe mogelijk is.
Later kunnen constraints dat domain verkleinen op basis van de huidige configuratie.
Expressions
Veel productlogica is gewoon een berekening.
Pootlengte kan gelijk zijn aan werkhoogte min werkbladopbouw.
Vereist motorkoppel kan volgen uit belasting, straal en rendement.
Prijs kan een materiaalhoeveelheid maal een tarief bevatten.
Zulke relaties hoeven geen rule of constraint te worden wanneer een directe expression duidelijker is.
Berekeningen expliciet houden maakt het model veel makkelijker te inspecteren en testen.
Rules
Rules zijn nuttig wanneer de relatie een natuurlijke richting heeft.
Als de breedte boven een grens komt, voeg een steun toe.
Als een optie gekozen wordt, voeg een component toe.
Als een bepaalde uitvoering gekozen wordt, gebruik een andere assemblyvariant.
Dat kennen we uit parametrische CAD en automation omdat de flow meestal deterministisch is.
Rules zijn niet het probleem. Het probleem ontstaat wanneer elke relatie in directionele rules geduwd wordt terwijl het product zelf niet directioneel is.
Constraints
Constraints beschrijven relaties die geldig moeten blijven.
Ze zijn vooral nuttig wanneer verschillende keuzes elkaar beïnvloeden en er geen duidelijke eerste input bestaat.
Een plaatlengte moet binnen een proceslimiet blijven.
Een motor moet genoeg koppel leveren voor de geconfigureerde belasting.
Een bepaalde combinatie van materiaal en brandklasse kan ongeldig zijn.
Een totale breedte kan gelijk moeten zijn aan de som van verschillende configureerbare delen.
Een constraint zegt wat waar moet zijn zonder noodzakelijk de volgorde voor te schrijven waarin het systeem die toestand bereikt.
Materialen
Materiaal is meer dan een label wanneer het model moet doorlopen naar engineering of productie.
Het kan densiteit, kost, beschikbare diktes, corrosieweerstand, stockmaten, procescompatibiliteit en andere downstream beslissingen beïnvloeden.
Dat betekent niet dat elke materiaaleigenschap rechtstreeks in de configurator moet zitten.
Het betekent wel dat het productmodel naar materiaal als echt technisch concept moet verwijzen en niet alleen als tekstoptie.
Verbindingen en relaties
Een productmodel wordt veel bruikbaarder wanneer componenten expliciet met elkaar gerelateerd zijn.
Een poot draagt een frame.
Een plaat is bevestigd aan een ander component.
Een profiel eindigt tegen een plaat.
Een component is uitgelijnd met of geoffset ten opzichte van een ander.
Die relaties mogen niet meteen verward worden met exacte CAD-mates of face references.
Op productniveau legt de relatie vooral intentie vast.
De geometry layer kan later beslissen hoe die intentie exact gerealiseerd wordt.
Dat is vooral belangrijk bij configureerbare geometrie omdat exacte vlakken en coördinaten tussen varianten kunnen wijzigen terwijl de relatie hetzelfde blijft.
Manufacturing intent
Voor mij is dit één van de belangrijkste aanvullingen bovenop een klassiek configuratiemodel.
Een plaat is niet alleen geometrie. Ze kan gesneden, geplooid en afgewerkt moeten worden.
Een profiel kan een zaagsnede, tube-laserbewerking of miter nodig hebben.
Een gat kan geponst, geboord of gelaserd worden afhankelijk van het proces.
Het productmodel hoeft niet noodzakelijk een volledig productieplan te bevatten, maar het moet genoeg fabrication intent kunnen uitdrukken zodat downstream software niet moet raden wat de geometrie betekent.
Dat is de laag waar ik met mijn eigen geometry/fabrication kernel op experimenteer.
Commerciële informatie
Pricing en commerciële beschikbaarheid horen bij configuratie, maar ik meng ze liever niet onzichtbaar met technische geldigheid.
Het model kan verwijzen naar price rules, marktbeschikbaarheid, opties en commerciële pakketten.
Belangrijk is dat duidelijk blijft of een keuze technisch ongeldig is of gewoon niet aangeboden wordt.
Dat zijn verschillende redenen en ze hebben vaak andere eigenaars.
Manufacturing capability
Productintentie en fabriekscapaciteit zijn gerelateerd maar niet hetzelfde.
Het product kan een geplooide plaat nodig hebben.
De fabriek kan een plooibank hebben met een bepaalde maximale lengte en dikte.
Het productmodel moet kunnen vragen of het geconfigureerde product met de beschikbare capability gerealiseerd kan worden.
Die capaciteit kan per werkplaats, site of leverancier verschillen. Daarom zou ik niet elke machinelimiet als eeuwige eigenschap van het product hardcoderen.
Ik laat het product liever beschrijven wat het nodig heeft en het manufacturingmodel wat beschikbaar is.
Configuratie kan die twee daarna vergelijken.
Outputs zijn afgeleide views
Een geconfigureerd product kan veel output opleveren:
- geometrie;
- een stuklijst;
- tekeningen;
- een offerte;
- een zaaglijst;
- CNC- of machinedata;
- een ERP-orderstructuur.
Ik denk niet dat elk van die outputs een aparte versie van het product moet worden.
Ze zijn beter te behandelen als afgeleide views van één geconfigureerde definitie.
Dat is één reden waarom ik het onderliggende model expliciet wil maken. Als de bron samenhangend blijft, kunnen verschillende outputs veranderen zonder opnieuw te definiëren wat het product is.
Identiteit is belangrijk
Elk belangrijk begrip heeft stabiele identiteit nodig.
Een component mag niet alleen “het derde item in een array” zijn. Een parameter mag niet afhangen van het label dat in één interface getoond wordt. Een relatie moet naar een component kunnen verwijzen zonder afhankelijk te zijn van de huidige geometrie.
Stabiele IDs maken vertalingen, revisions, APIs en automatische authoring veel veiliger.
Dat wordt extra belangrijk wanneer AI of externe tools het model moeten kunnen lezen en aanpassen.
Het model moet machine-readable zijn
Menselijke documentatie is nuttig, maar een configurator heeft formele definities nodig.
Daarom werk ik voor de kernbegrippen liever met typed structures en schemas.
Als een systeem weet wat een Profile, Plate, Parameter, Constraint of Material nodig heeft, kan het model gevalideerd worden voor geometrie of pricing gegenereerd wordt.
Hetzelfde schema kan daarna een UI, API, authoring tool of AI-agent sturen.
Machine-readable betekent niet onleesbaar.
Een goed schema moet het product makkelijker begrijpbaar maken en niet verstoppen achter technische ceremonie.
Niet elk product heeft elk concept nodig
Deze lijst kan een productmodel groot doen lijken.
Dat hoeft niet.
Een eenvoudig configureerbaar product heeft misschien alleen structuur, enkele parameters, domains en expressions nodig.
Een complexer product kan constraints, materialen, manufacturing intent en capability checks toevoegen.
Het belangrijke is dat het model kan groeien zonder elk nieuw probleem in een hoop ad-hoc rules te moeten duwen.
Dat is voor mij de echte test van een configureerbaar productmodel.
Het moet eenvoudig kunnen blijven wanneer het product eenvoudig is, maar genoeg structuur hebben om een complex product uit te leggen zonder de betekenis erachter te verliezen.