• Aucun résultat trouvé

Configuration knowledge modeling: How to extend configuration from assemble/make to order towards engineer to order for the bidding process

N/A
N/A
Protected

Academic year: 2021

Partager "Configuration knowledge modeling: How to extend configuration from assemble/make to order towards engineer to order for the bidding process"

Copied!
14
0
0

Texte intégral

(1)

To link to this article:

DOI:10.1016/j.compind.2018.03.019

URL:

http://dx.doi.org/10.1016/j.compind.2018.03.019

This is an author-deposited version published in:

http://oatao.univ-toulouse.fr/

Eprints ID: 19951

To cite this version

:

Sylla, Abdourahim and Guillon, Delphine and Vareilles, Elise and

Aldanondo, Michel and Coudert, Thierry and Geneste, Laurent

Configuration knowledge modeling: How to extend configuration from

assemble/make to order towards engineer to order for the bidding process.

(2018) Computers in Industry, vol. 99. pp. 29-41. ISSN 0166-3615

O

pen

A

rchive

T

oulouse

A

rchive

O

uverte (

OATAO

)

OATAO is an open access repository that collects the work of Toulouse researchers and

makes it freely available over the web where possible.

Any correspondence concerning this service should be sent to the repository

administrator:

staff-oatao@listes-diff.inp-toulouse.fr

(2)

Configuration

knowledge

modeling:

How

to

extend

configuration

from

assemble/make

to

order

towards

engineer

to

order

for

the

bidding

process

Abdourahim

Sylla

a,b,

*,

Delphine

Guillon

a,c

,

Elise

Vareilles

a

,

Michel

Aldanondo

a

,

Thierry

Coudert

b

,

Laurent

Geneste

b

aUniversitédeToulouse,IMT-MinesAlbi,CentredeGénieIndustriel,Albi,France bUniversitédeToulouse,INP-ENIT,LaboratoireGéniedeProduction,Toulouse,France cEcoleSupérieuredesTechnologiesIndustriellesAvancées,ESTIARecherche,Bidart,France

Keywords: Biddingprocess Assemble/Make-to-Order Engineering-to-Order Configurationsoftware Knowledge-basedmodel Constraintsatisfactionproblem

ABSTRACT

Thebiddingprocessisoneofthemostimportantphasesforsystemcontractors.Asuccessfulbidimplies definingandimplementingattractiveandrealisticsystemssolutionsthatfulfillcustomerexpectations. An additional challenge arises with the increase in systems diversity resulting from growing customizationneeds.Asaresult,forstandardcustomizingoffers,biddersfindgoodqualitysupport withconfigurationsoftwareforassemble/make-to-ordersituations.Butwhenrequirementsexceedthe standardoffers,biddersneedextendedsupporttofulfillEngineering-to-Orderrequirements.Inthis context, this article shows howconfiguration knowledge models, which support configuration in assemble/make-to-ordersituations(AMTO),canbeextendedandusedinengineer-to-ordersituations (ETO). Modelingis achievedassumingthattheconfigurationproblemisconsidered asaconstraint satisfactionproblem.SixkeyrequirementsthatdifferentiateETOfromAMTOareidentifiedandmodeling extensionsareproposedanddiscussed.Anexampleillustratesallthecontributions.

1.Introduction

Acallfortendersisaprocedurewhereacustomerasksseveral

potential contractors (bidders) to make different commercial

offersforthedevelopmentofaproductorsystem[1,2].Itgivesthe customertheopportunitytocompareseveraloffersandtochoose thebestoneintermsofprice,performanceanddeliverydate.After thereceptionof aninvitationtosubmit,thebiddersstart their bidding process, which consists mainly of four activities: (i) analysisofthebidopportunity,(ii)elaborationofthebidsolution, (iii)drawingupofthecommercialbidand(iv)transmissionofabid proposal[3,4].Thecontributionpresentedinthispaperadoptsthe

bidder’s point of view and aims to support and improve the

elaborationofthebidsolutionusingaknowledge-basedsystem.

LikeKrömkeretal.[5]andYanetal.[6],weconsiderthatabid solutioniscomposedofatechnicalpart(billofmaterialdrawing

together sub-systems and components) and a delivery process

(composedof keyrequiredactivitiesand resources).Butinthis paper,wevoluntarilyrestrictourproposaltothetechnicalpart,as itis moresensitivetocustomerrequirementsthanthedelivery

process. Indeed, a non-standard requirement, such as a new

feature,leadingtoa non-standardsolution,mainlyimpacts the technicalpartofthebid.Thedeliveryprocessislessimpacted,as thesetofrequiredactivitiesisassumedtobethesamewhatever thetechnicalsolution;wearguethatonlyactivitydurationsand keyresourcescanbedifferentbetweenastandardsolutionanda non-standardone.Thedeliveryprocessisthusnotconsideredin thisarticle.

Depending on the system diversity and the customer’s

requirements,twokindsofindustrialsituationscanbeidentified whenelaboratingthetechnicalpartorsolutionforthebid[7–9]. ThefirstsituationisConfigure-To-Order(CTO)whichis

intrinsi-cally linked to Assemble-To-Order (ATO) and Make-To-Order

(MTO)situations.ThesecondsituationistheEngineer-To-Order (ETO) situation. CTO refers to technical solutions (product or system)thathavealreadybeenstudiedindetailandthatarebased * Correspondingauthorat:UniversitédeToulouse,IMT-MinesAlbi,Centrede

GénieIndustriel,Alléedessciences,Albi,81000,France.

E-mailaddresses:abdourahim.sylla@mines-albi.fr,abdourahim.sylla@enit.fr

(A.Sylla),delphine.guillon@mines-albi.fr,d.guillon@estia.fr(D.Guillon),

elise.vareilles@mines-albi.fr(E.Vareilles),michel.aldanondo@mines-albi.fr

(M.Aldanondo),thierry.coudert@enit.fr(T.Coudert),laurent.geneste@enit.fr

(3)

onsomepredefinedcustomerrequirements.Mostofthetimein such cases,the technicalsolutions resultfrom theassembly of

standardsub-systemsandcomponents(ATOandMTOsituations)

thathavebeenentirelydefinedandfullycharacterized[10].Inthis

situation, many practitioners use configuration software as a

supportfortheelaborationofthetechnicalpart[11].Configuration softwareisaknowledge-basedsystemthat,givenakindofgeneric modelofthetechnicalsolutions,allowsthebiddertoinstantiateor customizeaspecificsolutionaccordingtothecustomer’s

require-ments [12,13,10]. Configuration systems allow reliable and

trustworthy technical solutions to be defined. But as a

conse-quence, andeven moresoin a biddingcontext,thecustomer’s

requirements must be fulfilled only with these standard

sub-systemsandrelevantassembliesasastandardoffer.

Whencustomerrequirementscannotbefulfilledbythiskindof standard offer, novel or adaptedtechnical solutions needtobe totallyorpartiallydefined,whichleadstoEngineering-To-Order (ETO)situations[14].Somecompaniesorsoftwareprovidersspeak of“light”ETO,whenstandardsolutionsalmostcompletelycover therequirementsandjustneedsmalladaptations,or“heavy”ETO,

when all standard solutions must be adapted and new ones

entirelydefined.ForanyETOsituation,thebiddersmayadopttwo differentapproachesfortechnicalsolutionelaboration.Thefirstis toperformafullydetaileddesign,whichimpliesstudyingindetail allthesub-systems,componentsandinterfacesthatmaybeapart ofatechnicalsolution.Withthisapproach,thecharacteristicsof thetechnicalsolutiontothebidareveryaccurateandcertain,but theresources,timeandeffortinvolvedareconsiderable[15,16].In contrast,thesecondapproachistoperforma pre-designofthe

technical solutions of the bid. Only the main decompositions,

characteristicsorworkingprinciplesforthetechnicalsolutionsare definedandestimated[17].Themainadvantageofthisapproachis thatitreducestheconsumptionofresources,timeandeffortwhen elaboratingthetechnicalsolutions.However,incontrasttothefirst

approach, the estimation of these technical solutions is more

impreciseanduncertainduetothelackofpreciseandcomplete knowledge[18,16].

GiventhetwopreviousCTOandETOsituations,ourconcerns are:

(i)toconsiderETOsituationswithaviewtoacceptingsome

non-standardcustomerrequirements,

(ii)to adopt a pre-design approach in order to reduce bidder workload,

