Technische informatiesystemen, zoals cad-systemen, zijn zo goed te ontwikkelen omdat ze objectgeoriënteerd zijn. De software is opgedeeld tot in de kleinste te vervullen functies: objecten of ‘features’. Helaas ontbreekt elementaire kennis van administratieve processen, nodig voor feature-ontwikkeling en -ontwerp, nog in belangrijke mate. Hierdoor loopt de ontwikkeling van administratieve systemen achter, aldus professor F.J.A.M. Van Houten (Universiteit Twente) in een interview.
| Gebruiksvriendelijk ontwerpen Na de introductie van systemen ter ondersteuning van het ‘feature based collaborative’ ontwerpen, produceren en service verlenen (levenscyclusbeheer), komt het gedraggeoriënteerd ontwerpen nu in de gebruiksfase. Het vindt al toepassing in de researchlaboratoria en ontwikkelafdelingen van de automobielindustrie. Over zo’n jaar of vijf – schat Van Houten – is het ook toepasbaar in middelgrote ondernemingen. Als volgende ontwikkeling onderzoekt Van Houtens vakgroep hoe producten in het virtuele stadium zijn te beproeven en hoe het resultaat van deze beproevingen weer als ontwerpcriteria te gebruiken zijn. Dit proces speelt zich af in de zogenaamde haptische infrastructuur, in de mens/voorwerp-relatie. Gevoel bij het aanraken van virtuele producten, gecombineerd met horen en zien, speelt in de haptische infrastructuur een belangrijke rol bij hanteren, bedienen en serviceverlening. De beoordeling van het schakelgedrag van een auto in de showroom door een potentiële klant weegt mee bij zijn aankoopbeslissing, ondanks dat dit schakelgedrag weinig te maken heeft met het (functionele) schakelen tijdens de rit. Met behulp van haptische interfaces wordt nu onderzocht hoe de potentiële klant het gedrag van virtuele producten waardeert en hoe de interacties tussen mens en product te kwantificeren zijn. De volgende stap is om de gekwantificeerde informatie toe te passen als ontwerpcriterium en in te bouwen in het proces van gedraggeoriënteerd ontwerpen. Het ‘haptics’-onderzoek is vooral gericht op het kunnen meten van het gevoel in de vingers, meer in het algemeen van ledematen, het voelen van trillingen en spelingen, en op bediening. Onderzoek naar en ontwikkeling van haptische apparatuur zelf speelt in de huidige ontwikkelingsfase een belangrijke rol. Het voelbaar maken van oppervlaktestructuren is een stuk ingewikkelder. Gevoelsvriendelijk ontwerpen bevindt zich nog in een embryonaal stadium, en is wellicht pas over vijf jaar rijp voor toepassing. |
Professor dr. ir. F.J.A.M. van Houten staat aan het hoofd van de vakgroep Ontwerp, Productie en Management van de faculteit Construerende Technische Wetenschappen en Engineering van de Universiteit Twente. Van Houten ontwikkelt al vanaf het begin van de jaren tachtig technieken ter ondersteuning van het ontwerpproces. De nadruk ligt daarbij op technisch ‘engineering’.
Bij ‘engineering’ denken we vooral aan het technische proces; aan het concipiëren en ontwikkelen van de moderne auto, de sensor, de procesbesturing of de processor. In toenemende mate worden echter business-, organisatie- en informatiesystemen ontwikkeld.
Weinig gestructureerd proces
"In de meeste bedrijven was construeren van oorsprong een, in organisatorische zin, weinig gestructureerd proces", begint Van Houten zijn betoog. "Men begon veelal direct met de details op basis van een ad hoc interpretatie van de wensen van de marketing- of verkoopafdeling, zonder eerst de correctheid en de relevantie van de probleemstelling ter discussie te stellen en vervolgens op systematische wijze naar een oplossing te zoeken. De toepassing van ict in het ontwerpproces heeft deze werkwijze wel beïnvloed maar niet drastisch veranderd. Technisch rekenen met behulp van de eindige-elementenmethode deden we in de jaren zestig al op het mainframe. Dankzij de grafische beeldbuis drong 2d-cad door in het tekenproces. Door de steeds krachtiger wordende hardware vond begin jaren tachtig het 3d-modelleren opgang. Op het beeldscherm ontstonden ‘solids’, de driedimensionale beelden van de onderdelen en van de samenstelling. "
"Om ‘solids’ consistent te kunnen modelleren moet je denken in productstructuren en productfamilies", stelt Van Houten. "Die structuren moet je goed begrijpen. Met een productgenerator kun je op basis van die structuren allerlei productvarianten genereren. Een productstructuur en de daarvan af te leiden varianten zijn dus binnen bepaalde grenzen te manipuleren. Het gevolg daarvan is wel dat sterk afwijkende oplossingen impliciet zijn uitgesloten. Een productstructuur houdt zowel een rationalisatie als een beperking van de mogelijkheden in."
"Ongeveer tegelijk met het begin van de academische ontwikkelingen op het gebied van ‘solid modeling’ zijn we aan de TU begonnen met ‘feature based manufacturing en design’. ‘Features’ zijn de kleinste technisch zinvolle eenheden waaruit een productmodel kan worden opgebouwd. Een feature kan bijvoorbeeld een bepaalde configuratie van productoppervlakken zijn die samen een bepaalde functie vervullen of samen op een bepaalde manier gecreëerd worden. Componenten opgebouwd uit ‘features’ werden de basis voor objectgeoriënteerd ontwerpen en dat is weer de basis voor ‘collaborative engineering’. Dankzij ‘feature-based design’ konden componenten, en daarmee producten, klantspecifiek worden geconfigureerd en gefabriceerd. Gevolg was een enorme verlaging van ontwerpkosten, ontwerp- en fabricagedoorlooptijd. De flexibiliteit van het proces nam fors toe. Het sterke punt van 3d-modelleren is de mogelijkheid tot opdeling van een ontwerp in modules. Indien de raakvlakken, de interfaces tussen de modules goed worden gedefinieerd, zijn eenduidige afspraken te maken over wie wat ontwerpt en wat fabriceert tegen welke kwaliteit.
Functiegericht ontwerpen
Desalniettemin laat het huidige proces van 3d-modelleren toch nog een aantal vragen onbeantwoord. Lang niet alle problemen zijn in dit nieuwe ontwerpproces opgelost. Bij het gebruik van de meeste cad-systemen is de werkwijze als volgt: kies eerst het materiaal en definieer vervolgens de geometrie. De gedefinieerde geometrie moet maakbaar zijn met het fabricageproces voor het gekozen materiaal. De keuze van het te volgen fabricageproces is echter ook in belangrijke mate afhankelijk van de seriegrootte. Verandert deze, dan is het mogelijk dat men een goedkopere fabricagemethode wil kiezen. Helaas zijn materiaal, fabricageproces en geometrie niet onafhankelijk van elkaar te wijzigen. Dat heeft tot gevolg dat men de geometrie vaak opnieuw gedefinieerd moet worden.
Daar komt nog een probleem bij. In functionele zin moeten onderdelen op plaatsen waar zij elkaar raken, een bepaalde speling hebben (bijvoorbeeld om onder alle omstandigheden met een zekere nauwkeurigheid ten opzichte van elkaar te kunnen bewegen). Anderzijds kunnen onderdelen maar met een begrensde nauwkeurigheid (tolerantie) worden gemaakt. De toleranties op de onderdelen bepalen tezamen de speling tussen de onderdelen. In complexe ontwerpen met veel onderdelen is het voor de constructeur onmogelijk om te overzien welke toleranties moeten worden opgegeven om te zorgen dat aan alle functionele spelingseisen is voldaan. Het ‘nauwkeurigheidsprobleem’ is momenteel niet afdoend in het modelleringsproces opgelost.
Om aan een ontwerp dan ook de vereiste materiaal- en geometrieflexibiliteit en de juiste spelingen te geven, moet het ontwerpproces geheel anders worden ingericht. We moeten van geometriegericht ontwerpen naar functiegericht ontwerpen. Het ontwerp moet in de eerste ontwerpfase vrijwel geometrieloos worden gedefinieerd. Dat heet ‘embodiment’. Wanneer een product van zijn geometrie wordt ontdaan, blijft een skelet over. Daarmee is veel flexibeler te manipuleren dan met een precies geformuleerde geometrie. In het kader van het onderzoekproject ‘gedraggebaseerd ontwerpen’ houdt de vakgroep van Van Houten zich bezig met de volgende zaken: formuleren van de functionele eisen, deze vastleggen in een ontwerpmethodiek die de geometrie genereert, en simuleren of de gegenereerde geometrie wel voldoet.
Gedrag staat centraal
"De tijd is nu rijp om het conventionele ontwerpproces te vervangen door dit nieuwe proces, dat gebaseerd is op scenario-denken", zo luidt Van Houtens credo. "Eerste stap in dit scenario is het neerzetten van een systeem- of productomgeving, en formuleren hoe het systeem of product zich in die omgeving dient te gedragen. Daaruit volgt een programma van functionele eisen. Denk bijvoorbeeld aan umts, defensie- en veiligheidssystemen die op de nieuwe politieke en maatschappelijke verhoudingen zijn gebaseerd, maar ook aan de moderne fiets, de stadsauto van morgen, een ontwerp- en fabricagetechniek voor vezelversterkte kunststoffen of een informatiesysteem. Een schitterend voorbeeld is de gsm-telefoon, met functies voor nummers kiezen, voicemail, verbinding maken als a met b wil praten, energievoorziening, schermverlichting en teletekst-input; verder is hij licht en schok- en valbestendig. Bij het maken van zo’n functioneel ontwerp staat het gedrag van het systeem of het product centraal en niet de geometrische productspecificatie. Het ontwerpproces wordt bij het gedraggebaseerd ontwerpen als het ware omgedraaid. Het systeem- of productgedrag wordt vastgelegd en simuleerbaar gemaakt in het skelet’.
Voor materiele producten bestaat zo’n skelet uit een virtuele constructie met knooppunten en verbindingen. Het skeletontwerp is een abstract netwerk, dat wordt opgebouwd uit objecten met hun belasting, hun specifieke speling en slijtagegedraging, en uit relaties tussen de objecten. De objecten kunnen vervolgens op diverse manieren en met diverse materialen en productietechnologieën worden gerealiseerd. Zo’n ontwerp is dan niet meer aan bepaalde materialen of bewerkingstechnologieën gebonden. Er kan, wanneer dat effectiever is, tijdens de levenscyclus van een product overgestapt worden op andere materialen of productiewijzen.
Voorwaarde voor toepassing van het skeletconcept is dat in de fase van geometriegeneratie, componenten van het ontwerp kunnen worden gegenereerd. En wel op basis van algemene fysieke ontwerpprincipes, catalogi met componenten, randvoorwaarden om het skelet los te koppelen van het ‘solid model’ en randvoorwaarden voor het kiezen van optimale fabricageprocessen. Daarnaast zijn er voorwaarden voor materiaalselectie.
"Geen enkele cad-applicatie voldoet aan de eisen van een dergelijk flexibel ontwerpsysteem’, stelt Van Houten. ‘Geen enkel cad-pakket heeft ook afdoende functionaliteit voor het goed ontwerpen van de spelingen in een ontwerp. Er is behoefte aan nieuwe functionaliteit, waarin de tekortkomingen worden opgelost. Wij ontwikkelen de tools met die functionaliteit en de bijbehorende kennis om ze te kunnen toepassen. "
"Het gedraggeoriënteerd ontwerpen wordt momenteel ook in de praktijk geïntroduceerd; onder meer bij Daimler Chrysler. Drie van Van Houtens promovendi werken bij Daimler Chrysler Forschung und Technologie aan de ontwikkeling en introductie van nieuwe cad-applicaties."
Technische versus administratieve systemen
Cad-systemen zijn, in tegenstelling tot de meeste administratieve systemen, goed uit te bouwen. Zij zijn anders opgebouwd: object georiënteerd. Software-ontwikkeling verloopt in het technische traject parallel aan productontwikkeling. De doorsnee ingenieur kan uitstekend met technische software omgaan en dat komt omdat die software net zo is gestructureerd als een technisch product. Ook het software-traject start daar met het ontwikkelen van een concept om er vervolgens de functionele eisen aan toe te voegen. Daarna worden de technische eisen op een rijtje gezet en kan het programmeren beginnen. Dat programmeren vindt zijn oorsprong in het denken van de zestiger jaren.
"In dat denken is altijd geworsteld met de dualiteit tussen programma’s en datastructuren. In de oertijd van het programmeren werd op machinetaalniveau gewerkt en kon een instructie bijvoorbeeld ook als een getal worden geïnterpreteerd, en omgekeerd", aldus Van Houten. "Daardoor werd kostbare geheugenruimte bespaard en konden uiterst efficiënte programma’s worden geschreven. Dit speelde vooral een rol bij besturingscomputers voor ‘real time’ applicaties. De programma’s waren echter bijna niet te begrijpen, laat staan te onderhouden door iemand die ze niet zelf geschreven had. In de administratieve software is die werkwijze niet gevolgd. Daar is praktisch van meet af aan een scheiding aangebracht tussen programma’s en data. Gevolg is dat het programma steeds meer ondergeschikt is geraakt aan de data en dat dataopslag een eigen leven is gaan leiden. De basis voor een applicatie werd het datamodel. Al in de jaren zestig ontstond daardoor de vraag ‘wat in het programma en wat in het datamodel moest worden opgeslagen’. Dit spanningsveld is nooit opgelost, in tegendeel, het is verergerd. Het datamodel is een enorm gecompliceerde en logge infrastructuur geworden, die rampzalig is voor de flexibiliteit van de administratieve software."
In de techniek is die weg niet gevolgd. Daar moest, zeker in de omgeving van de ingebedde software, maar ook als het gaat om het doorrekenen van constructies en vervolgens het omgaan met virtuele modellen, enorm zuinig worden omgegaan met de beschikbare verwerkings- en opslagcapaciteit van de hardware. Programma’s en data zijn daartoe bij elkaar gehouden, en dat heeft geleid tot het objectgeoriënteerd programmeren. In het object zijn de eigen structuur, data en programma’s opgenomen. We zien nu dat het verschil tussen data en programma’s ook steeds kleiner wordt, vooral bij neurale netwerken. Het verschil tussen de diverse soorten entiteiten lost op. In de techniek is bovendien de vraag naar ‘wat software oplost’ allesoverheersend. Software moet voldoen aan die primaire functie. Dat betekent dat deze volledig doorzichtig, betrouwbaar en implementeerbaar moet zijn. Zij moet daarnaast onderhouden kunnen worden, bijvoorbeeld bij veranderende gebruikerseisen; software moet configureerbaar zijn. In de spreadsheet is aan die voorwaarden voldaan. Met een spreadsheet kun je objectgeoriënteerde oplossingen bouwen, compleet met cad-objecten, technische rekenmodellen, enzovoort. Er zijn spreadsheet-achtige oplossingen in de markt, waarmee omvangrijke, objectgeoriënteerde informatiesystemen kunnen worden gebouwd; zowel technische als administratieve.
Ontwerpen met ‘features’
"De meeste erp- en crm-systemen missen niet alleen de objectgeoriënteerde structuur, zij zijn ook niet goed geïmplementeerd", stelt Van Houten. "In de technische informatiesystemen is de software opgedeeld tot de kleinste te vervullen functies; objecten of ‘features’. Een ‘feature’ is een structuur waaraan al die kennis, data en relaties worden gekoppeld die nodig zijn om zo’n object te kunnen manipuleren; om het te configureren, te visualiseren, samen te voegen met andere features tot modules. De in de features ingebouwde functies voor het reageren op interacties met de omgeving worden deel van de modules en de systemen die weer uit de modules worden opgebouwd. Features zijn niet beperkt tot alleen de technische functies. ‘Feature based design’ is een discipline die overal kan worden toegepast. Dat geldt evenzogoed voor de software, de onderhoudsvoorschriften of de noten in de muziek. Alles in de moderne techniek bestaat nu uit deze bouwsteentjes, waaruit het moderne product of proces wordt opgebouwd."
"Er zijn nu structuren om met behulp van die features te ontwerpen, te fabriceren en in toenemende mate ook service te verlenen. We hebben een nieuw concept voor dat structureren ontwikkeld. Voor dat nieuwe concept van gedraggeoriënteerd ontwerpen zijn nieuwe ‘features’ nodig, waarmee nieuwe processen zijn te realiseren. Het gedraggeoriënteerd denken speelt zich af op hogere abstractieniveaus; los van het specifieke, zichtbare en tastbare product. Ook in dat soort denken neemt de vaardigheid toe. We zijn gaan denken in structuren, en ‘decomponeren’ die structuren in objecten en relaties, kleden processen uit tot op ‘feature’-niveau. De representatie van ‘embodiment’ is de nieuwe laag die aan cad-systemen is (of wordt) toegevoegd. Daarmee wordt het mogelijk ‘assembly engineering’ te doen; een eerste stap naar ’top-down’ ontwerpen. Samen met de introductie van dynamische simulatie levert dat de mogelijkheid om het proces van gedraggeoriënteerd ontwerpen te implementeren. De processen hebben we geformuleerd en bediscussieerd in wetenschappelijke artikelen, deels in eigen laboratoria onderzocht en ontwikkeld, en nu komt deze functionaliteit langzamerhand beschikbaar in commerciële systemen. "
Probleem bij administratieve processen
De wijze van opbouw en implementatie richt zich op het minimaliseren van de hoeveelheid inspanning om de systemen aan te passen aan nieuwe inzichten en randvoorwaarden. Wanneer de latere gebruikers een nieuwe benadering en de nieuwe objecten op hun eigen manier toepassen, moet alles precies kloppen. Net zoals de ingenieur het staal altijd naar zijn hand heeft gezet, zo doet hij dat ook met de technische software.
Dat is een groot verschil met de administratieve wereld. De meeste administratieve systemen zijn niet naar de hand van de meester te zetten. Dat komt omdat de administratieve software in de meeste gevallen niet wezenlijk modulair is. De erp- en crm-applicaties zijn nog altijd uitdijende monolitische structuren. De ontwikkeling van die structuren kan met de spreadsheet-achtige software, waarmee wel flexibele, objectgeoriënteerde software is te ontwikkelen, worden doorbroken. Maar dan stuit men in de administratieve processen op een tweede probleem; het opdelen van de software in elementaire functies. Er is geen enkele erp- of crm-softwareleverancier die er tot op heden in is geslaagd om de huidige functies uiteen te rafelen tot eenduidige basisfuncties; tot logistieke, financiële, commerciële, personele en management-features.
Die tekortkoming werkt enorm remmend op de ontwikkeling van de administratieve software, die de afgelopen decennia in de breedte is gegroeid. De financiële- en voorraadadministratie werd MRP I, MRP II, toen erp, en nu crm, met als enige resultaat dat over steeds grotere trajecten kan worden geïntegreerd en gecommuniceerd. Voor de technische ict geldt een zelfde ontwikkelingspatroon. Het fundamentele verschil is echter dat zij daarnaast stapsgewijs de virtuele wereld kon scheppen die bijdraagt aan de mogelijkheid om vooraf te beoordelen in welke mate aan hoofd- en nevenfuncties van het product wordt voldaan.
Lange geschiedenis techniek
De ontwikkeling van technische processen verloopt veel sneller en ingrijpender dan die van administratieve processen. Dat komt in de eerste plaats doordat de techniek, veel meer en langer dan welke andere discipline, engineers heeft voortgebracht. Zij hebben voor het realiseren van hun dromen zelf tools ontwikkeld om makkelijk producten of systemen te kunnen genereren. Ze bezitten niet alleen elementaire kennis van processen, maar vooral ook van het op nieuwe manieren structureren daarvan. ‘Engineering’ breekt nu ook door in de logistieke, commerciële en financiële disciplines. De elementaire kennis van de administratieve processen, nodig voor feature-ontwikkeling en feature-ontwerp ontbreekt daar nog in belangrijke mate. Het abstractieniveau in het conceptuele denken is te laag, waardoor de basis voor objectgeoriënteerde systeemontwikkeling te smal is. De potentie van zowel ontwikkeling als toepassing is groot: objectgeoriënteerde systemen zijn sneller en veel goedkoper te ontwikkelen en effectiever in de toepassing, flexibel aan nieuwe eisen aan te passen en makkelijker in te voeren.
Cees van Heijkoop freelance medewerker
