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
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
baUniversité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
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) 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)cantakeavalueonlyinafinitedomain(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
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.
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.
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
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,
(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.
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,
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.
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.
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
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