(iii) to support and improve the elaboration of the technical

solutionwithadaptedconfigurationtechniquesdedicatedto CTO.

Inthisperspective,thegoalofthisarticleistodefineageneric knowledge-basedmodelfortheelaborationoftechnicalsolutions forbidsinbothCTOandETOsituations.Consideringasabasisa genericconfigurationmodelrelevanttoCTO,thekeycontributionof

this paper isto show howthis generic model canbeextended

towardsETOsituationsthankstovariousmodelingproposals.The modelingextensions relyonidentifyingthesetofnon-standard requirementsthatareacceptablefromthebiddingcompany’spoint ofview.Oncethisidentificationismadeandvalidated,thegeneric configurationmodelisupdatedwiththerelevantETOknowledge.In linewithmanyauthors,seeVareillesetal.[19]andFelfernigetal.

[10], we consider the configuration problem as a constraint

satisfactionproblem(CSP)andusethisframeworkformodeling. Weneedtopointoutthatourproposalsarenotonlydedicatedtothe biddingprocessandcanbeusedinotherdesignactivitiesaswell. Althoughthisproblemisquitecommonindesignactivities,theneed totakeintoaccountnon-standardbutacceptablerequirementsis muchmorecriticalinthebiddingprocess.Biddingcompanieshave

toanswer calls fortendersmoreandmore quicklywith solutionsthat fitthecustomer’srequirements(duedate,technicalsolution,cost, etc.),eveniftheserequirementsarenearthelimitsoftheirtechnical solutioncatalogs.Arealefforthastobemadeupstreamtodetermine whattechnicalsolutionsacompanyisabletoproducetominimize thepre-designtimewhilebiddingandmaximizetheconfidenceofa companyintheexecutionofitscommitmentsincaseofsuccess[9]. Inpractice,theimplicationsofthecontributionofthisarticle arethreefold:

(i)In general, for users of knowledge-based configuration

software, it enables them to use, with minor adaptations,

conventional configuration software dedicated to CTO (or

AMTO)forbothAMTOandETOindustrialsituations. (ii)In theparticularcase ofthebiddingprocess,itenables the

contractors(bidders):(a)toconsidermorebidopportunities andthusincreasetheirbusinessvolume,(b)tolimitthelossof resources, time and effort, especially in cases where their commercialoffersarenotacceptedbythecustomers. (iii)At the operationallevel, the person in charge of theoffer

definition is now allowed some leeway in respect of the

standard,whilstremainingwithintherigorofconfiguration software.

The restof the paper is organized as follows.In Section 2,

knowledge-basedconfigurationbackground,constraint

program-mingandgenericmodelingissuesrelevanttoCTOarepresented.In Section3,six requirementsand relevantextensionsof theCTO

generic model towards ETO are proposed and illustrated. In

Section 4, a synthesis of our proposals is made, leading to

discussionsandfutureresearch.Throughoutthepaperanexample dealingwithacranesystemconfigurationproblemillustratesthe proposals.Inthefinalversion,alinktoaconfigurationwebsitewill beprovidedinordertoshowthepropositions’interests.

2.ConfigurationbackgroundandETOissues

Inthissection,definitionelementsrelevanttotheconfiguration

problem for CTO technical systems are recalled. Secondly, the

ConstraintSatisfactionProblem(CSP)approachusedtoformalize itispresentedandexplained.Finally, theillustrativeexampleis introducedandmodeledasaCSP.

2.1.Productandsystemconfiguration

One of the first definitions of configuration activity was

providedbyMittalandFrayman[20],whodescribedconfiguration activityas“aspecialtypeofdesignactivity,withthekeyfeature thattheartifactbeingdesigned isassembledfromasetof pre-definedcomponentsthatcanonlybeconnectedtogetherincertain ways”.Theauthorsalsoconsiderthatacomponentischaracterized

by a set of properties and ports for connecting it to other

components.Thisdefinitionhasbeenadoptedanddiscussedby

manyauthors,especially,Soininen etal.[21],Sabin and Weigel [12], Aldanondo and Vareilles [22], Yang and Dong [23] and Felfernigetal.[10].

Frompreviousconfigurationproblemdefinitions,weconsider thefollowingonewiththekeyelementssummarizedasfollows: !Hypothesis:aproductisconsideredasasetofcomponents !Given:

(1) agenericarchitectureoftheproductthatdescribesafamily ofproducts,

(2) afixedsetofcomponentgroupsthatarealwayspresentin anyproduct,

(4)

(4) afixedsetofpropertiesthatcharacterizeeitheracomponent oraproduct,

(5) a setof constraints that restrict possiblecombinations of componentsand/orpropertyvalues,

(6) a set of customer requirements, where a requirement

correspondstheselectionofacomponentorapropertyvalue. !Objectives:Theconfigurationofaproductconsistsinfindingat leastonesetofcomponentsthatsatisfiesalltheconstraintsand thecustomerrequirements.

Anadaptationofthisproblem,definedforaCTOproductinthe contextofaCTOtechnicalsystemsconfigurationproblem,canbe

performed by substituting “product” and “component” with,

respectively, “technical system” and “sub-system” in the above definition.Withregardtothisadaptedproblemdefinition,onecan developaCTOtechnicalsystemsconfigurationmodel,whichmakes itpossibletoconfiguretechnicalsystemscomposedofasetof

sub-systems, considering one level of decomposition

(system/sub-systems).Thissingleabstractionlevelhypothesisisusuallysufficient ifweareconsideringapre-designcontextforbidders.However,as alreadynoticed byMittalandFrayman[20], Aldanondo etal.[24]and Felferniget al.[10],neither non-standard sub-systemsnor

non-standardintegrations betweensub-systems can beidentifiedor

selected toconfigureanon-standardtechnicalsystem.Configuration problemhypotheses requirestaying insidethe definition of the standardsolutionsetorstandardsolutioncatalog.

Therefore,ETOtechnicalsystemconfigurationcannotbedirectly

supported by a configuration model in line with previous CTO

hypotheses and definitions. Consequently, these configuration

definitionsandhypotheses,aswellasthegenericmodels,haveto beadaptedtocopewithETOsituations.Asfarasweknow,thereisno scientificworkdealingwiththisobjective.Althoughmanystudies havebeenmadeinthefieldofCTOknowledgemodeling–seefor example:[21,25] or[22] –muchfewerconcern ETOknowledge. However:[26,14,27,28]or[29]canbeconsulted.Whileeachofthese

papersis relevant to knowledgemodeling, theyconcern mainly

eitherCTOknowledgeor ETOknowledgeanddo notattemptto

bridgethegapbetweenthesetwomodelingcontexts.Inthisarticle, weextendtheCTOtechnicalsystemsconfigurationmodeltowards ETOinordertobeabletoconsidernon-standardbutacceptable customerrequirements.Theseadaptationsarethecore contribu-tionsgiveninSection3.Inthefollowing,theConstraintSatisfaction Problem(CSP)frameworkusedtomodeltheconfigurationproblem isrecalledandillustratedwiththecraneexample.

2.2.ConstraintSatisfactionProblem(CSP)

Within a CSP framework, a problem is defined as a set of

constraints (C), which state relations between the problem’s

variables(V),whereeachvariable(vi

e

V)cantakeavalueonlyina

finitedomain(Di)[30].ReferringtotheCSPdefinitionabove,Sabin

andSabinandWeigel[12],Soininenetal.[21]andothers(see[10])

have shownthat the productconfigurationproblem defined in

Section2.1canbemodeledwiththisCSPframework.

Weconsiderthesameforsystemsasfollow.Eachsub-system groupandeachpropertyisassociatedwithavariable.Aspecific sub-systemsolutionofasub-systemgrouporaspecificvalueofa

property corresponds to one value in the domain of the

corresponding variable. The constraints represent the allowed

combinationsofsub-systemsand/orpropertyvalues.Inordertobe abletomodeloptionalsub-systems,DynamicorconditionalCSP (DCSP),introducedbyMittalandFalkenhainer[31],canbeused. WithintheDCSPframework,thenotionsofactive/inactivevariables and active/inactiveconstraints areadded totheCSPframework. Variablesandconstraintsarepartitionedintoinitiallyactiveand initiallyinactive sets.Referring totheconfigurationproblemof Section2.1,thesub-systemsgroupsthatarealwayspresentina

configurable system are associated with the initially active

variableswhereastheoptionalsub-systemsgroupsareassociated withtheinitiallyinactiveones.Theactivationofinactivevariables orconstraintsisperformedusingactivityconstraintsthatcanadd tothecurrentproblemthevariablesandconstraintsthatwerenot initiallyactive.Constraintscanalsobeusedtolinksub-systemsto someindicators,e.g.performance,cost,readinessorconfidence,as shownin[32,33].Thisassessmentissuewillnotbeconsideredin thisarticle.

Inthis article,weusetheCSPframeworktoextendtheCTO genericmodeltowardsETO.InSection3,themainissuesdealing withCTOandETOarediscussedandtherelevantextensionsare shownandillustratedonasimpleexample.

2.3.Illustrativeexample:acranesystem

Asan illustrativeexample, weconsider avery simple crane systemcomposedofonlytwosub-systemsthatarealwayspresent inanyconfiguration(TowerandJib)andanoptionalsub-system (Operatorbasket).Thisexampleisinspiredbyrealsituations.In the interest of clarity and understanding, we have voluntarily simplifiedthereal-lifesituationsintherestofthepaper. 2.3.1.Cranemodel

Atthesub-systemlevel,astheconfigurationmodelstructureis similarforallthesub-systems,onlythemodelrelevanttothejibis detailed in Fig.1. The Jib sub-system is characterized by two properties associated with two variables: (i) length of the jib (notedLength,withtwopossiblevalues“4”or“8”meters)and(ii) stiffnessofthejib(notedStiffness,withtwopossiblevalues,“low” for low-stiffnessor “strong” for strong-stiffness). A sub-system

(5)

groupvariablenotedJib_Sol(withtwopossiblevalues“Ji_So_1” and“Ji_So_2”)identifiesjibtechnicalsolutions.Theconstraintcc1 allowstwopossiblecombinationsofthelengthandthestiffnessof thejibandindicatesthecorrespondingjibsub-systemsolution. According tocc1, neitheran “8mlow stiffness jib” nora “4m strongstiffnessjib”areallowedbythestandard.

Atthesystemlevel,theintegrationofthesub-systemshastobe takenintoaccount,asshowninFig.2.

Theconfigurationmodelshowsfivevariables:

(1)threevariablesassociatedwiththethreesub-systems: Thetwosub-systemsthatarealwayspresentinanysolution:

Jib_Sol,withtwopossiblesolutions“Ji_So_1”and“Ji_So_2”,corresponding tothesub-systemgroupfortheJib,

Tower_Sol,withtwopossiblesolutions“To_So_1”and“To_So_2”, correspondingtothesub-systemgroupfortheTower.

Thesubsystemthatisoptional:

Basket_Sol,withtwopossiblebasketsolutions,small“Ba_So_1”andlarge “Ba_So_2”,correspondingtothesub-systemgroupfortheBasket. (2)onevariableassociatedwiththesystempropertythatcharacterizesifthe

optionalsub-systemispresent:

Basket_Exist,withtwopossiblesolutions“yes”and“no”, (3)onevariableassociatedwiththesystem:

Crane_Sol,withthreepossiblevalues“Cr_So_1”to“Cr_So_3”, correspondingtothefinalCranesystem,

Threeconstraints,twoofcompatibilityandoneofactivation, link thesesub-systemgroups,propertyandsystem, togetherin ordertodescribethefamilyofsystemsproposedinthestandard: (1)thecompatibilityconstraintcs1describesthepossiblecombinationofajib

andatowerwithpossiblerelevantcranesolutions:

“Ji_So_1”and“To_So_1”arecompatiblewith“Cr_So_1”,while“Ji_So_2” and“To_So_2”arecompatiblewith“Cr_So_2”and“Cr_So_3”(whichonly differbythepresenceofthesub-systembasket).

(2)Thecompatibilityconstraintcs2linksthevariableCrane_solwiththe propertyBasket_exist.Cs2allowsselectionoftheappropriatecranetechnical solution.

“Cr_So_1”and“Cr_So_2”arenotcompatiblewithabasket,while“Cr_So_3” is.

(3)Theactivationconstraintas1enablescontroloftheexistenceoftheoptional sub-systemgroupbasket,Basket_Sol,accordingtothepropertyvalueof Basket_Exist.

2.3.2.CTOillustrativescenario

Asanillustrativescenariooftheconfiguration,letusconsider thefollowingcustomerrequirements:“Weneedaheavycapacity

jib-crane with a large operator basket.” This requirement is

translatedintothefollowinginputs“Acranewithastrongstiffness jibandalargeoperatorbasket”:

Input1: stiffnessofthejibequalsstrongischosen )Stiffness=“strong”

AstheStiffnessvariablehasbeenreduced,theconstraintscc1

and cs1 are filtered. Cc1 implies that (1) the length equals 8

(length=“8”) and (2) that the jib solution equals Jib_Sol_2

(Jib_Sol=“Ji_So_2”). Cs1 implies that thetower solution equals

To_So_2 (Tower_Sol=“To_So_2”) and therefore that the crane

solutionis either Cr_So_2or Cr_So_3 (Crane_Sol=“Cr_So_2” or Cr_So_3”).

Input2: thevalueyesfortheoptionalsub-systembasketischosen )Basket_Exist=“yes”

Asthisvariablehasbeenvaluated,theactivityconstraintas1 activatesthesub-systemgrouprelativetothesub-systembasket (Basket_sol)andtheconstraintcs2isfiltered.Cs2impliesthatthe cranesolutionequalsCr_So_3(Crane_Sol=“Cr_So_3”).

Input 3:

thevalueBa_So_2fortheoptionalbasketischosenasitcorrespondstoa largeone

)Basket_Sol=“Ba_So_2”

Oncethisvariablehasbeenvaluated,nothingelsecanhappen andtheconfigurationprocessisover.AsaresulttheCTOtechnical

solutionproposed tothecustomercorrespondsto Cr_So_3and

gathersthethreesub-systems:Ji_So_2,To_So_2andBa_So_2.For sakeofclarity,theoptionalstandardsub-system(Operatorbasket) isomittedintherestofthepaper.

2.4.Synthesis

In this section, Configuration-To-Order basics have been

recalledand theconstraintmodelingframeworkusedtomodel

theproblemhasbeenpresentedandillustratedwithanexample.

Finally, some issues that differentiate Engineering-To-Order

requirements from configure-to-order requirements have been

introduced.Thenextsectiondetailsthesedifferencesandproposes modelingextensions.

(6)

3.Proposals:ETOconfigurationproblemandmodelupdates Inthis section,we firstpresent and discussthemain issues dealingwithCTOandETOassembling.Weproposeandillustrate sixconstraint-basedmodelingextensionsinordertohandleETO situationswithconfigurationtechniques.

3.1.MainissuesinCTOandETOgathering

In the following sub-sections, we first identify, define and illustratesixkeyrequiredextensionstobridgeCTOandETO.We

thendiscussthemanddeducesomeconsequencesdealingwith

configuration knowledge management for ETO situations. We

finallyproposesomedefinitionelementsforCTO-ETO

configura-tion.

3.1.1.CTO–ETOdifferences:sixkeyrequirements

The study of various Engineering-To-Order (ETO) industrial situationsandmanydiscussionswithconfigurationpractitioners

of the configuration community have led us to identify and

proposesixcasesthatbridgethegapbetweenCTOandETOgeneric modeling.Eachofthesecasescorrespondstorealsituationsthat anybiddingcompanymayface.Foreachofthem,aspecifickindof customerrequirementcannotbefulfilledbystandardsub-systems

and CTO system modeling. Two typesof cases are considered:

thosethatarerelevanttosub-systemproperties(casesfrom1to3) andthosethatarerelevanttosub-systemsthemselves(casesfrom 4to6).Wewanttowarnthereaderthatthesetwotypesofcases

have common roots which induce similarities. We could have

proposed more abstract requirement definitions with more

abstract modeling extensions. But this would have required

abstractdefinitions and extensions plus instantiations for both

property and sub-system levels. We choose to promote easy

understanding, even if it may be a little longer, rather than

genericitythatcouldbemuchhardertofollow.Wethereforekeep thesixrequirementsthatareshowninFig.3.Allofthemareshown inFig.3.InFig.3thatdepictsthesixcases,thehighesthorizontal

flow shows CTO configuration that respects all the standard

definitions from left toright: (i) standard property values, (ii) standardpropertyvaluecombinations(arrowthatidentifies sub-systemsolution),(iii)standardsub-systemsolutions,(iv)standard

sub-system solution integrations (arrow that identifies system

solution)and(v)standardsystemsolutions.Lowestlevelflowsand

associated arrows situate the six ETO non-standard cases that

requireextensions.Thesesixcasesaredefinedasfollows:

!Case 1: non-standard combination of standard property

valuesthatleadstoanon-standardsub-systemsolution.In

thisfirstcase,inordertofulfillthecustomer’srequirements,the valuesofatleasttwostandardproperties,whichwerepreviously

incompatible,havetobechosensimultaneously.Forinstance,in thecraneexample,ifweconsiderthesub-systemjibpresented inFig.1,sucharequirementcouldbe“A4metersstrongstiffness jibisrequired”,whichisnotpossiblewiththecurrentmodel.

!Case 2: non-standard property values that lead to a

non-standard sub-system solution. In this second case, the

customerrequiresapropertyvaluewhichisoutsidethestandard values.Forinstance,inthecraneexample,ifweconsiderthe sub-systemjibpresentedinFig.1,sucharequirementcouldbe“A6m lowstiffnessjibisrequired.”,whilethevalue“6”isoutsidethe standardlengthpropertyvaluesandnotpresentinthecurrent model.

!Case3:non-standardpropertythatleadstoanon-standard

sub-systemsolution.Inthisthirdcase,thecustomerrequiresa

new property which does not belong to the standard. For

instance, inthecraneexample,ifweagainconsiderthe sub-systemjibpresentedinFig. 1,sucharequirementcouldbe“A4m lowstiffnessjibwithaU-shapesectionisrequired”.Thenewand non-standardproperty“sectionshape”,undefinedinthecurrent model,needstobeaddedtotheconfiguredsystemwithitsvalue “U-shape”.

!Case 4: non-standard integration of standard sub-system

solutionsthatleadstoanon-standardsystemsolution.Inthis fourth case, thecustomer’s requirementslead totheneed to integratestandardsub-systemsolutionswhichhaveneveryet beenintegratedtogether.Forinstance,inthecraneexample,if weconsiderthesub-systemsJibandToweraspresentedinFig.2, sucharequirementcouldcorrespondtotheneedtointegratea Jib“Ji_So_1”andatower“To_So_2”,whichisnotpossiblewith thecurrentmodel.

!Case 5: non-standard integration of standard and

non-standardsub-systemsolutionsthatleadstoanon-standard

system solution. In this fifth case, very close to case 4, the customer’srequirementsleadtotheneedtointegratestandard

sub-system solutionswithnon-standard ones(resultingfrom

cases1,2,3).Forinstance,inthecraneexample,ifweconsider the sub-systemsJib andTower as presentedin Fig.2,such a requirementcouldleadtotheneedtointegrateanon-standard Jib,correspondingtothefollowingrequirement:“A4mstrong stiffnessjibisrequired.”,andastandardtower“To_So_2”,which isnotpossiblewiththecurrentmodel.

!Case6:non-standardsub-systemthatleadstoanon-standard systemsolution.Inthissixthcase,thecustomer’srequirements leadtotheneedforanewsub-systemwhichdoesnotbelongto

the standard sub-systems catalog. Consequently, it must be

designed or boughtand then integrated. For instance, in the

craneexample,such a requirement couldbe“A rotationstop

control sub-system that allows maximum angle+/# 10$ is

required”, with the new non-standard sub-system “rotation

stop”undefinedinthecurrentmodel.

(7)

3.1.2.Discussionofrequirementsandknowledgemodeling consequences

Foreachofthesecases,thebiddingcompanyhasneverbefore

carried out the engineering work that would enable him to

proposeanon-standardsolutiontothecustomer.Thisdoesnot

mean thatsuchsub-systemscouldnot bedeveloped,produced

andintegratedwiththesecharacteristics.Itsimplymeansthatat thetimewhenthestandardsolutionsetorcatalogwasdefined,

these combinations of properties or sub-systems were not

studied. Mostof the time,this is because it was thoughtthat

the standard catalog represents the vast majority of the

customers’requirements.Ascustomersneedandwant

increas-ingly personalized products, many companies more and more

frequentlyhavetoproposenon-standardorout-of-rangesystem solutionsinordertofulfillnon-standardrequirements.Ofcourse,

a bidding company cannot simply accept any requirement, so

each one has to decide which non-standard requirement is

acceptable.Thisinducesathree-levelrequirement characteriza-tionscale:standard,non-standardacceptableandnon-standard non-acceptable.

In theintroduction,we spokeof “light”versus“heavy” ETO.

With the proposed cases, we can slightly refine “heavy ETO”

characterization as: (i) Case 3 “ETO heavier”than Case 2 “ETO heavier”thanCase1and(ii)Case6“ETOheavier”thanCase5“ETO heavier”thanCase4.Furthermore,thesixpreviouscasescanof

course be combinedin manyways, enforcing the “heavy” ETO

characterization.

As this problem is increasingly encountered in the bidding process and referstoETOsituations,ourgoal istoextend CTO constraintconfigurationmodelstowardsETOinordertobeableto consider thesix previouscasesasnon-standardbut acceptable customer’srequirements.

Before modeling proposals, an important and critical issue dealingwithknowledgemodelingandcodinginconfigurationfor CTOandETOsituationsmustbediscussedandclarified.

In Configure-To-Order situations, the product knowledge

necessaryfortheconfigurationsoftwareset-upisdefinedbyan

expertteamthatusuallyincludesexperiencedpeoplefromthe

sales, manufacture,anddesigndepartments. Generally

speak-ing,theseexpert teamstalkandreach a compromiseabouta

standardofferdefiningwhatcanbedesigned,manufacturedand

put onthe market. Then the configuration software isset-up

accordingtothisstandardofferandthebiddermustrespectthis standard.

In Engineer-To-Ordersituations,a standard offer is always

present,buttheseexpertteamsmustalsodecideonthe

non-standardbutacceptablerequirements.Thismeans,withrespect topreviouscases,decidingwhichofthefollowingnon-standard

aspectscanbeaccepted:(i) combinationofstandardproperty

values, (ii) property values (iii) property, (iv) integration of standardsub-systemsolutions,(v)integrationofstandardand

non-standard sub-system solutions and (vi) sub-system. The

examples that illustrate each extension willassume that the

non-standard but acceptable requirements are those that

illustrate the case description of Section 2.4. Furthermore,

when such non-standard requirements are considered, we

assume that it is the responsibility of the bidding company

expertteamtoconsider theirfeasibility,i.e.theirabilitytobe developedtechnicallyandeconomically[34].Itisimportantto notethat(1)itisnotalwayseasytoidentifywhichpotentially

non-standardrequirementsmayberequiredbycustomersorto

know how to evaluate their feasibility a priori and (2) the

evaluationofthisfeasibilityreliesontheskillsandexpertiseofthe expertteamanditsownsubjectivepointofview.Thismeansthat

the knowledge set up in the configuration software will not

containanyconstraintthatcanaffectnon-standardbidderchoice. Forexample,whenconfiguringajibsub-system,ifanon-standard

butacceptablerequirementmeansthatanewproperty(case3)

can be added, the bidder can add whatever (s)he wants as a

property. (S)he can add “section shape” but also “color” or

whateverotherpropertyisdeemednecessary.Oncethesystemis

configured with all these non-standard specificities, if the

customeracceptstheoffer,alltherelevantengineeringactivities

mustbeachievedinordertodefine,manufactureandassemble

the non-standard system solution. Then if this new system

solutionprovides satisfaction tobothcustomerand bidder, the knowledgerelevanttothis non-standardsolutionwillbe input

into the configuration and, as a result, this non-standard

descriptionwillbecomeastandardone.

3.1.3.TowardsadefinitionoftheCTO-ETOConfigurationProblem

Definition elementsfor CTO-ETO system configuration

prob-lems,which highlightthenotion ofstandard and non-standard

specificities, cannow bederived from theproduct and system

definitionofSection2.1asfollow.

!Hypothesis: a technicalsystem is consideredasa setof sub-systems

!Given:

(1) a genericarchitecture that representa familyof standard technicalsystems

(2) afixed setof standardsub-systemgroupsthatarealways presentinanytechnicalsystem,

(3) afixedsetofstandardsub-systemgroupsthatareoptionalin technicalsystems,

(4) afixedsetofstandardpropertiesthatcharacterizeseithera standardsystemorastandardsub-system,

(5) a setof constraintsthat restrict possiblecombinations of standardsub-systemsand/orstandardpropertyvalues,

(6) a set of customer requirements, where a requirement

corresponds toa selection of a sub-systemor a property value.

!Given additional features that will lead to the ETO system

solutions:

non-standardcombinationofstandardpropertyvalues, non-standardpropertyvalues,

non-standardproperties,

non-standardintegrationofstandardsub-systemsolutions,

non-standard integration of standard and non-standard

sub-systemsolutions,

non-standardsub-system.

!Objectives:Theconfigurationofatechnicalsystemconsistsin

finding at least one set of sub-systems (standard or

non-standard) thatsatisfiesalltheconstraintsand thecustomer’s requirements.

3.2.ExtensionofCTOconfigurationmodeltowardsETO

In this section, we present constraint-based modeling

extensions that fulfill the previous definition of a CTO-ETO

configurationproblem.EachofthesixpreviouslyidentifiedETO casesisconsideredseparately.Foreachone,firsttheextensionof

theknowledge-basedmodelisdescribed;secondly,theimpacts

on the constraint-based model are presented and illustrated

using the crane example. A first sub-section deals with the

requirementsrelevanttothesub-systempropertiesandasecond

sub-sectionaddressesthoserelevant tothesub-systems

(8)

3.2.1.StandardandNon-standardPropertiesleadingtoNon-standard Sub-systems

Case 1: Non-standard combinations of standard property

values.

Modelextension.

In order to allow some combinations of standard property

valueswhichwerenotpermittedbythestandardoffer,weneedto

broaden the model by linking non-standard combinations of

standardpropertyvaluestoasub-systemgroup.Intermsof

sub-system deductions, these non-standardvaluecombinations are

onlycompatiblewithanon-standardsub-systemsolution. Therefore,theconstraint-modelextensionsconsist inadding twoelements:

(i) anon-standardsub-systemvalueinthedomainofthevariable sub-system,

(ii)asmanynon-standardconstrainttuplesasneededtolinkthe non-standardcombinationsofstandardpropertyvaluestothe

newnon-standardsub-systemvalue.

Craneexample.

TheconfigurationmodelpresentedinFig.4belowdepictsan exampleoftheadditionofonenon-standardacceptable combina-tionoftwostandardpropertyvalues.Thisconfigurationmodelis derivedfromthegenericCTOjibconfigurationmodelpresentedin Fig. 1.Inthiscase,thenon-standardacceptablerequirement“A4m strongstiffnessjibisrequired”needstobetakenintoaccount.In ordertodoso:

(i) thenon-standardjibsub-systemsolutionnoted“Ji_So_NS_AC” isaddedtothedomainofthevariableJib_Sol.

(ii)this new value is linked to the non-standard acceptable

combination(4m,strong)asshowninFig.4.SeelineN$3of

constraintcc1.

Theterm“Ji_So_NS_AC”isusedtoenablethebidderstoknow thatthissub-systemJibsolutionisNon-Standard(NS)andresults fromanon-standardAcceptableCombinationofstandardproperty values(AC).Referringtocase1mentionedinsub-Section2.4,this modificationallowsacranewitha4-mjibwithastrongstiffnessto

nowbeconfigured.

Case2:Non-standardpropertyvalues.

Modelextension.

Inordertodefinesub-systemsolutionswithcharacteristicsthat exceedthedomainofthestandardpropertyvalues,non-standard propertyvaluescanbeaddedtothedomainsof theproperties.

Thesenon-standardvaluescorrespondto“non-standard

accept-able”requirements.Intermsofsub-systemsolutiondeductions,

these non-standard values are only compatible with a

non-standardsub-systemsolution.

Therefore,theconstraint-modelextensions consistinadding threeelements:

(i) non-standard values to the domain of some standard

properties,

(ii)anon-standardsub-systemsolution,

(iii) constrainttuplesthatlinkthenon-standardpropertyvalues andthenon-standardsub-systemsolution.

Craneexample.

TheconfigurationmodelpresentedinFig.5belowdepictsan exampleofadditionofnon-standardnumericalpropertyvaluesto

thedomainofa standard property.Thisconfiguration modelis

derivedfromthegenericCTOjibconfigurationmodelpresentedin Fig.1.Thedifference is that non-standardpropertyvalues(any valuebetween“4”and“8”meters)areaddedtothedomainofthe lengthofthejib(see“]4,8[m”inFig.5).Allothervaluesoutside [4,8]arenotacceptablerequirements.Inordertodoso:

(i) thenon-standardvalues“]4,8[m“areaddedtothedomainof thepropertyjiblengthasnon-standardacceptable require-ments,

(ii)the non-standard sub-system solution, “Ji_So_NS_AV”, is

addedinthedomainofthesub-systemgroupJib,

(iii) Thenon-standardlengthsarelinkedwithnewtuplestothe twopossiblevaluesof thejibstiffness(“low”and “strong”) andthecorrespondingpreviousnon-standardjibsub-system solutionisnoted“Ji_So_NS_AV”(seelinesn$3andn$4ofthe

constraintcc1inFig.5).

Theterm“Ji_So_NS_AV”isusedtoenablethebidderstoknow that this sub-systemsolution is Non-Standard(NS) and results

froma non-standardAcceptable Valueinone oftheproperties

(AV).Referringtocase2mentionedinsub-Section2.4,byusing thismodificationacranewitha6-mjibwithalowstiffnesscan

nowbeconfigured.

Case3:Non-standardproperty

Modelextension.

Inordertodefinespecificsub-systemsolutionswhichrequirea specificdescription,somenon-standardpropertiescanbeaddedto

the sub-system configuration model. The addition of a

non-standard property corresponds to “non-standard acceptable”

requirements. In terms of sub-system solution deductions, a

non-standard property can only be compatible with a

non-standardsub-systemsolution.

Therefore, theconstraint-model extensions,relevant toeach non-standardproperty,consistinaddingsixelements:

(i) onevariabletocapturethenon-standardpropertyname, (ii)onevariabletocapturethenon-standardpropertyvalue,

(9)

(iii) one variable to capture the requirement relevant to the

existence (existence flag) of the two previous variables

relevanttonon-standardpropertydescription,

(iv)one activity constraint that activates the two previous

variables,

(v)one non-standardsub-systemsolutionassociatedwith this non-standardproperty,

(vi)onecompatibilityconstraintlinkingtheexistenceflagandthe sub-systemsolution.

Craneexample.

TheconfigurationmodelpresentedinFig.6belowdepictsan

example of the addition of a non-standard property. This

configuration model is derived from the generic CTO jib

configuration model presented in Fig. 1. It shows how a

non-standardpropertycanbeaddedtothemodeltomeetaspecific

customerrequirement.Inordertodoso:

(i)onevariable,notedNS_prop_name,isaddedwithasymbolic domainallowingthecaptureofanykindofcharacterstring, (ii)onevariable,notedNS_prop_value,isaddedwithasymbolic domainallowingthecaptureofanykindofcharacterstring,

(iii)onevariable,notedNS_prop_exist,isaddedwithaBoolean domain“yes”or “no”allowingthecapture oftheexistence requirementofthenon-standardproperty,

(iv)one activity constraint ac1,

{NS_prop_ex-ist=“yes”}=>activationof{NS_prop_name,NS_prop_value}

(v)the non-standard sub-system solution, “Ji_So_NS_AP”, is

added in thedomainof thesub-systemgroupJib, variable

Jib_Sol

(vi)onecompatibilityconstraintcc2,thatassociatestheexistence

flag and sub-system solution (NS_prop_exist, Jib_Sol) and

showsthatthepositiveflagcanonlybeassociatedwiththe

non-standardsub-system“Ji_So_NS_AP”.

Theterm“Ji_So_NS_AP”isusedsothatthebidderswillknow that this sub-systemsolution is Non-Standard(NS) and results fromanon-standardAcceptableProperty

(AP). Referring to case 3 mentioned in Section 2.4, this

modificationallowsacranewitha 4-mjibwitha lowstiffness anda “U_shape”tonowbeconfigured:(1)Jib_Length=“4”,(2) Jib_Stiffness=“low”, (3) NS_prop_exist=“yes”, (4)

NS_prop_-name,=“jib shape”, (5) NS_prop_value, “U shape”, (6)

Jib_-Sol=“Ji_So_NS_AP”. Fig.5. Non-standardpropertyvalues.

(10)

Combiningnon-standardETOcasesatsub-systemlevel Thethreepreviouscasescanbeassociated.Thisallows

non-standard sub-systems tobedefined and configured, which can

potentiallyassembleastandardCTOofferwithnon-standard:case

1 orcase 2 or case 3 orcases 1 and 3, orcases 2 and 3. Two

combinationsare missing non-standardcase 1and 2 and

non-standard cases 1, 2 and 3, because as soon as there is a

non-standard property value (case 2),this requires a non-standard

combination of property values (case 1). Sub-system solutions

relevanttocases1and3arenotedwith“NS_AC_AP”whilethose relevanttocases2and 3arenotedwith“NS_AV_AP”.Itisvery importantforthebidderstoeasilyunderstandwhythesub-system isnon-standard.Indeed,byknowingtherootcauses,thebidders

canbetterestimatethetimeneededtodesign suchanew

sub-systemandassessthecostindicators. Craneexample.

TheconfigurationmodelpresentedinFig.7belowshowsthese fivepossibilitiesfor non-standardjibsub-systemsolutions.The initialstandardsolutionJi_So_1andJi_So_2aremergedwithfive non-standardJibsolutionsthatare:

(i)Ji_So_NS_AC”forcase1 (ii)“Ji_So_NS_AV”forcase2 (iii)“Ji_So_NS_AP”forcase3

(iv)“Ji_So_NS_AC_AP”forcases1and3 (v)“Ji_So_NS_AV_AP”forcases2and3

AllmodelingextensionsofFigs.4–6aremergedinFig.7.The configurationprocesscanstart eitherbyselecting thestandard valuesforthestandardpropertyorbyselectingnon-standardones. 3.2.2.Standardandnon-standardsub-systemsleadingto non-standardtechnicalsystems

Case4: Non-standard integrationof standard sub-system

solutions.

Modelextension.

Thiscaseisverysimilartocase1,dealingwithnon-standard combinationsofpropertyvalues.Inordertoallowtheintegration

of standard sub-systems which were not permitted by the

standard offer, we needto broadenthe model bylinking

non-standard integrations of standard sub-system solutions to the

technical system. The addition of a non-standard integration

correspondstoa“non-standardacceptable”requirement.Interms

of technicalsystem deductions, thesenon-standardsub-system

integrationsare onlycompatible witha non-standardtechnical solution.

Therefore,theconstraint-modelextensions consistinadding twoelements:

(i)anon-standardtechnicalsystemsolutionvalueinthedomain ofthetechnicalsystemvariable,

(ii)asmanynon-standardconstrainttuplesasneededtolinkthe non-standardintegrationsofstandardsub-systemstothenew non-standardtechnicalsystemsolution.

Craneexample.

TheconfigurationmodelpresentedinFig.8belowdepictsan exampleoftheadditionofonenon-standardacceptable

integra-tion of two standard sub-system solutions. This configuration

modelisderivedfromthegenericCTOcraneconfigurationmodel presented in Fig. 2. In this case, the non-standard acceptable technicalrequirement“WeneedtointegrateTo_So_2withJi_So_1” needstobetakenintoaccount.Inordertodoso:

(i)anon-standardcranesystemsolutionnoted“Cr_So_NS_AI”is addedtothedomainofthevariableCrane_Sol.

(ii)this new value is linked to the non-standard acceptable

integration thanks to the addition of the non-standard

constraint tuple (To_So_2, Ji_So_1) of the constraint cs1

(To_Sol,Jib_Sol,Crane_Sol),asshowninlinen$3ofFig.8.

Theterm“Cr_So_NS_AI”isusedtoenablethebidderstoknow thatthistechnicalsolutionisNon-Standard(NS)andresultsfroma

non-standard Acceptable Integration of standard sub-systems

solutions(AI).Referringtocase4mentionedinSection2.4,this

modificationmeans that a cranecomposed of thesub-systems

To_So_2andJi_So_1cannowbeconfigured.

Case 5: Non-standard integration of standard and

non-standardsub-systemsolutions.

Modelextension.

Thiscaseisverysimilartocase4,theonlydifferencebeingthat nowanon-standardsub-systemsolution(resultingofcases1,2

and/or 3) can also be integrated to provide a non-standard

technicalsystemsolution.Intermsoftechnicalsystemdeduction,

(11)

asincase4,thesenon-standardintegrationsofstandardand

non-standard sub-systems areonlycompatible withanon-standard

technicalsolution.

Therefore, theconstraint-modelextensionsconsistin adding

twoelements:

(i)anon-standardtechnicalsystemsolutionvalueinthedomain ofthetechnicalsystemvariable,

(ii)asmanynon-standardconstrainttuplesasneededtolinkthe non-standardintegrationsofstandardandnon-standard sub-systemstothenewnon-standardtechnicalsystemsolution. Craneexample.

TheconfigurationmodelpresentedinFig.9belowdepictsan exampleoftheadditionofonenon-standardacceptableintegration ofastandardwithanon-standardsub-system.Thisconfiguration modelisderivedfromthegenericCTOcraneconfigurationmodel presented in Fig. 2. In this case, the non-standard acceptable technicalrequirement“WeneedtointegrateTo_So_2witha4m strongstiffnessjib”needstobetakenintoaccount.Inordertodoso: (i)anon-standardcranesystemsolutionnoted“Cr_So_NS_NI”is

addedtothedomainofthevariableCrane_Sol.

(ii)this new value is linked to the non-standard acceptable

integration by means of the addition of the non-standard

constrainttuple(To_So_2,Ji_So_NS_AC)oftheconstraintcs1 (To_Sol,Jib_Sol,Crane_Sol)asshowninlinesn$4and5ofFig.9.

Theterm“Cr_So_NS_NI”isusedtoenablethebidderstoknow thatthistechnicalsolutionisNon-Standard(NS)andresultsfroma

Non-standard acceptable Integration of standard and

non-standardsub-systemssolutions(NI).Referringtocase5mentioned inSection2.4,thismodificationmeansthatacranewithastandard

sub-system solution To_So_2 and non-standard sub-system

solutionJi_So_NS_ACcannowbeconfigured.

Case6:Non-standardsub-system.

Modelextension.

Thiscaseisverysimilartocase3,whichdescribesaddinga non-standardproperty.Inordertodefinespecificsystemsolutionsthat

requireaspecificnewfunction,somenon-standardsub-systems

canbeaddedtothesystemconfigurationmodel.Theadditionofa

non-standardsub-systemcorrespondsto“non-standard

accept-able”requirements.Intermsofsystem-solutiondeductions,asin cases4and5,anon-standardsystemcanonlybecompatiblewitha non-standardtechnicalsolution.

Therefore, the constraint-model extensions relevant to each non-standardsub-systemconsistinaddingsixelements:

(i)onevariabletocapturethenon-standardsub-systemname, (ii)onevariabletocapturethenon-standardsub-system

descrip-tion,

(iii)one variable to capture the requirement relevant to the

existence (existence flag) of the two previous variables

relevanttonon-standardsystemdescription,

(iv)one activity constraint that activates the two previous

variables,

(v)onenon-standardsystemsolutionassociatedwiththis

non-standardsub-system,

(vi)onecompatibilityconstraintlinkingtheexistenceflagandthe systemsolution.

Craneexample. Fig.8.Non-standardintegrationofstandardsub-systemsolutions.

(12)

TheconfigurationmodelpresentedinFig.10belowdepictsan

example of the addition of a non-standard sub-system. This

configuration model is derived from the generic CTO crane

configurationmodelpresentedinFig.2.Isshowshowone non-standardsub-systemcanbeaddedtothemodeltomeetaspecific customerrequirement.Inordertodoso:

(i)onevariable,notedNS_subs_name,isaddedwithasymbolic domainallowingthecaptureofanykindofcharacterstring capturingthetypeofthesub-system,

(ii)onevariable,notedNS_subs_desc,isaddedwithasymbolic domainallowingthecaptureofanykindofcharacterstring capturingthedescriptionofthesub-system,

(iii)onevariable,notedNS_subs_exist,is addedwithaBoolean

domain “yes” or “no” allowing capture of the existence

requirementofthenon-standardsub-system,

(iv) oneactivityconstraintas2,{NS_subs_exist=“yes”}=> activa-tionof{NS_subs_name,NS_subs_desc}

(v) thenon-standardsystemsolution,“Cr_So_NS_AS”,isaddedin thedomainofthecranesystem,variableCrane_Sol

(vi)one compatibility constraint cs2, which associates the

existenceflagandsystemsolution(NS_subs_exist,Crane_sol) andshowsthatthepositiveflagcanonlybeassociatedwith

thenon-standardsub-system“Cr_So_NS_AS”.

Theterm“Cr_So_NS_AS”isusedtoenablethebidderstoknow thatthissystemsolutionisNon-Standard(NS)andresultsfroma

non-standard Acceptable Sub-system (AS). Referring to case 6

mentioned in Section 2.4, this modification allows a crane

witha4-mjibwithalowstiffnessanda“rotationstop”additional

sub-system to now be configured: (1) Jib_Length=“4”, (2)

Jib_Stiffness=“low”, (3) NS_subs_exist=“yes”, (4)

Fig.10.Non-standardsub-system.

(13)

NS_subs_name,=“rotation stop”, (5) NS_subs_desc, “Max+/# 120$

”,(6)Crane_sol=“Cr_So_NS_AS”.

Combiningnon-standardETOcasesatsystemlevel

Aswiththesub-systemlevel,themodelsofthethreeprevious

cases can be associated. The resulting model gathers the

configurationmodelsandpotentiallyallowsastandardCTOoffer tobeassembledwithnon-standard:case4orcase5orcase6or cases4and6orcases5and6.Twocombinationsarealsomissing

non-standard case 4and 5 and non-standardcases 4,5 and 6,

becauseassoonasthereisanon-standardsub-systemsolution (case 5),this requiresanon-standardintegrationofsub-system solutions(case4).Systemsolutionsrelevanttocases4and6are notedwith“NS_AI_AS”whilethoserelevanttocase2and3are

notedwith“NS_NI_AS”.

Craneexample.

TheconfigurationmodelpresentedinFig. 11belowshowsthese five possibilities for non-standard crane system solutions. The initialstandardsolutionCr_So_1andCr_So_2aremergedwithfive non-standardcranesolutions,whichare:

- “Cr_So_NS_AI”forcase4 - “Cr_So_NS_NI”forcase5 - “Cr_So_NS_AS”forcase6

- “Cr_So_NS_AI_AS”forcases4and6 - “Cr_So_NS_NI_AS”forcases5and6

AllmodelingextensionsofFigs.8–10aremergedinFig.11. 4.Conclusion

Answeringacallfortenderhasbecomearealchallengetoday, withbiddersandcompanieshavingtocopefirstwithaverytight timeperiodbetweenthedateofthecallandtheclosingdateforthe

application, and secondly, with ever more specific customer

requirements,whicharenotcompletelywithintheircapabilities

and need some engineering work. Therefore, companies that

nowadays runConfiguration-to-Order(CTO) softwaremustdeal

more andmore frequentlywithout-of-rangerequirementsthat

lead to non-standard solutions. This pushes them towards

Engineer-to-Order (ETO) situations. In this article,we focus on the technical part (bill of materials of systems grouping

sub-systems) of the bid solution. As a consequence, we propose a

genericknowledgemodelsupportingtheelaborationoftechnical solutionstoabidforbothCTOandETOsituations.Inordertodoso,

wehavebasedourproposalsontheframeworkmostcommonly

usedbytheCTOconfigurationcommunity,whichistheConstraint SatisfactionProblemorCSPframework,andwehaveextendedit fromCTOtoETOsituations.

Westartedbyrecallingconfigurationproblemsandconstraint

approaches and thenintroduceda verysimple cranesystemto

illustrate a configurationproblem. Thisvery simple example is usedthroughoutthearticletohighlighttheneedsofETOwhile bidding,aswellastheadvantagesandtheimplementationofour proposals.

Secondly,sixcasesthatbridgethegapbetweenCTOandETO situationshavebeenidentified.Eachofthemresultsfromaspecific

customerrequirementwhich cannotbedirectlyfulfilled bythe

company’sstandardcatalogandCTOmodeling.Therefore,some

engineering work is needed and this leads to a non-standard

technicalsolution.Inordertoreachthissolution,companiesfirst

have to identify which specific non-standard requirements are

acceptableand which arenot.It isonlyafterthis stepthatthe

knowledge-basedmodelcanbeenrichedwithnon-standardbut

acceptable specificities. Consequently, we have extended the

configurationdefinitiontoanETOsituationbyaddingthenotions

of “standard” and “non-standard”: (i) combination of property

values,(ii)propertyvalues,(iii)property,(iv)integrationof sub-system solutions, (v) integration of standard and non-standard

sub-system solutions, and (vi) sub-systems. These notions and

relevantcaseshavebeen situatedona globalETOschema(see

Fig.3)thatshowsthediversityofallthepossiblenon-standard

configurationflows.Theyhavebeensummarizedandgroupedas

follows:

!Standardandnon-standardpropertiesleadingtonon-standard sub-systemsolutions:

Case1:Non-standardcombinationsofstandardpropertyvalues (AC)

Case2:Non-standardpropertyvalues(AV) Case3:Non-standardproperty(AP).

!Standard and non-standardsub-systems leading to

non-stan-dardtechnicalsystemsolutions:

Case 4:Non-standard integration of standard sub-system

sol-utions(AI)

Case5:Non-standardintegrationofstandardandnon-standard sub-systemsolutions(NI)

Case6:Non-standardsub-system(AS).

For each of these cases, we have shown how the CTO

knowledge-based model can be extended or updated with all

non-standard specificities. Each extension has been illustrated

usingthe craneexample.Furthermore,it hasbeenshown that

differentmodelingextensionscouldbecumulatedinordertotake intoaccountdifferentnon-standardbutacceptablerequirements

present in the same industrial situation. For each root cause

leadingtoanETOconfiguration,wehavepaidattentiontomaking

sure that bidders are aware of the reasons for the ETO

configuration by using specific notation proposals in the

non-standardsolution:(i)AC foracceptablecombination,(ii)AVfor acceptable value, (iii) AP for acceptable property, (iv) AI for acceptableintegrationofstandardsub-systemsolutions,(v)NIfor acceptableintegrationofstandardandnon-standardsub-system solutions(vi)ASforacceptablesub-system.

Alltheseproposalstendtoshowthat,intermsofmodelingand intermsofconstraintfiltering,itappearshighlyfeasibletoextend

theuseofconstraint-basedconfigurationsoftwarefrom

Config-ure-to-OrdertowardEngineer-to-Order.AsstatedinSection2,we

did not find any significant previous work that attempted to

combineCTOandETOknowledgemodelingissues.Wehopethat

thisfirstproposalwillstimulateworkinthescientific configura-tioncommunity.Asregardsconfigurationsoftwareproviders,we haveseensomeconfiguration-aidingsoftwarethatproposesakind

of “escapegate” for addressing someETO issues, which would

allowaconventionalCTOstandardconfigurationprocess,coupled

with some kind of open design for non-standard requirement

processing.Wehopethatourproposalswillcontributetoabetter understandingofthiskindof“escapegate”andthereforeprovidea betterstructuretoCTO-ETOconfigurationsystems.Thegenericity ofourproposalsallowsthemtobeappliedinthebiddingprocess aswellasinotherdesignactivities.Toconcludeonthepractical benefitsofourproposals,weareconvincedthattheycangenuinely improvepractitioners’biddingmethods:(i)byallowingthemto

definemorebids whilereducing thetime, effortand resources

allocated,and(ii)bygivingthemcontrolledfreedomcomparedtoa catalogofstandardsolutions.

Inourfutureresearch,wenowneedtoextendourproposalsto thedeliveryprocessbyidentifyinganddrawingthelinksbetween non-standardsystemsandtheirdeliveryprocesses.Wealsohave totesttheapplicabilityandscalabilityofourproposalsusinglarger realcases.Particularlywithcomplexsystems,itisnotalwayseasy toidentifywhichnewfeatureswillberequiredandtoknowhowto

(14)

evaluatetheirfeasibilityapriori.Ona moreconceptualside,we alsothinkthatthesixcasespresentedherecanbeconsideredasa goodbasisforproposingamoreformaldefinitionoftheheaviness/ lightnesslevelthatcharacterizesEngineer-to-Ordersituations. References

[1]G.Arslan,M.Tuncan,M.T.Birgonul,I.Dikmen,E-biddingproposalpreparation systemforconstructionprojects,Build.Environ.41(10)(2006)1406–1413.

[2]R. Sonmez,B. Sözgen,Asupportvectormachine methodforbid/nobid

decisionmaking,J.Civ.Eng.Manage.23(5)(2017)641–649.

[3]R. Chalal,A.R. Ghomari, AnApproach for a Bidding Process Knowledge

Capitalization,inworldacademyofscience,Eng.Technol.13(2008).

[4]A. Le!sniak, E. Plebankiewicz, Modeling the decision-making process

concerningparticipationinconstructionbidding,J.Manage.Eng.231(2)

(2013)4014032.

[5]M.Krömker,K.D.Thoben,A.Wickner,Aninfrastructuretosupportconcurrent

engineeringinbidpreparation,Comput.Ind.33(97)(1997)201–208.

[6]W.Yan,M.C.Pritchard,C.H.Chen,L.P.Khoo,Astrategyforintegratingproduct conceptualizationandbidpreparation,Int.J.Adv.Manuf.Technol.29(5)

(2006)616–628.

[7]B.Chandrasekaran,Generictasksinknowledgebasedreasoning:highlevel

buildingblocksforexpertsystemdesign,IEEEExpert(3)(1986)23–30. [8]J.Olhager,Strategicpositioningoftheorderpenetrationpoint,Int.J.Prod.

Econ.85(2003)319–321.

[9]A.Sylla,E.Vareilles,M.Aldanondo,T.Coudert,K.Kirytopoulos,Customer/

supplierrelationship:reducinguncertaintiesincommercialoffersthanksto

readiness,riskandconfidenceconsiderations,Adv.Mech.Des.Eng.Manuf.

(2017)1115–1122.

[10]A.Felfernig,L.Hotz,C.Baglay,J.Tiihonen,Knowledge-BasedConfiguration

FromResearchtoBusinessCases,(2014).

[11]A. Myrodia, K.Kristjansdottir, L. Hvam, Impactof product configuration

systemsonproductprofitabilityandcostingaccuracy,Comput.Ind.88(2017)

12–18.

[12]D.Sabin,R.Weigel,Productconfigurationframeworks-asurvey,IEEEIntell.

Syst.13(4)(1998)42–49.

[13]P.-A.Yvar,ACSPapproachforthenetworkofproductlifecycleconstraints

consistencyinacollaborativedesigncontext,Eng.Appl.Artif.Intell.22(6)

(2009)961–970.

[14]L.Rivest,A.Desrochers,A.Brie,Adaptivegenericproductstructuremodelling fordesignreuseinengineer-to-orderproducts,Comput.Ind.61(2010)53–65. [15]O.Willner,J.Gosling,P.Schönsleben,Establishingamaturitymodelfordesign

automationinsales-deliveryprocessesofETOproducts,Comput.Ind.82

(2016)57–68.

[16]A.Sylla,E.Vareilles,T.Coudert,M.Aldanondo,L.Geneste,Readiness,feasibility andconfidence:howtohelpbidderstobetterdevelopandassesstheiroffers, Int.J.Prod.Res.55(23)(2017)7204–7222.

[17]G.Pahl,W.Beitz,EngineeringDesignASystematicApproach,SpringerScience &BusinessMedia,2013.

[18]J.Dantan,N.Gayton,A.J.Qureshi,M.Lemaire,A.Etienne,Toleranceanalysis approachbasedontheclassificationofuncertainty(aleatory/epistemic),12th

CIRPConferenceonComputerAidedTolerancing(10)(2013)287–293.

[19]É.Vareilles,M.Aldanondo,A.CodetDeBoisse,T.Coudert,P.Gaborit,L.Geneste,

Howtotakeintoaccountgeneralandcontextualknowledgeforinteractive

aidingdesign:towardsthecouplingofCSPandCBRapproaches,Eng.Appl.

Artif.Intell.25(1)(2012)31–47.

[20]S.Mittal,F.Frayman,Towardsagenericmodelofconfigurationtasks,Proc.

Elev.Int.Jt.Conf.Artif.Intell.2(1989)1395–1401.

[21]T.Soininen,J.Tiihonen,T.Männistö,R.Sulonen,Towardsageneralontologyof

configuration,AiEdam12(4)(1998)357–372.

[22]M.Aldanondo,E.Vareilles,Configurationformasscustomization:howto

extendproductconfigurationtowardsrequirementsandprocess

configuration,J.Intell.Manuf.19(5)(2008)521–535.

[23]D.Yang,M.Dong,Applyingconstraintsatisfactionapproachtosolveproduct

configurationproblemswithcardinality-basedconfigurationrules,J.Intell.

Manuf.(2013)99–111.

[24]M.Aldanondo,K.Hadj-hamou,G.Moynard,J.Lamothe,Masscustomization

andconfiguration:requirementanalysisandconstraintbasedmodeling

propositions,Integr.Comput.AidedEng.10(2003)177–189.

[25]A.Felfernig,G.Friedrich,D.Jannach,Conceptualmodelingforconfigurationof mass-customizableproducts,Artif.Intell.Eng.15(2001)165–176. [26]Z.Siddique,J.A.Ninan,Modelingofmodularityandscalingforintegrationof

customerindesignofengineer-to-orderproducts,Integr.Comput.AidedEng.

13(2)(2006)133–148.

[27]F.Elgh,Modellingandmanagementofproductknowledgeinan

engineer-To-Order,InternationalConferenceonEngineeringDesign,ICED11(August)

(2011).

[28]Z.Miaofen,S.Shaohui,G.Youping,C.Guojin,Researchontheconfiguration

designoftheETOproductbasedonknowledgeandthingcharacteristictable,

InternationalConferenceonAppliedInformaticsandCommunicationICAIC

(2011)273–281.

[29]Y.Kristianto,P. Helo,R. Jianxin,Asystemlevelproduct configuratorfor

engineer-to-ordersupplychains,Comput.Ind.72(2015)82–91.

[30]U. Montanari, Network of constraints: fundamental properties and

applicationstopictureprocessing,Inf.Sci.7(1974)97–132.

[31]S. Mittal, B. Falkenhainer, Dynamic constraint satisfaction problems.

Proceedingsofthe9th,NationalConferenceonArtificialIntelligenceAAAI

(1990)25–32.

[32]É.Vareilles,M.Aldanondo,P.Gaborit,Evaluationanddesign:a

knowledge-basedapproach,Int.J.Comput.Integr.Manuf.20(7)(2007)639–653.

[33]P.Pitiot,M.Aldanondo,E.Vareilles,Concurrentproductconfigurationand

processplanning:someoptimizationexperimentalresults,Comput.Ind.65

(4)(2014)610–621.

[34]E.Vareilles,T.Coudert,M.Aldanondo,L.Geneste,J.Abeille,SystemDesignand

ProjectPlanning:ModelandRulestoManageTheirInteractions,Integrated

Figure

Fig. 1. Generic CTO configuration model of the jib sub-system.
Fig. 2. Generic CTO configuration model of the crane system.
Fig. 3. Summary of the six ETO cases.
Fig. 4. Non-standard combination of standard property values.
+5

Références

Documents relatifs

Alors que l’idée d’une proportionnalité stricte entre le revenu et l’effort, quand bien même il s’agirait d’une exigence de justice également intuitive,

First, in Gass’s own initial experiment, L2 learners showed no reliable grammaticality effect in any structural condition (adverb placement, subject – verb agreement, or

In active hyperspectral imaging, a scene is illuminated by a laser source at many different wavelengths and the reflected light is imaged with a camera at each wavelength, resulting

9 Au sujet du troisième site, un acteur de l'administration (E) indique : « Mais juste des sanitaires, pas de douche, (...) sinon il aurait fallu de l'électricité à nouveau, des

Nous avons accéder à une méthode descriptive car cette méthode peut servir pour la résolution de notre problème et projet et après l’analyse des résultats dont nous avons

The objective of this study was to determine the phytochemical composition of a multicomponent hydroethanolic root extract (HRE) of Astragalus mongholicus Bunge and to assess

In summary, to the best of our knowledge, this is the first work estimating the e↵ect of pollution abatement investments on the production technology of firms using methods that

Although Lambon Ralph and Ehsan (2006) identified a significant effect of the order of introduction of the patterns when the relationships between input and output patterns