View
1
Download
0
Category
Preview:
Citation preview
Verband der Bahnindustrie in Deutschland (VDB) e.v.
VDB-Guideline
Quality Engineering during Design phaseof Rail Vehicles and Rail Vehicle Systems
3
Contents
Preamble 4
1 Objectives of the guideline 7
2 QE process model 9
3 Elements of the guideline 12
3.1 Productdevelopmentprocess(PDP)forrailvehicles 12
3.2 ThereadinessmodelsTRLandIRL 17
3.3 Phaseassignmentforthedesiredresultsandreadinesslevels ofthereferenceprocess(PDP) 26
3.4 Analysisofsystemsforcreatingcomparability 27
3.4.1 Structuringrequirements–functionalandnon-functional 28
3.4.2 Structureandtypesofchecklists 29
3.4.2.1 Non-functionalchecklist 30
3.4.2.2 Functionalchecklist 32
3.5 QEmethodsforassuringspecificphaseresults 34
3.6 Determiningmethodsforassuringresults(QEactionplan) 34
3.7 Presentationofsystems’statusbasedonreadinesslevels 38
4 Application of the QE process model in a project 39
Glossary 50
Literature 54
List of figures 55
Liability disclaimer 56
Contact 57
4
Preamble
Therailindustryandtherailoperatorshavethecommongoalofcommissioningrailvehiclesofhighqualityandonagreedtermsandconditions.Onekeyroleistheirdevelopmentintheappropriatequality–becauseincreasingperformancerequirementsplacedontheproductsandeverstricterlawsandapprovalregulations(e.g.relatingtotheenvironmentorEuropeanharmonisation)demandadaptationsintheproductdesignofrailvehicles.
Tothisend,theGermanRailwayIndustryAssociation(VDB)andDeutscheBahnAG(DBAG)issuedamemorandumofunderstandingontheirdecisiontolaunchaqualitypartnershipforthedevelopmentofrailvehicles.Itisintendedtobundletheknowledge,experienceandcompetenciesoftherailindustryandtheoperators.Thisguidelinerepresentsanimportantelementinthequalitypartnership.
ThisguidelinedescribesaprocessmodelusingmethodsfromQualityEngineering(QEprocessmodel).Duetothismodel,thepartiesinvolvedinthemanufacturingprocessareabletorec-ogniserisksalreadyattheearlystagesofdesignandthusavoidthem.Thedescribedactionsforqualityassuranceplacethemainemphasisontrustfulco-operationbytheplayersinthedevelopmentofrailvehiclesandtheirsubordinatesystems(sub-systems).
ThisguidelineisrecognisedbytheVDB’smembercompaniesasthe“industrystandard”.Inthefutureitwillbetakenintoaccountduringthedesign/engineeringofrailvehiclesandtheirsystems.Itaimstoadvancetheengineeringincompaniesintherailindustrythroughtheapplicationofqualitymanagementmethods,tominimiserisksandtoimprovethetransparencyofthesupplychain.Theguidelineindicatestheoptionsforachievingthis.Thecompaniesthemselvesareresponsibleforimplementingtheresultingrequirementsfortheengineeringinasuitablemanner.However,theminimumstandardachievedshouldbethatsetforthintheguideline:
• Establishingstructuredproductdesignprocesses,takingtechnologyreadinessand integrationreadinesslevelsintoaccount;• Evaluatingthesystemthroughsystematicanalysisoffunctionalandnon-functional requirements(checklists)andreviewthemafterchangeshavebeenmade;• Demonstratingspecificactionsforassuringthequalityofthedesignprocessrightatthe outsetbasedonaqualityplanandtheirconsistentimplementationwithdocumentary evidence;• AssessingthereadinesslevelsusingtheQEprocessmodeluponcompletionofeachphase (andcommunicatingtheresultstotheclient).
TheQEprocessmodelisintendedforintroductionthroughouttherailindustryandshouldbeappliedduringtheentiredevelopmentprocessofaproduct.Toavoidinfluencingcompetition,theguidelinewillinitiallyapplyonlyafterthetenderphase.However,itisexpedienttoapplytheprocessmodelalsoduringelaborationoftheoffer.
Theincreasedtransparency,theidentificationofasystem’scriticalelements,andtheactionstobederivedtherefromareallofgreatimportancefortheoffer.
Preamble
Termsshowninboldtypeareexplainedintheglossary
i
5
Preamble
Applicationofthemethodsandprocessesshouldconcentrateonearlyerrorprevention.Theassociatedsystematicassuranceofresultsreducestheeffortneededforandthecostsofsubsequentcorrectiveactions.Agradualintroductioncancompensatetheinitialtemporaryextraeffort.
Furthermore,therailindustryexpectsareducedeffortduetotheoptimisedmonitoringofdevelopmentprojectsbyapplyingthisguideline.QualityGateReviewsshouldbestreamlinedandtheresultsoftheQEprocessmodelshouldfeedintothem.Evidenceofthereadinesslev-elswhichisofequivalentqualityandquantityshouldberecognisedduringthisprocess.
Thisguidelinewasdevelopedjointlybythemajormarketparticipants.ItisplannedthatitscontentswillbeincorporatedintotheongoingdevelopmentoftheInternationalRailwayIndustryStandard(IRIS).Theguidelineisnotrestrictedtocompaniesengagedindevelop-mentactivitiesinGermany,butshouldalsobeappliedandimplementedintheinternationalcontext.
Inaddition,thisguidelinewillhelpingeneratingtherequirementsmorefunctionalandinlimitingdetaileddescriptionstothoseelementswhichneedstandardisationacrossmultipleprojects,e.g.forintegrationintoanexistinginfrastructureorinthecaseofstandardsolutions.
Thankstoalltheseaspects,manufacturersandoperatorsalikecanachievethedesiredresultsandthuscontributetothecontinuingpartnership-baseddevelopmentoftherailsector.
6
7
1|Objectivesoftheguideline
Enhancedco-operationandcommunicationEvencloserco-operationbetweenmanufacturersofrailvehiclesandtheirsuppliersisoneaspectofthefutureviabilityoftherailwayindustry.Oneofthethingsneededforachievingitisacommonunderstandingoftherequirementsandthepathtowardsqualitativeassuranceofresultsanddeadlines,intensiveandfrankcommunicationaboutthenecessaryactions,andtransparencyconcerningthesetopicsbetweenallthoseinvolvedalongtheentiresupplychain.
Thisguidelineisintendedtocontributethisprocessbyprovidingassistanceinderivingpre-ventiveactionsfortheassuranceofdevelopmentprojectsintherailwayindustry,whichtakethedevelopmentstatusoftheoverallsystemandthoseofthesub-systemsintoconsidera-tion.Thiswillmarkedlyreducethedevelopmentrisks.
AccomplishacommonunderstandingofQualityEngineeringFurthermore,theguidelineshouldachieveacommonunderstandingofqualityengineeringandtheuseofqualityengineeringmethods(QEmethods)withinthesupplychain.Italsodescribeshowcriticalelementscanbesystematicallyidentifiedatanearlystage.Atthesametimeitoutlinesapproachesforvalue-basedandtargeteddeploymentofpreventiveQEactionsinthedevelopmentofcompleterailvehiclesandtheirsubordinatesystemsand/orcomponents.Theguidelineenablesthemanufacturerstoconcentrateonthoseactionsthathavebeenidentifiedasrelevantandeffective.
CommissioningofrailvehiclesontheagreedtermsandconditionsThisguidelineisintendedtoassistinachievingthecommonobjectiveofoperatorsandman-ufacturers:commissioninghighqualityrailvehiclesontheagreedtermsandconditions–forexamplethoseapplyingtotechnicalproperties,deadlinesandcosts.
EstablishtransparencyandcomparabilityApplicationoftheguidelineenables: • thecomparabilityofthedevelopmentstatusesoftheindividualsystemsfromwhicha railvehicleisconstructed; • therealistic,comparabledescriptionandassessmentofthequalityassuranceactions andinputsrequiredforthedevelopmentgoalstobeachievedwithcertainty.
TheseobjectivesareachievedthroughapplicationoftheQEprocessmodel.Itusesreadinessmodelsasabasisforfocusingonidentifyingthedevelopmentstatusesofthesuperiorandsubordinatesystemswithinavehicleproject.Italsomakesitpossibletotracktheprogressofdevelopmentbymeansofcomparisonwithaproductdesignprocessasareferenceandusingdefineditemsofevidencethroughoutthedevelopmentprocess.Thiscomparisonisbasedonasystematic,standardisedanalysisofthecompletesuperiorsystemandthesubordinatesub-systemsoftherailvehicle.
Objectives of the guideline
8
Theanalysistakesaccountofthefunctionviewandthecomponentview,andenablesidenti-ficationofthoseelementsinasystemthatexhibitthelowestlevelofreadiness.ThenecessaryQEactionsarederivedbasedonthedeviationsfromthetargetstatusesoftheproductdesignprocess(PDP).ThisguidelineproposesQEmethodsdependingonthedegreeandthetypeofdeviationandthetimeofitsoccurrence.ItisthenuptothemanufacturerordevelopertodrawupaQEactionplanforeachsystem.
AssuringinnovationTherailwayindustryworksonadvancingthetechnologyinrailvehicleswiththeaimoflong-termsuccessonthemarket.Inthisprocess,readinessmodelscanbeusedtodescribethestatusesofsystems,inordertopinpointrisksandobtainatransparentviewofthequalityassuranceneededforinnovations.Fortheanalysis,asystemwithalowlevelofreadinessincombinationwithaplausibleactionplanforassuringtheobjectiveswithinadefinedtimeframeisregardedasequivalenttoasystemthatalreadyexhibitsahigherlevelofreadiness.
MinimisingeffortsAtthebeginningofaproject,theQEprocessmodelrequiresacertainamountofinitialef-forts,butgainsinthelaterphasescompensateforthis.Alltheanalysesareconductedonthebasisofstandardchecklistswithquestionsaboutdefinedtopicareas–sorelevanttopicareasandtheirstatusaresystematicallyrecorded.AstheQEprocessmodelisappliedmorefre-quently,learningeffectsbecomeapparentwhichdecreasestheinitialamountofefforts.ThisguidelinerecommendsthemanufacturerstointegratetheprocessesoftheQEprocessmodelintotheircorporateprocesses,inordertoavoidduplicatedeffortthatcouldariseduetoinade-quatesynchronisationofthecontentsoftheirdevelopmentandqualityprocesseswiththeQEprocessmodel.Thisappliesinparticulargiventhatthefunctionaldescriptionofsystemsbytheclientsisbecomingevermoreimportant.Thishavetobetakenintoconsiderationequallybythemanufacturersandthesuppliersofsub-systemsintheirdevelopmentprocesses.Theanalysesofthedevelopmentstatusesofsystemsalsobuildonthefunctionview.
Objectives of the guideline
9
2|QEprocessmodel
Therearetwobasicapproachesfordevelopingrailvehicles(Figure1): 1. Adoptionoftried-and-testedsystemswithadaptivedevelopment:themanufacturers constructnewrailvehiclesbyevolvingthemoutoftried-and-testedsystems.
Thisapproachfocusesprincipallyonintegratingthesubordinatesystemsintothenew, superioroverallsystem.Anothermajorfocusistheanalysisoftheboundaryconditions –forexampleamendedlicensingregulationsandlaws,otheruseprofilesorchanging installationconditions.Otherfactorsincludechangingperformancerequirements placedonthesystems.
Thedevelopersmustidentifyhowtherequirementsoftheexistingsystemdifferfrom thoseofthenewsystem,andusethisinformationtoderivethenecessaryactions. Thisprocedureisappliedinmostrailvehicleprojects.
2. Developingnewsystemsandnewsub-systems:ahighdegreeofinnovationisrequired todevelopnewrailvehiclesorsub-systems.
QE process model
QEprocessmodel(Fig.1)
Adoptionoftried-and-testedsystemswithadaptivedevelopmentAspects:- Comparability- Systematic identifi cation and classifi cation of deviations- “Common basis” - Starting point- Reference process
Application of preventive QE actions (analysis-based, phase and result-specifi c)
ObjectiveCommission rail vehicles on agreed terms and conditions- Properties (high quality) - Deadline- Budget
Developmentofnewsystems- Reference process- Baseline for orien- tation/classifi cation
QEprocessmodelStructured, standardised approach• Reference process: product design• Measurements: - Technology readiness (TR) - Integration readiness (IR)• Method of analysis: - Function and component views (application of EN 15380 -2/4)• Assuring results: Suitable QE methods based on: - Levels of readiness - Deviation from desired result
10
ProcessstepsintheQEprocessmodel(Fig.2part1)
Client: userspecifications(US)/requirements
Contractor designs the superior system: functionalspecifications(FS)/requirementsincl.vehicleconcept
Standardisedstructureforrequire-mentsforsuperior-system(fromUSandFS)- Non-functional- Functional
Non-functional
Functional
Standardisedstructurefordescri-bingthereferencesystemDefi nition ofrequirementsfrom US and FS
ReferenceproductdesignprocessTOOLS.xlsx Sheet:“PRODUCT_DESIGN_PROCESS”
Record- Requirements- Necessary but not yet specifi ed requirements
Selectionofreferencesystem- Identifi cation of system with best match with new system
Checklist TOOLS.xlsx Sheet:“Non-functional requirements”
OutputInput Process
Recorddeviations of new system from reference system and / or need for new defi nition / design
- Non-functional
- Functional (see Fig. 2 part 2)
(Fig.2part2)
Results for documentation
QE process model
11
ProcessstepsintheQEprocessmodel(Fig.2part2)
Description of the relevant functions of the systems of rail vehicles based on EN 15380-4
StandardisedstructureRecording and describing the functions of systems
Generic description of the stages- TRL / IRL TOOLS.xlsx Sheet:“TRL_IRL_MEASUREMENTS_LEVELS”
Recommendation of specifi c (phase and result) QE METHODS for assuring the resultsTOOLS.xlsx Sheet: “QE_METHODS”
Classifying the deviation according to defi ned readiness levels inTRL / IRL
Identifying critical elements(readiness level / serious deviation)
CHECKLIST OF FUNCTIONAL REQUIREMENTS TOOLS.xlsx Sheet: “Functional requirements”
SUMMARY OF QE ACTIONSTOOLS.xlsx Sheet: “Summary_QE_Actions”
Results for documentation
QE ACTION PLAN TOOLS.xlsx Sheet: “QE_ACTION_plan_generic“
OutputInput Prozess
Selecting and assigning suitable QE actions for assuring the results
Creating comparability- Element with lowest readiness level (TRL / IRL)- Number of main functions needing QE actions
Recording deviations of new system from ref. system / need for new defi nition / new design
- Non-functional
- Functional
QE process model
12
Inthisapproach,actionsforassuringthenecessaryresultsareofgreatimportanceineveryphaseofproductdevelopment.
Inbothapproaches,thedevelopersshouldassuretheirresultsbymeansofprogresschecks.Thegenericproductdesignprocess(PDP)providesorientation;thisprocessassignsspecificdevelopmentgoalstotheindividualphases.Developmentriskscanalsobereducedbyrecom-mendationofpreventiveQEmethodsspecifictothephaseandtheresult.
TheQEprocessmodelisbasedonthefollowingelements:
• Productdesignprocess(PDP)withdefinedobjectivesforthephasesasthereference process; • Measurementsfordeterminingthedevelopmentstatus:technologyreadinesslevel (inTRL)andintegrationreadinesslevel(inIRL); • Analyticalmethodsforevaluatingthestatusofsystemsandtheirdeviationsfrom comparatorsystems,fromthefunctionandcomponentviews; • AssuringresultsbyrecommendingappropriateQEmethodsbasedonthelevelsof readinessandthedeviationsfromthedesiredresult.
Figure2(parts1and2)describesthestepsintheQEprocessmodelandtherelevantinputsandoutputs.Astructuredandcomparableapproachispossibleduetochecklistsforthein-puts,thegenericproductdesignprocess,thestagesindeterminingthelevelsofreadinessandtherecommendationofQEmethodsforassuringphase-specificresults.TheQEprocessmodelprovidesoutputintheformofsystems’developmentstatus.Uniformlystructuredchecklistsandactionplansensurethatthestatusistransparentandcomparable.
3|Elementsoftheguideline
3.1Productdesignprocess(PDP)forrailvehicles
Thisguidelinedescribestheprocedurewithintheproductdesignprocess(PDP)forrailvehi-cles,fromthe“Tender”phaseallthewaytothe“Operation/warranty”phase(Figure3).Thedevelopmentmethodologyisfunction-based:thestartingpointforthedesignprocessisthefunctionsthatasystemhastofulfil.Therequiredconstructionelementsarealsoderivedfromthesefunctions.
ThePDPthereforedescribestheresultsofeverydesignphasefromthefunctionandcompo-nentviews.ThedesiredresultsforeachphaseandthestandardstructureofthePDPallowdifferentsystemstobecompared.Whenexistingsolutionsaretransferredtoanewproject,thePDPmakesitpossibletoallocateasystemtoadesignphaseonthefoundationofobjec-tivelyverifiableresults.
QE process model
13
ThePDPoftheQEprocessmodelrepresentsagenericprocesswithspecificqualityassuranceactionsdefinedforeachdevelopmentphase.Inaddition,theresultsthathavetobeachievedineachphasearedefined,alongwiththeevidencerequiredtoshowthattheyhavebeenachieved.ThePDPisthereforeaproduct-orientedprocess.Bycontrast,thespecificdevelop-mentprocessesofthemanufacturersarefrequentlyorientedontheworkflowsindevel-opment.Themanufacturerhasthetaskoftransferringtherequirementsfordevelopmentphasestoitsowndevelopmentprocess.
ThePDPisdividedintogenericphases,thefirstofwhichisthetenderphaseandthelastisthewarrantyphase.ThePDPincludestheengineeringphases“Tender”,“Concept”,“Interme-diatedesign”and“Finaldesign”.ThesephasesarestructuredinlinewiththeproceduresetoutintheVDIguidelines2206(Designmethodologyformechatronicsystems)[VDI2206]and2221(Systematicapproachtothedesignoftechnicalsystemsandproducts)[VDI2221].Theotherphasesareorientedontherailwayvehiclehandbook“HandbuchEisenbahnfahrzeuge”[BUN2010]andontheestablishedpracticeforcommissioningrailvehicles.
Milestonesdescribetheresultsthathavetobeachieveduponcompletionoftheindividualphases.Itcanthusbeascertainedwhethertherespectiveobjectiveshavebeenreached.Read-inessmodelsaddmoreprecisedetailtothisclassification:theyusesystematic,standardisedquestionsaboutpredeterminedcategoriesindefinedstagestopresentthestatusofdevel-opmentprojectsinacomprehensibleandtransparentmanner.Thereadinessmodelsandthestagesaredescribedindetailinsection3.2.
Themilestonesalsoprovidethebasisforco-ordinationandsynchronisationwithinthesupplychain.Herethedevelopersdonothavetoadhereexactlytothereferenceprocess,butinsteaditservestoindicatewhichresultsintheindividualphasesarehelpfulforachievingtheobjec-tives.Thedevelopersofthesystemsareresponsiblefortakingtheseresultsintoconsiderationduringtheirwork.
Figure4showsthephasesofthePDPandthecategoriesofresults,whichallowsystematic,phase-specificevaluationofthephase-specificresults.Italsodescribesthephase-specificresultsofprojectmanagementandqualitymanagement.Theydeterminesuchthingsasthecontentandtimingofcommunicationinthesupplychainandthepreparationofqualityengi-neeringactionplans(QEplan).
Genericreferenceprocess:productdevelopmentprocess(Fig.3)
Tend
er /
clar
ifi ca
tion
Conc
ept
Inte
rmed
iate
des
ign
Dyn
amic
com
mis
sion
ing
Auth
oris
atio
n fo
r pla
cing
the
vehi
cle
in s
ervi
ce
Ope
ratio
n / w
arra
nty
Fina
l des
ign
Prod
uctio
n
Type
test
prio
r to
inte
grat
ion
/ fi r
st a
rtic
le in
spec
tion
(FAI
)
Stat
ic co
mm
issi
onin
g
Elements of the guideline
14
Elements of the guideline
Schematicdiagramoftheproductdesignprocess(PDP)(Fig.4)
TR-levels 3.1 3.2 3.3 3.4
IR-levels I II.I II.II II.III
Developmentphase
Planning - requirements for information- Compilation - Recognition of gaps
Conceptual design - Functional structures - Basic solutions
Drafting and designing modular structuresElaborating solutions/ functional structures
Overall draft design
Functionview
Specifying and describing main functions
Specifying and describing overall function and major sub-functionsSpecifying how functions are fulfi lled (draft system design) by functional structures (incl. sub-functions) and operating principles and/or functional architecture control)
Division of elements for control (hard-wired/software; superior/subordinate)
Componentview
General arrangementof structure/space is determined (black box)
General arrangement of structure/space is determined (black box)
Design of key modules (sub-systems and system elements, e.g. assemblies, individual parts), including linkages (interfaces) / programming the software modules (control)
All major design decisions have been made,Completion of design and linkage of all components / software modules (control) of the system
Agreeing project communica-tion / status / duty to provide or collect information / format of communication (e.g. VDB Requirement Interchange Format / RIF) with the aim of exchanging as much concrete information as possible
Schedule with fi xed co-ordina-tion times for interfaces
Procedural strategy for the co-ordinating with the operator (fi nal customer) and for the support of the system supplier by the sub-system supplier;Project-related exchange of information between superior/subordinatesystems, e.g. change management, regular co-ordination after each phase;Step-by-step approach for synchronising the entire supply chain
Entire supply chain is syn-chronised
Project-related exchange of information between superior/subordinatesystems, Active life of change man-agement (bilateral) for all co-ordinated topics - regular co-ordination after each phase
Ongoing documented progress tracking
Project-related exchange of information between system and sub-system,Active life of change management (bilateral) for all co-ordinated topics - regular co-ordination after each phase
QE plan for systems based on readiness level analysis (TRL /IRL)
Plan for elements not yet taken into account
Updated analysis-based QE plan - evaluation of the elements on the critical path - review after each phase
Action plan for elements not yet taken into account
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/
firstsampletest(FST)
Staticcommissioning Dynamiccommissioning Authorisationforplacingthevehiclein
service
Operation/warranty
Q m
anag
emen
t / Q
E pl
anPM
- su
perio
r/su
bord
inat
esys
tem
Prod
uct d
evel
opm
ent
4 5 6 / 7 8 9
III IV.I IV.II IV.III V
Assurance of properties through verifi cation / validation
Experimental vehicle Near-series productFirst sample
First sample / series element integrated into superior system
First sample / series element integrated into superior system,Adaptation / programming of integrative part (higher / subordinate system) of soft-ware (control) as far as dynamic commissioning
Series element integrated into superior system
Series element integrat-ed into superior system
Project-related information exchange between system and sub-systemActively living the change management (bilateral) for all co-ordinated topics - regular co-ordination after each phase
Updated, analysis-based QE plan - assessment of the elements in the critical pathway - review after each phasePlan of action for elements not yet taken into consideration
Reference product design process: determination of desired results for each phase - Provides orientation- Deviations indicate a need for further analysis
Separate detailed presentation available at www.bahnindustrie.info
15
Elements of the guideline
TR-levels 3.1 3.2 3.3 3.4
IR-levels I II.I II.II II.III
Developmentphase
Planning - requirements for information- Compilation - Recognition of gaps
Conceptual design - Functional structures - Basic solutions
Drafting and designing modular structuresElaborating solutions/ functional structures
Overall draft design
Functionview
Specifying and describing main functions
Specifying and describing overall function and major sub-functionsSpecifying how functions are fulfi lled (draft system design) by functional structures (incl. sub-functions) and operating principles and/or functional architecture control)
Division of elements for control (hard-wired/software; superior/subordinate)
Componentview
General arrangementof structure/space is determined (black box)
General arrangement of structure/space is determined (black box)
Design of key modules (sub-systems and system elements, e.g. assemblies, individual parts), including linkages (interfaces) / programming the software modules (control)
All major design decisions have been made,Completion of design and linkage of all components / software modules (control) of the system
Agreeing project communica-tion / status / duty to provide or collect information / format of communication (e.g. VDB Requirement Interchange Format / RIF) with the aim of exchanging as much concrete information as possible
Schedule with fi xed co-ordina-tion times for interfaces
Procedural strategy for the co-ordinating with the operator (fi nal customer) and for the support of the system supplier by the sub-system supplier;Project-related exchange of information between superior/subordinatesystems, e.g. change management, regular co-ordination after each phase;Step-by-step approach for synchronising the entire supply chain
Entire supply chain is syn-chronised
Project-related exchange of information between superior/subordinatesystems, Active life of change man-agement (bilateral) for all co-ordinated topics - regular co-ordination after each phase
Ongoing documented progress tracking
Project-related exchange of information between system and sub-system,Active life of change management (bilateral) for all co-ordinated topics - regular co-ordination after each phase
QE plan for systems based on readiness level analysis (TRL /IRL)
Plan for elements not yet taken into account
Updated analysis-based QE plan - evaluation of the elements on the critical path - review after each phase
Action plan for elements not yet taken into account
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/
firstsampletest(FST)
Staticcommissioning Dynamiccommissioning Authorisationforplacingthevehiclein
service
Operation/warranty
4 5 6 / 7 8 9
III IV.I IV.II IV.III V
Assurance of properties through verifi cation / validation
Experimental vehicle Near-series productFirst sample
First sample / series element integrated into superior system
First sample / series element integrated into superior system,Adaptation / programming of integrative part (higher / subordinate system) of soft-ware (control) as far as dynamic commissioning
Series element integrated into superior system
Series element integrat-ed into superior system
Project-related information exchange between system and sub-systemActively living the change management (bilateral) for all co-ordinated topics - regular co-ordination after each phase
Updated, analysis-based QE plan - assessment of the elements in the critical pathway - review after each phasePlan of action for elements not yet taken into consideration
Q m
anagement / Q
E planPM
- superior/subordinatesystemProduct developm
ent
16
Integrationofthesupplychainduringthedevelopmentofrailvehiclesisamajorfactoraf-fectingsuccess–becausetheoverallsystemsarebuiltupfromsub-systems,andthemajorityofthemhavetobeeitheradaptedand/ordevelopedspecificallyforeachproject.Thecurrentstateoftheartismodularsolutionsandplatformsolutions.Thesystemsaredevelopedinadvanceforspecifiedusecases.However,themanufacturershavetoensurethattheoriginalrequirementsplacedonthesystemscorrespondtotherequirementsofthenewsystem.Here,too,theQEprocessmodelhelpsdevelopersbyenablingthemtoconductasystematicanalysisforidentifyingdeviations.Insomecasestherequirementsplacedonthesubordinatesystemscannotbespecifieduntiltheconceptphaseforthesuperiorsystem,sincepriortothisnotalltherequiredinformationisavailable.Forthisreason,thesesystemscanonlybedevel-opedafterthispoint.Asarulethisreducesthetimeavailablefordevelopingthesubordinatessystems.Theriskofthishappeningcanbeminimisedusingthesimultaneous/concurrentengineeringprocedure.Toincorporatethesubordinatesystemsintothesuperiorsystem,theyhavetobephysicallyintegratedintotheoverallsystemfollowingthetypetestingandfirstarticleinspectionandatthelatestatthetimeofstaticcommissioning.However,itispossiblethattheintegrationhastotakeplacemuchearlierintheassemblyprocess,dependingontheindividualproject.Insuchcasesthedesignprocessforthesubordinatesubordinatesystemsstartsafterthatoftheoverallsystem,althoughitendsbeforethatoftheoverallsystem.Thedevelopmentperiodforthesub-systemshastobeshorterthanthatfortheoverallsystem.ThecascaderelationshipbetweenthepartnersinthesupplychainisshowninFigure5.
Thecascadewithinthesupplychain(Fig.5)
Cascading the PDP from the overall system to the supply chain: superior (overall) system manufacturer > subordinatesystem manufacturer > subordinate(component) system manufacturer
The PDPs of the superior and subordinatesystems (supply chain) have the same structure. The PDP of the subordinatesys-tems / supply chain is compressed and starts with a time lag
Superior (overall) system
Tend
er, r
eque
st
Subm
issi
on o
f offe
rs
Clar
ifi ca
tion
and
refi n
emen
t of
pro
ject
Type
test
ing
not i
nteg
rate
d / F
AI
Stat
ic co
mm
issi
onin
g of
ov
eral
l sys
tem
Dyn
amic
com
mis
sion
ing
of
over
all s
yste
m
Valid
atio
n au
thor
isat
ion
for
plac
ing
in se
rvic
e
Ope
ratio
n / w
arra
nty
Conc
ept
Inte
rmed
iate
des
ign
Fina
l des
ign
Prod
uctio
n
Subordinate, 1st level
Subordinate, 2nd level
Tend
er, r
eque
st
Subm
issi
on
of o
ffers
Clar
ifi ca
tionSubordi-
nate, 1st level Co
ncep
t
Inte
rmed
iate
de
sign
Fina
l des
ign
Prod
uctio
n
Type
test
ing
/ FAI
for
subo
rdin
ates
yste
m
Tend
er, r
eque
st
Subm
issi
on o
f offe
rs
Clar
ifi ca
tionSubordi-
natesys-tem, 2nd level Co
ncep
t
Inte
rmed
iate
ce
sign
Fina
l ces
ign
Prod
uctio
n
Type
test
ing
/ FAI
for
subo
rdin
ates
yste
m
Integration of the supply chain
17
3.2Themodelsfortechnologyreadinesslevel(TRL)andintegrationreadinesslevel(IRL)
Readinessmodelsmakeitpossibletodeterminethedevelopmentstatusofcomplexsystemsinatransparentandcomprehensibleway.Thelevelofreadinessisevaluatedonthebasisofspecificallydefinedattributes,towhichvariousrequirementsareassignedstagebystage.Thedegreetowhichtheserequirementstagesarefulfilleddeterminesthesystem’slevelofreadiness.Readinessmodelsthusmaketheprogressofcomplexsystemstransparentduringtheprocessofproductdevelopment.Notonlythedefinedattributesplayakeyrolehere,butsodoregularevaluationsofthesysteminapredeterminedschedule–frequentlyduringeachphase.Figure6illustratesthebasicstructureofreadinessmodels.
Principleofreadinessmodels[AKK2013](Fig.6)
Element not takeninto account
Req.= requirement
Objectunderexamination
Observation
Improvement
Comparison
Evaluation /actions
Evaluator/assessor
Req.= requirement
Defi ned readiness levels with level-dependent requirements
and attributes
Readinessmodel
Readiness levels 1 2 ... n Attribute 1 Req. 1.1 Req. 1.2 ... Req. 1.n
Attribute 2 Req. 2.1 Req. 2.2 ... Req. 2.n ... ... ... ... ... Attribute m Req. m.1 Req. m.2 ... Req. m.n
The readiness level models TRL and IRL
18
Alevelofreadinessisregardedasreachedonlywhennotonlythelocalcriteriaforthatpar-ticularlevelhavebeenmet,butalsothosedescribedatthepreviousstage(soeachlevelofreadinessbuildsonthepreviousones[AHL2005]).Ifthisisnotthecase,thelevelofreadinessofthesystemisresettothelevelthathasalreadybeenfulfilled.Asystemreachesahigherreadinesslevelonlyifitfulfilsallthecriteriadefinedforthehigherlevel–thelevelofreadi-nessisalwaysdeterminedbytheweakestpartofthesystem.
Readinessmodelshavealreadybeensuccessfullyestablishedinothersectors,too,e.g.theaerospaceindustry,whichapplieslevelsoftechnologicalmaturity(TechnologyReadinessLevels).Thesedonotdifferintheirfundamentallogic,butthisguidelineforrailvehiclescon-siderstechnologicalreadinessandintegrationreadinessseparatelyandthencombinesthem,becausehereasaruleestablishedsub-systemsarelinkedwithinnovations.
FollowingonNASA’smaturitymodel,thetechnologyreadinessmodelforrailvehiclesconsistsofninelevels,wherebytheengineeringphaseisdividedintothefoursub-levelsTRL3.1toTRL3.4.Theyrepresentdevelopmentprogressinthisphaseoftheprocess–whichiscrucialtoprojectsuccess.TheunderlyingphasesarederivedfromthegenericdevelopmentphasesintheVDIdesignguidelines2206and2221[VDI2206,VDI2221].
Thephasesintheassuranceofpropertiesareorientedontheestablishedverificationandvalidationprocessesforrailvehicles.
Theintegrationreadinessmodel(IRL)consistsoffivelevelsandhere,too,theengineeringphaseisdividedintosub-levels.ThelevelsIRLII.ItoII.IIIcoverthestep-by-stepco-ordinationprocessofinterfacesbetweenthesuperior/subordinatesystems.Step-by-stepco-ordinationisgenerallyindispensablehere,asshortprojectdurationusuallydemandsthatthesystemsaredevelopedsimultaneously.Theassuranceofpropertiesisalsosub-dividedintothephasesIRLIV.ItoIV.III,tomaketheprogressduringcommissioningmeasurablehereaswell.
Figure7describesbrieflywhattheTRLandIRLreadinesslevelscontain.
The readiness level models TRL and IRL
19
EntwurfsversionfürSteeringCommittee
Brie
fdes
crip
tion
ofte
chno
logy
and
inte
grat
ion
read
ines
slev
els(
Fig.
7)
Definition/clarification
IRL I
Mai
n fu
nctio
ns a
re d
efi n
ed a
nd d
ivid
ed b
etw
een
syst
ems (
mod
el)
Inte
rfac
es a
nd in
tera
ctio
n ar
e de
term
ined
(mod
el)
Supe
riors
yste
m d
efi n
es
subo
rdin
ate
syst
em‘s
boun
dary
co
nditi
ons a
nd fu
nctio
ns
TRL 3
.1Re
quire
men
ts a
nd b
ound
ary
cond
ition
s are
des
crib
edM
ain
func
tions
are
defi
ned
Design
IRL I
I.ID
eter
min
atio
n of
all
cros
s-sy
stem
func
tions
(inc
l. anc
illar
y an
d de
rived
func
tions
; fu
nctio
nal a
rchi
tect
ure)
,Fu
nctio
nal s
truc
ture
s and
ope
ratin
g pr
inci
ples
(mod
el);
gene
ratio
n of
com
plet
e in
form
atio
n fo
r sub
ordi
nate
syst
em (f
unct
iona
l, non
-fun
ctio
nal)
(mod
el)
TRL 3
.2Pr
oduc
t (m
odel
) con
cept
ual d
esig
n is
com
plet
eAs
soci
atio
n of
func
tion<
->op
erat
ing
prin
cipl
e<->
cons
truc
tion
elem
ent
IRL I
I.II
Det
aile
d de
term
inat
ion
of in
terf
aces
for e
lem
ents
of t
he sp
ecifi
c pha
se (m
odel
),D
escr
iptio
n of
dat
a in
terf
ace
for s
ub-s
yste
ms t
hat a
re ch
arac
teris
ed b
y co
mpl
ex
soft
war
e an
d ha
ve fe
edba
ck lo
ops t
o th
e ci
rcui
t dia
gram
of t
he tr
ain
and/
or
betw
een
the
syst
ems (
mod
el)
TRL 3
.3Co
nstr
uctio
n el
emen
ts (m
odel
) of a
func
tiona
l str
uctu
re fu
lfi l r
equi
rem
ents
pl
aced
on
this
func
tiona
l str
uctu
re
Det
erm
inat
ion
of a
ssur
ance
of p
rope
rtie
s (ve
rifi c
atio
n / v
alid
atio
n pr
inci
ple)
IRL I
I.III
All o
vera
rchi
ng fu
nctio
ns a
re fu
lfi lle
d (m
odel
)D
etai
led
dete
rmin
atio
n of
all
inte
rfac
es (m
odel
)
TRL 3
.4D
esig
n of
all
cons
truc
tion
elem
ents
is co
mpl
ete
(mod
el)
All c
onst
ruct
ion
elem
ents
are
inte
grat
ed in
to th
e sy
stem
(mod
el)
Inte
ract
ing
elem
ents
fulfi
l the
requ
irem
ents
(mod
el)
Assuranceofproperties
isolated
IRL I
IID
efi n
ed in
put f
rom
supe
rior s
yste
m fu
lfi ls
/ tr
igge
rs d
efi n
ed fu
nctio
n in
non
-in
tegr
ated
subo
rdin
ate
syst
em
From
vie
wpo
int o
f sub
ordi
nate
syst
em, t
estin
g of
conn
ectio
n to
supe
rior s
yste
m
and
othe
r sys
tem
s
Subo
rdin
ate
syst
em fu
lfi ls
bo
unda
ry co
nditi
ons a
nd fu
nctio
nsTR
L 4Ev
iden
ce th
at a
ll re
quire
men
ts a
re fu
lfi lle
d by
the
fi rst
sam
ple
that
is n
ot
inte
grat
ed in
to th
e su
perio
r/su
bord
inat
e sy
stem
(exp
erim
enta
l set
-up
with
sy
stem
qua
lifi c
atio
n br
ough
t for
war
d) to
the
exte
nt d
efi n
ed a
nd v
erifi
able
fo
r the
type
test
and
fi rs
t sam
ple
test
(FST
)
Assuranceofpropertiesintegrated
IRL I
V.I
Defi
ned
inte
ract
ion
fulfi
ls /
trig
gers
defi
ned
func
tion
/ fee
dbac
k on
the
initi
al
sam
ple
inte
grat
ed in
to th
e su
perio
rsys
tem
und
er st
atic
cond
ition
s
Assu
ranc
e of
pro
pert
ies
thro
ugh
inte
grat
ion
of su
perio
r/su
bord
inat
esys
tem
s
TRL 5
Evid
ence
that
all
requ
irem
ents
are
fulfi
lled
by th
e fi r
st sa
mpl
e th
at is
inte
grat
ed
into
the
supe
rior s
yste
m u
nder
stat
ic co
nditi
ons
IRL I
V.II
Defi
ned
inte
ract
ion
fulfi
ls /
trig
gers
defi
ned
func
tion
/ fee
dbac
k on
the
initi
al
sam
ple
inte
grat
ed in
to th
e su
perio
rsys
tem
dur
ing
test
or t
rial o
pera
tion
TRL >
= 6
Evid
ence
that
all
requ
irem
ents
are
fulfi
lled
by th
e fi r
st sa
mpl
e th
at is
in
tegr
ated
into
the
supe
rior s
yste
m u
nder
sim
ulat
ed u
se co
nditi
ons (
test
ope
ratio
n)TR
L >=
7….
und
er re
alis
tic co
nditi
ons (
tria
l ope
ratio
n)
IRL I
V.III
Defi
ned
inte
ract
ion
fulfi
ls /
trig
gers
defi
ned
func
tion
/ fee
dbac
k on
the
serie
s pr
oduc
t int
egra
ted
into
the
supe
riors
yste
m u
nder
app
rova
l and
acc
epta
nce
cond
ition
s
TRL 8
Evid
ence
that
all
requ
irem
ents
are
fulfi
lled
by th
e se
ries p
rodu
ct th
at is
inte
grat
ed
into
the
supe
rior s
yste
m u
nder
app
rova
l and
acc
epta
nce
cond
ition
s
IRL V
Defi
ned
inte
ract
ion
fulfi
ls /
trig
gers
defi
ned
func
tion
/ fee
dbac
k on
the
serie
s pr
oduc
t int
egra
ted
into
the
supe
riors
yste
m u
nder
ope
ratin
g co
nditi
ons
TRL 9
Evid
ence
that
all
requ
irem
ents
are
fulfi
lled
by th
e se
ries p
rodu
ct th
at is
inte
grat
ed
into
the
supe
rior s
yste
m u
nder
ope
ratin
g co
nditi
ons
Brie
fdes
crip
tion
ofIR
leve
lsM
ajor
IRL-
TRLi
nter
actio
nBr
iefd
escr
iptio
nof
TRL
leve
ls
20
TheTRLevaluatesthedegreetowhichaseparatesystemachievesacertainfunctionalcapa-bility.Itfocusesonthefulfilmentoftherequirementsplacedonthesystem:itdescribestheperformanceofthissystem.
Theintegrationreadinessevaluatesthedegreeoffulfilmentofthefunctionalcapabilityofthecombinationofseveralsystems.Itindicatesthestatusofthesystemascomparedwiththesuperiorsystem:doesitmeetalltherequirementsforbeingintegratedintoasuperiorsystemandsatisfyingitsrequirementsinthisenvironment?
TechnologyreadinessandintegrationreadinessarecomparedandcontrastedinFigure8.
Comparisonoftechnologyreadinessandintegrationreadiness(TRL/IRL)(Fig.8)
TRL–technologyreadinesslevelofasystemAretherequirementsfulfilled?
Withinthesystem–INTRA
Superior system(overall system)
IRL–integrationreadinesslevelofasubordinatesystemintoasuperiorsystem
Aretherequirementsfulfilled?Betweenthesystems–INTER
Subordinate system (sub-system)
Measuring the TRL- Standardised request for the status of the system (e.g. model or fi rst article)- Content / implementation- Comparison of results with DESIRED TRL for each phase (reference)
Focus for TRLLevel considered within the subordinate systemDegree to which requirements are fulfi lled, e.g. - Cooling performance by air-conditioning device- Supplying a defi ned torque
Measuring the IRL- Standardised request for the status of the system (e.g. stand-alone or integrated into superior system) - Content / implementation- Comparison of results with DESIRED IRL for each phase (reference)
Focus for IRLLevel considered between the superior/subordinate systemsDegree to which requirements for integration are fulfi lled e.g. - Taking account of the defi ned accelerations - Compliance with the defi ned construction space by the subordinatesystem
- Superior system defi nes the requirements placed on integration (functional / non-functional)- IRL can be applied between all superior/subordinate systems in the supply chain - Subordinatesystem reports degree of IRL fulfi lment to superior system- Independent view of TRL / IRL is possible only with identical requirements / framework conditions (platform solutions must be validated for all requirements of a new application project)- Changes to the boundary conditions generally lead to changes to systems => new analysis / classifi cation
}{
The readiness level models TRL and IRL
21
Whenthedegreeoffulfilmentismeasured,allrequirementshavetobetakenintoconsider-ation–thenon-functionalrequirementsandthefunctionalonesalike.Therequirementsforintegrationarelargelydefinedbythesuperiorsystem:thesubordinatesystemmustsatisfyboththeserequirementsanditsown,andreportthedegreeoffulfilmenttothesuperiorsys-tem.Therequirementsarisingfromtheintegrationhaveacrucialinfluenceonthedevelop-mentofasubordinatesystem–itsrealisationis,forexample,greatlyaffectedbytheconstruc-tionspaceavailableandtheregulationsthathavetobesatisfied.
Therequirementsplacedonthesubordinatesystemstobeintegratedmustthereforebeknownatthestartoftheirdevelopment.Ifthatisnotthecase,assumptionsarefrequentlyusedinpractice.Iftheassumptionsarenotcorrect,alargenumberofdecisionshavetoberevised–whichasaruleresultsinduplicatedworkandextratime.Innovationsand/orcompo-nentsattechnologyreadinesslevels1and2generallydonotcomeintoquestionforthereali-sationofspecificrailvehicleprojects,butinsteadaredevelopedindependentlyinadvance.
Forasystemtobeallocatedtoareadinesslevelitisnecessarytoanalysethesystemsac-cordingtotheirproperties(e.g.physicalstateoftheproduct,function,component)andtodeterminelevelsoffulfilmentoftherequirements.ThedesiredparametersforthelevelsaregiveninFigure9.Thelevelsareorientedonthegenericproductdevelopmentprocess.Forthisreason,thephasesofthePDPandthoseofthereadinesslevelsareidentical.Thefunctionviewisofspecialimportance:althoughthedevelopmentprocessesofsystemsaremostlybasedonthefunctionalrequirements,whentheyareanalysedtheemphasisisfrequentlyonthecomponentview.However,thereadinesslevelswillbecomparableonlyifconsiderationisgivenbothtothefunctionviewandtothecomponentview.
SpecificclassificationinthedifferentlevelsintheTRLandtheIRLiscarriedoutbasedonachievementofthedesiredresultsand/ortheevidencefortheprocessphasestowhichtheyareallocated(seeFigure9).Thedesiredresultsoftheprocessphasesaredividedintothecate-goriesofthesystem’sstatus(e.g.model,firstsample),thefunctionviewandcomponentview.Thetablealsospecifiesevidenceofachievementofthedesiredresults.
Figure9showsthetablefordeterminingthereadinesslevels.
The readiness level models TRL and IRL
22
The readiness level models TRL and IRL
PrinzipdarstellungzurBestimmungderReifegradstufen(Abb.9)Teil1
PDPdevelopmentphase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physicalstate/conditionsfortesting
Model
Simulation / description
TRL
Leveloftechnologyreadiness
3.1 3.2 3.3 3.4
Functionview
Complete information on interaction (physical, process technology, information, etc.) with other systems (integration), e.g. which accelerations must be taken into consideration Solutions for critical requirementsMain (i.e. crucial) functions are defi ned
Functional structures and principles for all functional requirementsAssignment of function/principles of action to construction elementProduct‘s conceptual design is complete - System draft (multi-domain solution concept)
Defi nition of assurance of properties (validation principle)
Componentview Complete information and description of system attributesLaws, regulations, standards Use profi le, vehicle confi g.Customer‘s special requirementsInterfaces (material, energy, informa-tion) to the construction components to be designed, e.g. structure/space for construction, climate, dynamic, etc.
Construction elements of a functional structure fulfi l requirements placed on this functional structure
Defi nition of assurance of properties (verifi cation / validation principle)
Design of all construction elements is completedAll construction elements are integrated into the systemInteracting elements fulfi l requirements
EvidenceforTRL - Basic vehicle structure („PowerPoint design“) - Clause-by-clause commentary on the requirements of the functional specifi cations - Designation of the relevant main and sub-functions based on EN 15380-4, second level - Description of the deviations pursuant to checklists for „non-functional require-ments“ and „functional requirements“
- Conceptual specifi cations - Overall layout (elaborated vehicle structure)- Installation spaces- Draft total weight- Interface description is available
3-D model (preliminary) - Transfer of all production documents- Approval of circuit diagrams- Approved validation plan incl. rough defi nition of evidence requi-red (type tests)
IRL Levelofintegration
readinessI II.I II.II II.III
Assurance of properties through verifi cation and validation (scope for stand-alone systems)
Assurance of properties through verifi cation / validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior systemTest is not integrated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;
Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Testing under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi c operation
4 5 6 / 7 8 9
Evidence of fulfi lment of all functional requirements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all functional requirements (static)
Evidence of fulfi lment of all functional requirements (dynamic)
Evidence of fulfi lment of all functional requirements (approval / acceptance)
Evidence of fulfi lment of all functional requirements (operational deployment)
Evidence of fulfi lment of all requirements placed on construction elements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all requirements placed on construction elements (static)
Evidence of fulfi lment of all requirements placed on construction elements (dynamic)
Evidence of fulfi lment of all requirements placed on construction elements(approval / acceptance)
Evidence of fulfi lment of all requirements placed on construction elements (operational deployment)
Evidence of fulfi lment of requirements placed on sub-ordinate system (FAI report)
Type test reports (prior to integration)
Type test reports (integration - static)
Type test reports (integration - dynamic)
Commissioning approvalApproval certifi cate Acceptance reports
No reports of necessary design modifi cations within one annual cycle
III IV.I IV.II IV.III V
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/first
articleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Issueofcommissioning
approval
Operation/warranty
ments“ and „functional requirements“
IRL Levelofintegration
readinessI II.I II.II II.III
Please note: The second part of the table is shown on the next two pages.
Separate detailed view available at www.bahnindustrie.info
23
The readiness level models TRL and IRL
PDPdevelopmentphase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physicalstate/conditionsfortesting
Model
Simulation / description
TRL
Leveloftechnologyreadiness
3.1 3.2 3.3 3.4
Functionview
Complete information on interaction (physical, process technology, information, etc.) with other systems (integration), e.g. which accelerations must be taken into consideration Solutions for critical requirementsMain (i.e. crucial) functions are defi ned
Functional structures and principles for all functional requirementsAssignment of function/principles of action to construction elementProduct‘s conceptual design is complete - System draft (multi-domain solution concept)
Defi nition of assurance of properties (validation principle)
Componentview Complete information and description of system attributesLaws, regulations, standards Use profi le, vehicle confi g.Customer‘s special requirementsInterfaces (material, energy, informa-tion) to the construction components to be designed, e.g. structure/space for construction, climate, dynamic, etc.
Construction elements of a functional structure fulfi l requirements placed on this functional structure
Defi nition of assurance of properties (verifi cation / validation principle)
Design of all construction elements is completedAll construction elements are integrated into the systemInteracting elements fulfi l requirements
EvidenceforTRL - Basic vehicle structure („PowerPoint design“) - Clause-by-clause commentary on the requirements of the functional specifi cations - Designation of the relevant main and sub-functions based on EN 15380-4, second level - Description of the deviations pursuant to checklists for „non-functional require-ments“ and „functional requirements“
- Conceptual specifi cations - Overall layout (elaborated vehicle structure)- Installation spaces- Draft total weight- Interface description is available
3-D model (preliminary) - Transfer of all production documents- Approval of circuit diagrams- Approved validation plan incl. rough defi nition of evidence requi-red (type tests)
IRL Levelofintegration
readinessI II.I II.II II.III
Assurance of properties through verifi cation and validation (scope for stand-alone systems)
Assurance of properties through verifi cation / validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior systemTest is not integrated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;
Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Testing under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi c operation
4 5 6 / 7 8 9
Evidence of fulfi lment of all functional requirements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all functional requirements (static)
Evidence of fulfi lment of all functional requirements (dynamic)
Evidence of fulfi lment of all functional requirements (approval / acceptance)
Evidence of fulfi lment of all functional requirements (operational deployment)
Evidence of fulfi lment of all requirements placed on construction elements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all requirements placed on construction elements (static)
Evidence of fulfi lment of all requirements placed on construction elements (dynamic)
Evidence of fulfi lment of all requirements placed on construction elements(approval / acceptance)
Evidence of fulfi lment of all requirements placed on construction elements (operational deployment)
Evidence of fulfi lment of requirements placed on sub-ordinate system (FAI report)
Type test reports (prior to integration)
Type test reports (integration - static)
Type test reports (integration - dynamic)
Commissioning approvalApproval certifi cate Acceptance reports
No reports of necessary design modifi cations within one annual cycle
III IV.I IV.II IV.III V
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/first
articleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Issueofcommissioning
approval
Operation/warranty
III IV.I IV.II IV.III V
24
The readiness level models TRL and IRL
Schematicdiagramofdeterminationofreadinesslevels(Fig.9)Part2
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/first
articleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Issueofcommissioning
approval
Operation/warranty
PDPdevelopmentphase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physicalstate/conditionsfortesting
Model
Simulation / description
TRL Leveloftechnology
readiness3.1 3.2 3.3 3.4
IRL
Levelofintegrationreadiness
I II.I II.II II.III
Functionview
Multi-system functions are defi ned and main functions are distributed (which system does what?)
Multi-system functions are defi ned and main functions are distributed (which system does what?)
All overarching functions are fulfi lled
Componentview(interface-materialenergyinformation)
Determination of interfaces (material, energy, information)and interaction (physical, process technology, etc.)
Generation of complete information for subordinate systemfunctional requirements;non-functional requirements and attributes:laws, regulations, standards, use profi le, vehicle confi g. Customer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction components to be designed, e.g. construction concept/space, climate, dynamic, etc.
Detailed defi nition of interfaces for elements of the specifi c phase;Description of the data interfaces for sub-systems characterised by complex software and feedback loops to circuit diagram of train and/or between the systems. Software (Train Control Monitoring System, TCMS) can be implemen-ted later in a separate cycle
Detailed defi nition of all interfaces
EvidenceforIRL Description of deviations pursuant to checklists „non-functional /functional requirements“
Tech. Specifi cations available for procuring elements and subordinate system (incl. interface description)
Approval of interfaces (protocols)
Approval of data interfaces (reports)
Assurance of properties through verifi cation and validation (scope for stand-alone systems) Assurance of properties through verifi cation / validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior system
Test is not integrated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);
Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;
Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Testing under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi coperation
4 5 6 / 7 8 9
III IV.I IV.II IV.III V
Defi ned input from superior system triggers defi ned function in non-integrated subordinate system (test environment, e.g. signal on pin x triggers door opening)
Defi ned interaction fulfi ls / triggers defi ned function / feedback from the subordinate system
From the viewpoint of subordinate system, test of connection to superior system and other systems
Fulfi lment of requirements placed on interaction
Report (FAI) Type test report (static) Type test report (dynamic) Commissioning approvalApproval certifi cate Acceptance report
No reports of necessary design modifi cations within one annual cycle
25
The readiness level models TRL and IRL
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/first
articleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Issueofcommissioning
approval
Operation/warranty
PDPdevelopmentphase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physicalstate/conditionsfortesting
Model
Simulation / description
TRL Leveloftechnology
readiness3.1 3.2 3.3 3.4
IRL
Levelofintegrationreadiness
I II.I II.II II.III
Functionview
Multi-system functions are defi ned and main functions are distributed (which system does what?)
Multi-system functions are defi ned and main functions are distributed (which system does what?)
All overarching functions are fulfi lled
Componentview(interface-materialenergyinformation)
Determination of interfaces (material, energy, information)and interaction (physical, process technology, etc.)
Generation of complete information for subordinate systemfunctional requirements;non-functional requirements and attributes:laws, regulations, standards, use profi le, vehicle confi g. Customer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction components to be designed, e.g. construction concept/space, climate, dynamic, etc.
Detailed defi nition of interfaces for elements of the specifi c phase;Description of the data interfaces for sub-systems characterised by complex software and feedback loops to circuit diagram of train and/or between the systems. Software (Train Control Monitoring System, TCMS) can be implemen-ted later in a separate cycle
Detailed defi nition of all interfaces
EvidenceforIRL Description of deviations pursuant to checklists „non-functional /functional requirements“
Tech. Specifi cations available for procuring elements and subordinate system (incl. interface description)
Approval of interfaces (protocols)
Approval of data interfaces (reports)
Assurance of properties through verifi cation and validation (scope for stand-alone systems) Assurance of properties through verifi cation / validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior system
Test is not integrated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);
Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;
Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Testing under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi coperation
4 5 6 / 7 8 9
III IV.I IV.II IV.III V
Defi ned input from superior system triggers defi ned function in non-integrated subordinate system (test environment, e.g. signal on pin x triggers door opening)
Defi ned interaction fulfi ls / triggers defi ned function / feedback from the subordinate system
From the viewpoint of subordinate system, test of connection to superior system and other systems
Fulfi lment of requirements placed on interaction
Report (FAI) Type test report (static) Type test report (dynamic) Commissioning approvalApproval certifi cate Acceptance report
No reports of necessary design modifi cations within one annual cycle
26
3.3Phaseassignmentfordesiredresultsandreadinesslevelsofthereferenceprocess(PDP)
Simplificationsweremadeduringdefinitionofthedesiredphase-specificresultsofthereferenceprocess.Theyrelatetoassignmentofthedesireddevelopmentcontent,thedesiredlevelsoftechnologyreadinessandthedesiredlevelsofintegrationreadinesstotheindividualphases.
Forthephases,thereferenceprocessdeterminesthedesiredresultsinthecategoriesandthelevelsofdesiredtechnologyandintegrationreadiness.ThereadinesslevelsoftheTRLandtheIRLaresynchronisedwiththeindividualphases,eventhoughtheanalysesdiffer,asdotheclassificationsinlevels.Theboundaryconditionsforintegration–suchasthedeterminationofconstructionspaces–areanimportantinputforthedevelopmentofasubordinatesystemandhavetobeavailablewhenitsdevelopmentcommences.
Thedegreesoffulfilmentofthedesiredresultsoftechnologyandintegrationreadinessareexaminedduringtheclarificationphase,andformthebasisforassignmenttotherelevantIRLorTRLlevels.Forexample,ifasystemdoesnotachievethedesiredresultforaTRLlevel,itdoesnotreachtherespectivereadinesslevelintheTRL.TRLanalysisisindependentofassignmenttotheIRL.IfthedesiredresultsfortheIRLareachieved,thesystemanalysedreachestherespectivereadinesslevelintheIRL.Theneedforaction–forinstanceselectingtherequiredQEactions–isorientedonthelowestlevelofreadinessineachcase.
Comparisonofthedevelopmentprocessstatuswiththereferenceprocessallowsthoseelementstobeidentifiedthatexhibitthelowestlevelofreadiness.ThisenablestargetedQEactionstobetakenthatassuretheachievementofhigherlevelsofreadiness.
Itshouldbenotedthatalowlevelofreadinessisnotnecessarilyassociatedwithahighrisktotheachievementofgoals:theriskisderivedfromtheeffortneededineachcaseforimple-mentingthenecessaryqualityengineeringactions(quantity,type,scope).Thedifficulty,thecomplexityandtheriskofthenecessaryQEactionsaredeterminedbythespecificcontentthatisnecessaryforattainingthegoalofthehigherlevelofreadiness.
Iftherequirementschangeduringthedevelopmentprocess,thesameprocedureshouldbeappliedasfortheanalysis.Inthiscase,thoseelementsofasystemhavetobeidentifiedwhichhavebeenalteredand/orareinfluencedbythechange.AssignmenttotherelevantprocessphasesorTRL/IRLlevelsusesthesamecriteriaasintheoriginalanalysis.Changestotheconceptusuallyleadtore-classificationatalowerTRLorIRL.Re-classificationiscarriedoutinthoselevelswherethechangesweremade.
Phase assignment of desired results and PDP readiness levels
27
3.4Analysisofsystemsforcreatingcomparability
Theanalysisofthenon-functionalrequirementsaimstoidentifyanyrelevantspecialattrib-utesanddeviationsbymeansofsystematicqueryandthustoensurethatthesepointsaretakenintoconsiderationinthedesignprocess.
Thedegreeoffulfilmentofthecriteriafortheindividuallevelsisdeterminedbyanalysisofthesystems’developmentstatus.Thebasisforthisisthefunctionviewandcomponentviewoftherespectivesystem.ThisprocedurecorrespondstoEN15380-2(componentview)andEN15380-4(functionview).
Differentanalysesrequiredifferentviewsofthesystems–theirreliabilitycanonlybecalcu-latedtheoretically,forexample,usingelementsfrombothviews:thelinkagesbetweenthecomponentsarederivedfromthefunctionalstructure,whereasthereliabilityoftheindivid-ualcomponentsisdeterminedbythecomponentsthemselves.Systemsconstructedfromidenticalcomponentsthatarelinkedwithoneanotherindifferentwayswillexhibitdifferentreliabilityvalues.Componentswithredundantlinksgenerallyhavegreaterreliabilitythancomponentsconnectedinseries.
Similarconsiderationsarerequiredforthecomparabilityofsystems.Thefunctionalstructureofasystemisofmajorimportanceforitstransferabilitytoanewsystemasareferencesystem.Ifthefunctionalstructureofasystemischangedwhilethecomponentsremainiden-tical,theempiricalvaluesfromoperationaldeploymentcanbetransferredtothenewsystemonlytoalimiteddegree.
Whenatried-and-testedsystem(referencesystem)isadoptedasthebasisforanewsystemwhoserequirementshavebeenaltered,theeffectsofthesechangeshavetobesubjectedtoastructuredanalysis.Theempiricalvaluesfromoperationofthereferencesystemcanbecomparedwithandtransferredtothenewsystemonlyaftertheanalysishasbeencarriedout.TheprocessstepsinthefunctionalsystemanalysisaccordingtoEN15380-2andEN15380-4areshowninFigure10.Thefunctionalstructuresandthemechanismsofopera-tionofthemainfunctionsareanalysedandpresentedstartingfromthefunctionview.Themainfunctionsofasystemarethecrucialfunctions.Thefunctionsofrailvehiclesarestruc-turedanddefinedinEN15380-4.Onthebasisoftheanalysis,theexistingsystemiscomparedwiththenewsystem.Ifdifferencesarefoundinthefunctionalstructureandthemechanismsofoperation,furtheranalysesarerequired.
Analysis of systems for creating comparability
28
Basedonthefunctionalanalyses,theelements/componentscanbeassignedtothemecha-nismsofaction–thisisthepointwherethefunctionviewandtheproductviewarelinkedtogether.
Thefunctionalstructureisamajorfoundationforthemethodologicaldesignandthevalueanalysisofsystems.TheVDIguidelines2206and2221,whichdescribethedesignprocessforsystems,arealsobasedonfunctionalstructures.
3.4.1 Structuring requirements – functional and non-functional
Structuringaccordingtofunctionalandnon-functionalrequirementsfacilitatestheanalysisofsystems.Systemstheoryprovidesthefollowingdefinition:thefunctionofsystemscon-sistsoftransformingtheinputquantities(material,energy,information)intothenewoutputquantities(material,energy,information),takingintoaccountstatevariables.Themainfunc-tions(theessentialfunctionsaccordingtoEN15380)areusedforcomparingsystems.Theyserveasthestartingpointwhensystemsarebeingdeveloped.
Besidethefunctionalrequirements,everyproducthavetofulfilnon-functionalrequirementsaswell.Theydescribetheboundaryconditionsunderwhichafunctionisperformedandwhichpropertiesthesystemhastohave.
Analysisfromthefunctionandcomponentviews.Theproductstructureresultsfromthephysicalimplementationofthefunctionalstructure(Fig.10)
Functional system analysis EN 15380-2 / 4- Creating comparability between
new system and reference system through function and component analysis
Analysis of functional structure’s deviation from reference system / process
EN 15380-4 Functional Breakdown Structure (FBS)
Main functions
Product / Component
Assignment
Operating principle
Component
Functional structure
Operating principle
EN 15380-2 Product Breakdown Structure (PBS)
Analysis of component’s deviation from reference system / process
Functionview Productview
Structuring requirements – functional and non-functional
29
Railwayvehiclesystemscanbecomparedaccordingtothefollowingschemeinrelationtohowthenon-functionalrequirementsareorganised:
• Standards,regulations,approval • Useprofile,configuration • Additionalspecificrequirementsoftheoperatorsorcustomers • Provisionsforintegration(mechanics,physics,electricalsystems,control)3.4.2 Structure and types of checklists
Checklistsallowsystemstobeanalysedaccordingtopre-setcategories.Thepre-definedstructureofthechecklistsensuresthatthemanufacturershavetorespondonalltherelevantaspects.Thismeansthesystemscanbemadecomparable.Furthermore,checklistsencouragetheteamstotacklethetopicsactively.Thechecklistsarefilledoutbytherespectivemanufacturersordevelopersofthesystemswhoarealsoresponsibleforforwardingtheinformationtothesuperiorsystem.Thestructureofthechecklistscorrespondstothefunctionalandnon-functionalanalysis.ItisshowninFigure11.
Thisstructuredanalysisofsystemsallowsdeviationstobeidentifiedanddescribed–itformsthebasisforclassificationtothelevelsofreadiness.Actionsforassuringtheobjectivesarederivedfromtheanalysisandareassignedtothephasesoftheproductdesignprocess(PDP).
Structureofthechecklists(Fig.11)
Referencesystem- Designation- Number of installed systems- TRL - IRL - Available fi ndings
Non-functionalrequirements(boundaryconditions/properties)- Standards / regulations / approval- Use profi le / confi guration- Additional, specifi c requirements of operator / customer - Integration (physics / mechanics / electrical systems / control)
Analyses- Deviations - Non-functional - Functional- Phase of deviation from reference process
Functionalrequirement- Fulfi lment of functions of the systems is compared with EN 15380-4- Assignment of components (EN 15380-2) to functions and operating principles
Results- Classifi cation of elements in TRL / IRL- Identifi cation of elements with the lowest levels of readiness / greatest input / risk to achieving objectives - QE action plan with assignment to phases- Consolidation on overall system level - Elements with lowest level of readiness (TRL / IRL) - Number of elements needing QE actions
Structure and types of checklists
30
3.4.2.1 Non-functional checklist
Non-functional checklist
Separatedetailedviewavailableatwww.bahnindustrie.info
Prinzipdarstellung der nicht-funktionalen Checkliste (Abb. 12)
View of superior- system (e.g. vehicle ET 4xx)
Reference system (superior system): Please note: fi ll this section out only if the reference system is relevant, e.g. if a similar product is to be used in a modifi ed form
System designation xx Field experience xx
Project xx Critical topics xx
Realisation period xx TRL [3-9] xx
Number of items xx IRL [1-5] xx
Description of the deviations between the reference system (superior system) and the system to be analysed (superior system), which infl uence development of the subordinate system
Classifi cation of deviations: [u] - identical /unimportant; [d] - marked; [g] - fundamental
Deviations from stan-dards / regulations / approval
Deviations from use pro-fi le/ confi guration
Deviations from additional, specifi c requirements, e.g. from operator / customer
Input aus übergeordnetem System
Zu analysierendes (untergeordnetes) System
Bezugsystem
Normen / Vorschriften/ Zulassung
Einsatzprofi l / Konfi guration
Spezifi sche Anforderungen
Integration- Mechanik- Elektrik- FZ-Steuerung
Erkenntnisse nutzen- Betriebserfahrung- Lessons Learned
Findings
Category Topic Specifi c description
Operating experience
Lessons learned
E.g. fi ndings from the development process in previous projects
View of subordinate system to be analysed (e.g. door system, coupling system, etc.)
Reference system Please note: the reference system should be as similar as possible to the new system. Deviations are measured between the reference system and the new system.If no suitable reference system is selected, it should be checked whether the required information for developing the system is available. Current technology should provide orientation.
System designation xx Field experience xx
Project xx Critical topics xx
Realisation period xx TRL [3-9] xx
Number of items xx IRL [1-5] xx
Analysis of specifi cations, deviation, lack of non-functional requirements
Description - Designating the signifi cant non-functional requirements (e.g. approval standard) that are necessary so that the system can be developed- Deviations in the non-functional requirements between the reference system (e.g. door system from Project x) and the (new) system to be analysed, which infl uence the development of the (new) system to be analysed - Information missing on non-functional requirements that are necessary so that the system can be developed
Classifi cation of deviations / missing data: [u] - identical /unimportant; [d] - marked; [g] - fundamental
Designation, deviation, lack of required infor-mation on standards / regulations / approvale.g. TSI, fi re protection, etc.
Designation, deviation, lack of required information onuse profi le / confi guration
Designation, deviation, lack of required informa-tion on additional specifi c requirements of the operator / customere.g. customer‘s operating equipment, same parts as in x, interchangeable with y, etc.
Analysis of specifi cations, deviation, lack of non-functional requirements for integration
Designation, deviation, lack of required infor-mation on integration of mechanics,e.g. dimensions, installa-tion spaces, forces, mo-ments, output, clearance gauge, etc.
Designation, deviation, lack of required infor-mation on integration of electrical systems,e.g. voltage, currents, energy requirement
Designation, deviation, lack of required informati-on on integration of phy-sics (not incl. mechanics) e.g. acoustics, thermal currents, sensor system, compressed air, etc.
Designation, deviation, lack of required infor-mation on integration of controle.g. human-machine, sensor signals, BUS protocol, data format
Schematicdiagramofnon-functionalchecklist(Fig.12)
Input from superior system
(Subordinate) system to be analysed
Reference system
Standards / regulations /approval
Use profi le / confi guration
Specifi c requirements
Integration- Mechanics - Electrical systems- Vehicle control
Using fi ndings- Operating experience - Lessons learned
31
Thenon-functionalchecklist(Figure12)isdividedintothreesections(“Superiorsystem”,“Subordinatesystem”and“Findings”).Inthefirstsectionthesuperiorsystemisanalysed.Thefirstcheckiswhetherareferencesystemforitexists,whichexhibitsahighlevelofagree-mentwiththenewsuperiorsystem.Ifsuchareferencesystemcanbeidentified,itsessentialdataaretoberecorded.Thesecondcheckisonwhetherdeviationsintheareasofstandards,regulationsandapprovalexistintheuseprofileandtheconfiguration,orinadditionalspecificrequirementsoftheoperatororthecustomers.Thisisnecessary,forexample,whenanentirerailvehicleistobeadoptedforuseinanewsystem.
Changestothenon-functionalrequirements–forinstanceintheapprovalregulationsortheregionofdeployment–mayrenderitimpossibletotransferthereadinesslevelsoftherefer-encesystemtothenewsystem.Thedeviationsshouldthereforeberecordedandanalysed.
Thesecondsectionofthechecklistconsidersthenewsubordinatesystemthatistobean-alysed.Here,too,acheckisrunonwhetherareferencesystemforitexistswhichhasahighlevelofagreement.Thisisoftenthepredecessorsystemthatisintendedeithertobeusedortoundergoevolutionarydevelopmentinthenewsystem.Thedecisiontouseareferencesystemisoffar-reachingimportanceandhastotakethemanufacturer’sproductstrategyintoaccount.Oncethereferencesystemhasbeenselected,therelevantinformationshouldbeenteredinthechecklist.
Inthenextstepthesignificantnon-functionalrequirements(e.g.approvalstandards)aresetforth,whicharerequiredfordevelopmentofthesystem.Thisisfollowedbyananalysisofthedeviationsbetweenthenewsystemandthereferencesystem.However,onemaydiscoverthatsomeinformationaboutthenon-functionalrequirementsplacedonthesystemismiss-ing.Thestructuredqueryiscarriedoutinlinewiththeabove-mentionedtopics:
• Standards,regulations,approval • Useprofile/configuration • Additional,specificrequirementsoftheoperatororthecustomers • Integration: oMechanics oElectricalsystems oPhysics(notincludingmechanics) oControl
Ifnoreferencesystemisselected,itshouldbecheckedwhetherthemostimportantinfor-mationfordevelopmentofthenewsystemisavailable.Thechecklisthavetocontainde-scriptionsbothofthisinformationandofmissinginformation.Theitemstobeincludedinthechecklistareselectedbasedoncurrenttechnology:thoseitemsshouldbedescribedthatdeviatefromthestateoftheart.Apartfromthedescriptionofthedeviationsand/orthemissinginformationaboutthenon-functionalrequirements,eachofthedeviationsshouldbeclassifiedas“identical/unimportant”,“marked”or“fundamental”.
Theavailablefindingsarerecordedinthethirdsection.Thequeryisdividedintothetopicsof“Errorevents”and“Lessonslearned”.Thelessonslearnedaregenerallybasedoncompa-ny-specificknow-howthatthecompanieswishtoprotect–forthisreasonthesefindingsare
Non-functional checklist
32
recordedinthesystem-specificchecklist.Itisintendedtohelpinusingtheavailablefindingsduringdevelopmentofthesystem.
UsingfindingsThepurposeofchecklistsistosystematicallyrecordexperiencesfromprojectsandtofeeditintothedevelopmentprocesswhilegivingconsiderationtocompetition-relatedaspects(e.g.protectionofknow-how,locationofthecompetition)andsensitivedatahandling.Itisinsuf-ficienttolimitthistothepureengineeringphasesasfarascompletionofthe“Finaldesign”processphase,becausesomekeyfindingsconcerningtheeffectivenessoftheengineeringareonlymadeduringverification,whenapprovalisissued,orasaresultofexperienceincontinu-ousoperation.
3.4.2.2 Functional checklist
ThefunctionalanalysisofsystemsisakeyelementintheQEprocessmodelandforms,amongotherthings,thefoundationforcomparingvarioussystemconcepts.Inordertocreatecomparabilityandconductafunctionalanalysis,allthemainfunctionsoftherelevantsystemshavetobetakenintoconsideration–evenifsomequestionsremainunanswered.ApplicationofEN15380-4ensuresthatthisisthecase.Itliststhosefunctionsthatshouldbefulfilledforeachoftherelevantrailvehiclesystems.
Themainfunctionsaredeterminedinafirststep.Basedonthefunctionalstructuresofthesystems,themainfunctionsarethencomparedwiththedefinedfunctionstakenfromthestandard.Itshouldbeensuredthatalltherelevantfunctionsofeachsystem,whicharelistedinthestandard,arefulfilledbythedesignatedfunctionsorfunctionalstructuresofthesys-tem.Thisprocedurealsoallowssystemswithdifferentapproachestofindingsolutionstobecomparedintermsoftheirfulfilmentoffunctionsandtheirlevelsofreadiness.
TheVDIguidelines2206,2221and2803alsodescribehowfunctionsarefulfilledbyseveralfunctionsandsub-functions.Theyrepresentthefunctionalstructures.Thesefunctionalstruc-turesarerealisedbyactivestructures–thatis,byphysical,chemicalorothereffectsandtheirstructures.Theactivestructuresdeterminetheelements,partsorcomponentswhichcanbeusedtorealisetheactivestructuresandthefunctionalstructures.Severalelementstakentogethercanberegardedaselementstructures.Functionsarerealisedeitherbyelementsorbyelementstructures.
Thefunctionalanalysisofthesystemsfollowsthemethodologydescribedintheguidelinesandisreflectedinthefunctionalchecklist(Figure13).Comparisonofthesystems–thatis,ofthenewsystemwiththereferencesystem–iscarriedoutonthisbasis:firstofallthereisacheckonwhetherthefunctionsfromthestandardarefulfilledforthespecificsystemandwhetherthefunctionalstructuresmatch.Thisisdoneinthesystem’sfunctionview.Anyde-viationsshouldbedetailedinthechecklist.Thenthecomponentsthatrealisethefunctionalstructuresarecompared.Thisisdoneinthecomponentviewofthesystem.Thenextstepconsistsofanevaluationofthedeviationsfromthefunctionandcomponentviews.Thedeviationsareclassifiedinthespecifiedlevels“identical/unimportant”,“marked”or“fundamental”.AssignmenttotheTRLorIRLreadinesslevelsfollowstheproceduredescribedinsection3.2.
functional checklist
33
Sche
mat
icd
iagr
amo
ffun
ctio
nalc
heck
list–
exa
mpl
e(F
ig.1
3)
Func
tiona
lana
lysi
sofd
oors
yste
m
base
don
EN
1538
0-4
Iden
tific
atio
nan
dde
sign
atio
nof
mai
nfu
nctio
ns
Crite
rion
form
ain
func
tion:
cruc
ialt
ofu
lfilli
ng
purp
ose
Iden
tific
atio
nan
dde
sign
atio
nof
rele
vant
su
b-fu
nctio
ns
Crite
rion
forr
elev
ance
:ne
cess
ary
forf
ulfil
ling
mai
nfu
nctio
n
Func
tiona
lstr
uctu
re
and
oper
atin
gpr
inci
ple
Cons
truc
tion
elem
ents
real
isin
gth
efu
nctio
nal
stru
ctur
e
Devi
atio
nbe
twee
nre
fere
nce
syst
ema
nd
(new
)sys
tem
tob
ean
alys
ed(fu
nctio
nan
dco
nst-
ruct
ion
elem
ent)
Devi
atio
nca
tego
ry
-Fun
ctio
nals
truc
ture
,o
pera
ting
prin
cipl
e
Devi
atio
nm
easu
re-
men
t-I
dent
ical
/un
impo
r-ta
nt[u
]-M
arke
d[d
]-F
unda
men
tal[
g]
Devi
atio
nca
tego
ry-C
onst
ruct
ion
elem
ent
Devi
atio
nm
easu
re-
men
t-I
dent
ical
/un
impo
r-ta
nt[u
]-M
arke
d[d
]-F
unda
men
tal[
g]
TRLc
lass
ifica
tion
(atw
hich
leve
lare
de
cisi
onsm
ade
abou
tth
eob
ject
of
dev
iatio
n)
IRLc
lass
ifica
tion
(atw
hich
leve
lar
ede
cisi
onsm
ade
abou
tthe
obj
ect
ofd
evia
tion)
E(O
pera
te d
oor s
yste
m)
x...
......
......
...
F(B
olt o
utsi
de d
oor)
x...
......
......
...
GU
nbol
t out
side
doo
rx
......
......
......
HEn
able
out
side
doo
r ope
ning
x...
......
......
...
JPl
an e
ntra
nce
illum
inat
ion
x...
Perm
anen
t ele
ctric
al
cont
act "
1" to
cont
rol
Elec
trom
echa
nica
l sw
itch
- El
ectr
ic p
art
Elec
tric
switc
h fr
om
door
syst
em x
with
TR
L 9 a
nd IR
L 5
Func
tiona
l st
ruct
ure
[u]
Part
[u]
4III
KBl
ock
outs
ide
door
sx
Bloc
k do
orCe
ntra
l rot
ary
switc
h -
tran
sfer
red
by B
ow-
den
cabl
e to
bol
ting
artic
ulat
ion
Elec
trom
echa
nica
l sw
itch
- Mec
hani
cal
part
Bow
den
cabl
e Ki
nem
atic
s In
tegr
atio
n in
to
bolti
ng a
rtic
ulat
ion
New
par
tFu
nctio
nal
stru
ctur
e [u
]Pa
rt [g
]3.
1I
Bolt
door
secu
rely
Cent
ral r
otar
y sw
itch
- tr
ansf
erre
d by
Bow
-de
n ca
ble
to b
oltin
g po
int o
n lo
wer
par
t of
door
leaf
Elec
trom
echa
nica
l sw
itch
- Mec
hani
cal
part
Bow
den
cabl
e Ki
nem
atic
s In
tegr
atio
n in
to
bolti
ng p
oint
New
par
tFu
nctio
nal
stru
ctur
e [u
]Pa
rt [g
]3.
1I
Sepa
rate
det
aile
d vi
ew a
vaila
ble
at w
ww
.bah
nind
ustr
ie.in
fo
34
Theanalysismakesitpossibletoassignlevelsofreadinesstotheelementsofasystemandonthisbasistoassureactionsforachievingobjectives.Itisalsopossibletocomparesystemsbasedonthelevelsofreadiness.Theprocedureforthisisdescribedinsection3.7.
3.5QEmethodsforassuringspecificphaseresults
Acoreelementinthequalitypartnershipfordevelopingrailvehiclesistheprocessmodelfordeterminingtheneedforqualityassurance–alwaystakingthestateofdevelopmentintoaccount–sothatitsapplicationcanbeconcentratedontherelevantpartsofdevelopment.
Figure15indicatessuitablemethodsforpreventiveactiontoassurethedesiredresults,basedonthedeviationsofthesystemtobeanalysedfromthereferenceprocessorthereferencesystemintherelevantcategoriesofthephaseandoftheTRL/IRL.Therecommendedmethodsarequalityengineeringmethodsthathavealreadybeenputintopractice.Theyarethereforenotdescribedindetailinthisguideline.Thecategories,phasesanddeviationscorrespondtotheclassificationofthereadinesslevelsinFigure9insection3.2,whichfacilitatesnavigationwithinthetable.
3.6QEactionplan:determiningactionsforassuringresults
TheQEprocessmodelconcentratesonassuringtheachievementofobjectivesduringtheproductdesignofrailvehiclesand/ortheirsub-systemsandcomponents.ThisisdonebydeterminingspecificQEactionsonthebasisofthephase-specificdeviationofasystemfromthereferenceprocess.Section3.4setsoutthenecessaryanalysesfromthefunctionandcom-ponentviews.
TherecommendationofQEmethodsforassuringspecificphaseresultsisgiveninsection3.5.Themanufacturers/developersofasystemusethisasafoundationfordeterminingtheactionstoassuretheresults.SelectionofthemethodsistheirresponsibilityandtheQEactionplanindicatesthemethodselectionforeachphase.
TheQEactionplanshowstheneedforQEactionsandtheassociatedrisksforasystemallthewaytoitsfinalcompletion.Itformsthebasisforreportingthestatusofasubordinatesystemtothesuperiorsystem.Progressistrackeduponcompletionofeveryphasebetweenthesuperiorandthesubordinatesystems.Thesubordinatesystemisresponsibleforprovidingtheinformation.Figure14showsthegenericstructureoftheQEactionplan.
Qe methods and qe action plan
35
Dete
rmin
atio
nof
QE
actio
nsd
epen
ding
on
devi
atio
n(p
hase
and
cate
gory
)(Fi
g.14
)
TRL
IRL
Tend
er/
clar
ifica
tion
Conc
ept
Inte
rmed
iate
de
sign
Fina
ldes
ign
Prod
uctio
nTy
pete
stp
riort
oin
te-
grat
ion
/firs
tart
icle
insp
ectio
n(F
AI)
Stat
ic
com
mis
sion
ing
Dyna
mic
co
mm
issi
onin
gAu
thor
isat
ion
for
plac
ing
the
vehi
cle
in
serv
ice
/acc
epta
nce
Ope
ratio
n/w
arra
nty
3.1
I
3.2
II
3.3
III.I
3.4
III.II
4III
.III
5IV
.I
6IV
.II
7IV
.II
8IV
.III
9V D
esire
d re
adin
ess l
evel
(TRL
or I
RL) a
ccor
ding
to re
fere
nce
proc
ess
Des
crip
tion
of Q
E ac
tions
for a
ssur
ing
achi
evem
ent
of th
e ne
cess
ary
read
ines
s lev
el- S
elec
tion
from
the
reco
mm
ende
d ac
tions
- A
dditi
onal
nee
ds-b
ased
act
ions
- T
empo
ral a
ssig
nmen
t in
phas
es
Des
ired
stat
e of
a sy
stem
prio
r to
inte
grat
ion
in su
perio
r sys
tem
(T
RL 3
.4, I
RL 3
.2)
Syst
em q
ualifi
cat
ion
poss
ibly
bro
ught
fo
rwar
d du
e to
test
ing
in si
mila
r ove
rall
syst
ems (
TRL 6
, IRL
4.2
)
Sepa
rate
det
aile
d vi
ew a
vaila
ble
at w
ww
.bah
nind
ustr
ie.in
fo
36
Qe methods and qe action plan
RecommendationofsuitableQEmethods(Fig.15)
Phase Tender/clarification
TRL 3.1
IRL
Function/componentview TRLfunctionview TRLcomponentview
Specificdeviation
Complete information on interaction (physical, process technology, information, etc.) with other systems (integration)
Solutions for critical requirements Main functions are defi ned
Complete information: laws, regulations, standards,use profi le, vehicle confi gurationcustomer‘s special requirements for interfaces (material, energy, information) placed on the parts to be designed, e.g. construction space, environment, dynamic, etc.
SuitableQEmethods
Requirements engineering x x
Checklists Non-functional requirements Functional requirements
x x
Use case x x
Systematic description of functions and system (e.g. Unifi ed Modeling Language, UML)
x x
Quality Function Deployment (QFD) x x
Modelling and analysis of the system in relation to: - Dynamics- Warming up- Stray fi elds- EMC- Vibration noise, etc.
FMEA
Virtual prototyping / 3-D model
Software in the loop simulation
Hardware in the loop simulation / Iron Bird
Special tests: sturdiness, rigidity, endurance strength, pressure, tight-ness, emissions (liquid, gas, waves/ vibrations, e.g. sound, EMC, etc.)
Separate detailed view available at www.bahnindustrie.info
37
Qe methods and qe action plan
Categories of specifi c deviations of the system to be analysed from reference process / reference system- Phase of deviation- Type of deviation (technology readiness / integration readiness)
Tender/clarification Concept
3.2
I II.I
IRLfunctionview IRLcomponentview TRLfunctionview IRLfunctionview
Multi-system functions: Dividing up main functions (which system does what?)
Defi nition of interfaces (material, energy, information)and interaction (physical, chemical, process technology, etc.)
Functional structures and operating principles for all functional requirementsAssignment of function/operating principle Part – Product‘s conceptual design is complete
Multi-system functions:Defi nition of all functions (incl. ancillary and derived functions), functional structures and operating principles
x x x x
x x x x
x x
x x
x x x
x x
x x
38
3.7Presentationofsystems’statusbasedonreadinesslevels
Asarule,theelementswiththelowestlevelofreadinessandrequiringthemosteffortforachievingtheobjectivesalsorepresentthehighestrisks(criticalpathofadevelopment).Thenumberofelementswithalowlevelofreadinessandahighlevelofdevelopmenteffortisalsoofparticularsignificancewhenitcomestoestimatingthetotalrisk.Forinstance,twosystemsarecompared,whichhavetofulfileightmainfunctionspursuanttoEN15380-4.Oneconstructionelementstructureinonesystemexhibitsalowlevelofreadinessforonemainfunction.Intheothersystem,sixelementstructuresexhibitalowlevelofreadinessforthemainfunctionsandeachonerequiresahighdegreeofeffort.Theeffortforrealisingtheelementstructureswiththelowestlevelsofreadinessisthesameforbothsystems.Yettherisktoachievingrealisationishigherforthesystemwithseveralelementstructureswithlowlevelsofreadiness.
TheQEprocessmodeltakesthissituationintoaccount.Itindicatesnotonlythecomponentstructureswiththelowestlevelofreadinessbutalsothenumberandlevelsofreadinessofthosecomponentstructuresthatrealisethemainfunctionsofsystems.ThedifferentsystemsarecomparablebecausethenumberofmainfunctionsisspecifiedinEN15380-4.ThestatusofsystemsisshowninFigure16.
Presentation of systems’ status based on readiness levels
Readinesslevelsinrealisationofmainfunctionsbyelementstructures(Fig.16)
System: DoorNumber of main functions in the system: 6
10
9
8
7
6
5
4
3
2
1
TRL 3.1 3.2 3.3 3.4 4 5 6 / 7 8 9
IRL I II II.I III.II III.III IV.I IV.II IV.III V
The weakest element (TRL/IRL) should be indicated in each case.
Example with six main functions; indication of the weakest element in each case
Separate detailed view available at www.bahnindustrie.info
39
4|ApplicationoftheQEprocessmodelinaproject
ThestepsinapplyingtheQEprocessmodelareshowninFigures2and3insection2.Figure17illustratesthephaseassignmenttothesuperiorandsubordinatesystems.
Figure18presentsthecontentandthesequenceofthechecklistsforapplyingtheQEprocessmodelinacustomerproject,andisorientedontheflowdiagramfromFigure17.ThismeansthatthechecklistsreflecttheQEprocessmodel.
Application of the qe process model in a project
FlowdiagramforapplyingtheQEprocessmodel,illustratedwithacustomerproject(Fig.17)
Inputfromoverallsystemtosub-systems- Non-functional requirements- Laws, regulations, approval- Use profi le / confi guration- Customer’s special requirements- Interfaces (installation spaces, forces, etc.)- Functional requirements
Focusonsubordinatesystemsrelevanttosuc-cess(“sub-systemsrelevanttosuccess”),e.g.- Propulsion systems- Brake- Vehicle control - Coupling- Doors
Superior system conceptRequirements for sub-systems
Supe
rior s
yste
mSu
bord
inat
e sy
stem
Client: functionalspecifi cations /requirements
Structured,standard analyses, TRL / IRL
Review after each phase
Status(completionofeachphase)ofoverallsystem(graphic)basedonthesub-systemsrelevanttosuccess- Elements with lowest readiness levels (TRL / IRL)- Number of main functions needing QE actions, andthe scope of actions needed for assuring results
Consolidation to superior system of elements with lowest readiness level of all subordinate systems relevant to success
Tender / clarifi cation Concept Intermediate design Final design Production First sample
Tender / clarifi cation Concept Intermediate design Final design Production
Action plans Assurance Achieving objectives
IdentificationElements with lowest levels of readiness(TRL / IRL)
40
The following steps are necessary when applying the process model:
(1)Recordinganddeterminingfulfilmentofthenon-functionalrequirements(identification ofdeviationsfromthereferencesystem) •Basedonthechecklist“Non-functionalrequirements”(2)Recordinganddeterminingfulfilmentofthefunctionalrequirements(analysisof deviationsofmainfunctions,functionalstructure,parts/componentsfromthereference system) •Basedonthechecklist“Functionalrequirements” •Basedonthetable“Productdesignprocess”(3)Classificationinreadinesslevels(TRL/IRL) •Basedonthetable“TRL_IRL_MEASUREMENTS_LEVELS”(4)SelectionofappropriateQEmethods(onthebasisofTRL/IRLandthedeviation) •Basedonthetable“QE_methods”(5)PreparationoftheQEactionplan •Basedonthetable“QE_ACTION_plan_generic”(6)Presentationofthestatusreport •Basedonthetable“Summary_QE_actions”
FlowdiagramandapplicationofchecklistsduringapplicationoftheQEprocessmodeltoacustomerproject(Fig.18)
Client: user specifi cation (US) / requirements
Statusreporttosuperiorsystembased on the subordinate system relevant to success- Critical elements- TRL and IRL- Actions for assuring the requirementsInput from superior system into subordinate systems
Contractor elaborates conceptual design of superior system:Functional specifi cations (FS) / requirements (incl. vehicle concept)
Defi nition of requirements from US and FS
Non-functional
Functional
GenericchecklistsforsubordinatesystemsElaborateinputtogetherwithsuperiorsystem
Identificationofcriticalelements(Focus on deviations from reference system)- Functional structure- Parts
By structured comparison with reference system from- Functional perspective- Component perspective
- Selection of reference system / orientation on reference PDP (new development)- Deviations from reference system- Using fi ndings
QEactionplan-Specificfor identifi ed criticalelement
- Recommendation of QEactionsAssessmentbasedon TR/ IR levels and the deviation- Analysis of deviations from
reference system / PDP - Main functions - Functional structure - Parts / components
Non-functional requirements (checklist)
Functional requirements (checklist)
Assignment to TR / IR levels
1
4
5
2 3
QE action plan, illustrated by a door system (Fig. 22)
TRL IRL Tender / clarification Concept Intermediate design Final design Production Type test prior to integration / first article inspection (FAI)
3.1 I Identification of “new function” also to be bolted securely when not in service
3.2 II Detailed conceptual speci-fication for new function „Door also to be bolted securely when not in service“Use caseThorough discussion
3.3 II.I Draft for realising new function D-FMEAApproval by customer Customer confirms integration capability
3.4 III.II Drawings / part lists Approval by customerPhasing into supply chainFEM calculation for safety-relevant bolts
4 III.III Before FAI prototype realisation and testing in comparable door systemcomplete type test, in
Readiness levels in realisation of main functions by element structures (Fig. 16)
System: Door Number of main functions in the system: 6
10
9
8
7
6
5
4
3
2
1
TRL 3.1 3.2 3.3 3.4 4 5 6 / 7 8 9
IRL I II II.I III.II III.III IV.I IV.II IV.III V
The weakest element (TRL/IRL) should be indicated in each case.
Example with six main functions; indication of the weakest element in each case
Separate detailed view available at www.bahnindustrie.info
5 6
Application of the qe process model in a project
41
Thesestepsaredescribedinmoredetailbelow:
Step(1)–Recordingthenon-functionalrequirementsFirstofallthenon-functionalrequirementsareanalysed.Itshouldbecheckedwhetherallthenecessaryinformationisavailable.Ifreferencesystemsexist,itshouldbeclarifiedwheth-erthenon-functionalrequirements(boundaryconditionsandstipulatedproperties)canbetransferredtothenewsystem.Thefoundationforthisanalysisisthenon-functionalchecklistshowninFigure12insection3.4.2.1.Theapproachfordeterminingthedeviationsbetweenthenewsystemtobeanalysedandthetried-and-testedreferencesystemisshowninFigure19.Thesystemmanufacturerhavetofilloutthenon-functionalchecklistanddocumenttheresult.Theinputfromthesuperiorsystemshouldbeco-ordinatedindialoguebetweenthemanufacturers/developersofthesubordinatesystemandthoseofthesuperiorsystem.Themanufacturerofthesuperiorsystemandthemanufacturerofthesubordinatesystemmayhavetoco-ordinateonthecompletedchecklist.
Step(2)–RecordingthefunctionalrequirementsInthenextstepthefunctionalrequirementsareanalysedpursuanttoEN15380-2andEN15380-4.Startingfromthefunctionalstructures,thesystemsareanalysedinthefunctionviewandinthecomponentview.Theanalysishavetoidentifythoseelementswheredevia-tionsfromtheselectedreferencesystemoccur.Ifnoreferencesystemhasbeendefined,thedeviationsfromthereferenceprocessshouldbedetermined.Theanalysisfollowstheap-proachdescribedinFigure13insection3.4.2.2.Figure20showsthedeterminationandcomparisonofthefunctionalstructureswiththefunctionsdescribedinEN15380-4foreachsystem.Manufacturers/developershavetodeter-minethefunctionsofthespecificsystemsonthebasisofthestandard.Theyarealsorespon-sibleforconductinganddocumentingthecomparisonofthefunctionswiththerequirementsofthestandard.Themanufacturerofthesuperiorsystemandthemanufacturerofthesubor-dinatesystemmayhavetoco-ordinateonthecomparisonthatiscarriedout.
Step(3)–Classificationinreadinesslevels(TRL/IRL)Thedeviationsidentifiedserveasinitialvaluesfordeterminingthelevelsofreadiness.ThefoundationforthisistheevaluationofthematrixfordeterminingthelevelsofreadinessasshowninFigure21.Itshouldbeborneinmindthattheattribute“Physicalstateofthesystem/conditionsfortest”(upperrowsofthematrix)havetobetakenintoaccountforallsuchqueries.Thetestconditionsduringthephaseofpropertyfulfilmentareofcrucialimportancewhenthelevelsofreadinessareincreased(suchaswhetherthetestwascarriedoutunderstaticoroperatingconditions).TheelementswiththelowestTRandIRlevelshavetobegivenparticularconsideration,sincelowlevelsofreadinessareanindicatorforadditionalinputandrisk.Thedocumentationoftheanalysis–i.e.settingthelevelsofreadiness(TRLandIRL)–correspondstotheapproachsetoutinFigure13(functionalchecklist)insection3.4.2.2.Manufacturers/developersmustworkthroughanddocumentthefunctionalandnon-func-tionalchecklistsofthespecificsystem.Themanufacturerofthesuperiorsystemandthemanufacturerofthesubordinatesystemmayhavetoco-ordinateonthecompletedchecklist.
Application of the qe process model in a project
42
Step(4)–SelectionofappropriateQEmethodsStartingfromthisanalysis,themanufacturersselectneeds-basedQEactions,whichresultfromtheprocessmodel,dependingonthecategoryandphaseofthedeviation(seeFigure15insection3.5).
Step(5)–PreparationoftheQEactionplanTheQEactionplanassignstheselectedactionstoindividualphases.Theyareintendedtoensurethatthedesiredresults(desiredTRLordesiredIRL)areinfactachievedattheappropri-atetime.AssignmentoftheactionstothetargetTRLorIRLovertheindividualphasesenablesthestatustoberepresentedgraphically.TheformforthispresentationisshowninFigure14insection3.6.Areviewshouldbeconductedtocompleteeachphase,involvingacheckonwhethertheactionsselectedhavebeenimplemented.Inaddition,itshouldbeclarifiedwhether–forexample–changeshaveresultedinnewcriticalsituationsthathavetobeanalysedaccordingtotheQEprocessmodel.
Figure22showsaspecimenQEactionplanforadoorsystem.
Step(6)–PresentationofthestatusreportInordertoshowthestatusoftheoverallproject,ineachcasetheelementwiththelowestlevelofreadinessandthehighestriskuptocompletionisrepresentedgraphicallyinaccord-ancewithFigure14insection3.6.Forallthesubordinatesystemsrelevanttosuccess,thisisdonebytheirmanufacturersordevelopers,whoreportthestatustothesuperiorsystems.Theproject-specificdefinitionofthesystemsrelevanttosuccessisacommontaskforthemanufacturers/developersofthesuperiorandsubordinatesystems.
Themanufacturers/developershavetocarryoutanddocumentpresentationofthestatusofthespecificsystem.Uponcompletionofeachdevelopmentphase,themanufacturerofthesuperiorsystemshouldbenotifiedofthestatusinthepresentationprescribedinsection3.7(statusandnumberofelementstructuresthatrealisethemainfunctionsofsystems).
Application of the qe process model in a project
43
Application of the qe process model in a project
Approachfordeterminingthedeviationbetweenanewsystemtobeanalysedandatried-and-testedreferencesystem(Fig.19)
TRLReference system,superior
TRLsystem (project) to be analysed,superior
IRLsystem (project) to be analysed,subordinate
TRL
IRL
Bezugssystemübergeordnet
Deviation (delta) in superior system
IRLsystem (project) to be analysed,subordinate
Reference system,subordinate
TRLReference system,subordinate
IRLReference system
Non
-fun
ctio
nal r
equi
rem
ents
Non
-fun
ctio
nal r
equi
rem
ents
Non
-fun
ctio
nal d
evia
tions
Func
tiona
l str
uctu
re
Func
tiona
l str
uctu
re
Func
tiona
l and
co
mpo
nent
dev
iatio
ns
Com
pone
nt st
ruct
ure
Com
pone
nt st
ruct
ure
Non
-fun
ctio
nal r
equi
rem
ents
Non
-fun
ctio
nal r
equi
rem
ents
Func
tiona
l str
uctu
re
Func
tiona
l str
uctu
re
Non
-fun
ctio
nal d
evia
tions
Func
tiona
l and
co
mpo
nent
dev
iatio
ns
Com
pone
nt st
ruct
ure
Com
pone
nt st
ruct
ure
Integration between lower and superior systemFunctionBoundary conditions / interfaces
Deviation in integration between lower and superior system
Deviation (delta) in superior system
Project system
Project sub-system
Integration between lower and superior systemFunctionBoundary conditions / interfaces
1
1
2
2
3
3
44
Dete
rmin
ing
and
com
parin
gth
efu
nctio
nals
truc
ture
swith
the
func
tions
des
crib
edin
EN
1538
0-4
fors
peci
ficsy
stem
s(Fi
g.2
0)
DEn
able
acc
essa
ndlo
adin
g
BPl
ana
cces
sfro
mo
utsi
de
B(R
elea
se o
utsi
de d
oors
)
C(O
pen
outs
ide
door
s)
D(C
lose
out
side
doo
rs)
E(O
pera
te d
oor s
yste
m)
F(B
olt o
utsi
de d
oors
)
GU
nbol
t out
side
doo
rs
H(E
nabl
e ou
tsid
e do
or o
peni
ng)
JPr
ovid
e en
tran
ce il
lum
inat
ion
KBl
ock
outs
ide
door
s
EN 15
380-
4: Li
st o
f the
func
tions
of a
syst
em
Sele
ctio
n of
mai
n fu
nctio
nsfr
om E
N 15
380-
4-
Cruc
ial t
o fu
lfi lli
ng th
e pu
rpos
e
Mai
nfu
nctio
nsSu
b-fu
nctio
ns
Mov
e do
or le
af
Bolt
door
leaf
Cont
rol d
oor s
yste
m
... ... Bloc
k ou
tsid
e do
ors
... ... ... ... ... Bloc
k do
or
Bolt
door
secu
rely
... ... ... ... ... ... ...
Chec
k on
whe
ther
all
func
tions
of th
e sp
ecifi
c sys
tem
indi
cate
d in
EN
1538
0-4
are
fulfi
lled
by th
e ne
w
syst
em
45
Application of the qe process model in a project
46
Application of the qe process model in a project
PDP development phase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physical state / test conditions
Model
Simulation / description
ERG
Technology readiness levels
3.1 3.2 3.3 3.4
Function view Complete information on interaction (physical, process technology, information, etc.) with other systems (integration), e.g. which accelerations must be taken into accountSolutions for critical requirements, main (i.e. crucial) functions are defi ned
Functional structures and operating principles for all functional require-mentsAssignment of function / operating principleConstruction elementProduct‘s conceptual design is complete - System draft (multi-domain solution concept)
Defi nition of assurance of properties (validation principle)
Component view Complete information and description of the attributes of the system:laws, regulations, standardsuse profi le, vehicle confi gurationCustomer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction elements to be designed, e.g. structure / construction space, environment, dynamic, etc.
Construction elements of a functional structure fulfi l requirements placed on this functional structure
Defi nition of assurance of pro-perties (verifi cation / validation principle)
Design of all construction elements is completedAll construction elements are integrated into the systemInteracting elements fulfi l requirements
Evidence for TRL - Basic vehicle structure („PowerPoint design“)- Clause-by-clause commentary on - Requirements of the functional specifi cations- Designation of main and sub-functions based on EN 15380-4, second level- Description of deviations pursuant to checklists „non-functional / functional requirements“
- Conceptual specifi cations - Overall arrangement (elaborated vehicle structure)- Installation spaces - Draft total weight - Interface description available
3-D model (preliminary) - Transfer of all production documents- Approval of circuit diagrams- Approved validation plan incl. rough defi nition of evidence requi-red (type tests)
IRG
Integration readiness levels
I II.I II.II II.III
Function view Multi-system functions are defi ned and main functions are distributed (which system does what?)
Determination of all multi-system functions (incl. ancillary and derived functions; functional architecture),functional structures and operating principles
All overarching functions are fulfi lled
Component view (interface - material, energy, information)
Defi nition of interfaces (material, energy, information) and interaction (physical, process technology, etc.)
Generation of complete information for subordinate system functional requirements;non-functional requirements and attributes:laws, regulations, standards, use profi le, vehicle confi guration Customer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction elements to be designed, e.g. const-ruction concept/space, environment, dynamic, etc.
Detailed defi nition of interfaces for elements of the specifi c phase;Description of the data interfaces for sub-systems characterised by complex software and feedback loops to circuit diagram of train and/or between the systems. Software (Train Control Monitoring System, TCMS) can be implemented later in a separate cycle
Detailed defi nition of all interfaces
Evidence for IRL Description of deviations pursuant to checklists„non-functional / functional requirements“
Tech. specifi cations available for procuring elements and subordinate system (incl. interface description)
Approval of interfaces (protocols)
Approval of data interfaces (protocols)
Assurance of properties through verifi cation and validation (scope for stand-alone systems)
Assurance of properties through verifi cation and validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior system, Test is not integ-rated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Test under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi c operation
4 5 6 / 7 8 9
Evidence of fulfi lment of all functional requirements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all functional requirements (static)
Evidence of fulfi lment of all functional requirements (dynamic)
Evidence of fulfi lment of all functional requirements (approval / acceptance)
Evidence of fulfi lment of all functional requirements(operational deployment)
Evidence of fulfi lment of all requirements placed on construction elements to the extent defi ned and veri-fi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all requirements placed on construction elements(static)
Evidence of fulfi lment of all requirements placed on construction elements (dynamic)
Evidence of fulfi lment of all requirements placed on cons-truction elements (approval / acceptance)
Evidence of fulfi lment of all requirements placed on construction elements(operational deployment)
Evidence of fulfi lment of requirements placed on subordinate system (FAI report)
Type test protocols (prior to integration)
Type test protocols (integration static)
Type test protocols(integration dynamic)
Commissioning approvalApproval certifi cate Acceptance protocol
No reports of necessary design modifi cations within one annual cycle
III IV.I IV.II IV.III V
Defi ned input from superior system triggers defi ned function in non-integrated subordinate system (test environment, e.g. signal on pin x triggers door opening)
Defi ned interaction fulfi ls / triggers defi ned function / feedback from the subordinate system
From the viewpoint of the subordinate system, test of connection to superior system and other systems
Fulfi lment of requirements placed on interaction
Protocol (FST) Type test protocol (static) Type test protocol (dynamic) Authorisation of serviceApproval certifi cate Acceptance protocol
No reports of necessary design modifi cations within one annual cycle
Approachfordetermininglevelsofreadinessbasedontheassessmentmatrix(Fig.21)
PDP development Planning Conceptualisation Drafting and design of Complete draft design
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortoin-tegration/firstarticle
inspection(FAI)
Staticcommissioning
Dynamiccommissioning
Authorisationforplacingthevehicleinservice
Operation/
warranty
- Requirements of the functional specifi cations- Designation of main and sub-functions based on EN 15380-4, second level- Description of deviations pursuant to checklists „non-functional / functional requirements“
Determination of the TRL based on achievement of all desired results for the respective level
47
Application of the qe process model in a project
PDP development phase
Planning - Requirements for information - Compiling - Identifying gaps
Conceptualisation- Functional structures - Basic solutions
Drafting and design of modular structures Elaborating solutions / functional structures
Complete draft design
Physical state / test conditions
Model
Simulation / description
ERG
Technology readiness levels
3.1 3.2 3.3 3.4
Function view Complete information on interaction (physical, process technology, information, etc.) with other systems (integration), e.g. which accelerations must be taken into accountSolutions for critical requirements, main (i.e. crucial) functions are defi ned
Functional structures and operating principles for all functional require-mentsAssignment of function / operating principleConstruction elementProduct‘s conceptual design is complete - System draft (multi-domain solution concept)
Defi nition of assurance of properties (validation principle)
Component view Complete information and description of the attributes of the system:laws, regulations, standardsuse profi le, vehicle confi gurationCustomer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction elements to be designed, e.g. structure / construction space, environment, dynamic, etc.
Construction elements of a functional structure fulfi l requirements placed on this functional structure
Defi nition of assurance of pro-perties (verifi cation / validation principle)
Design of all construction elements is completedAll construction elements are integrated into the systemInteracting elements fulfi l requirements
Evidence for TRL - Basic vehicle structure („PowerPoint design“)- Clause-by-clause commentary on - Requirements of the functional specifi cations- Designation of main and sub-functions based on EN 15380-4, second level- Description of deviations pursuant to checklists „non-functional / functional requirements“
- Conceptual specifi cations - Overall arrangement (elaborated vehicle structure)- Installation spaces - Draft total weight - Interface description available
3-D model (preliminary) - Transfer of all production documents- Approval of circuit diagrams- Approved validation plan incl. rough defi nition of evidence requi-red (type tests)
IRG
Integration readiness levels
I II.I II.II II.III
Function view Multi-system functions are defi ned and main functions are distributed (which system does what?)
Determination of all multi-system functions (incl. ancillary and derived functions; functional architecture),functional structures and operating principles
All overarching functions are fulfi lled
Component view (interface - material, energy, information)
Defi nition of interfaces (material, energy, information) and interaction (physical, process technology, etc.)
Generation of complete information for subordinate system functional requirements;non-functional requirements and attributes:laws, regulations, standards, use profi le, vehicle confi guration Customer‘s special requirements for interfaces (material, energy, infor-mation) placed on the construction elements to be designed, e.g. const-ruction concept/space, environment, dynamic, etc.
Detailed defi nition of interfaces for elements of the specifi c phase;Description of the data interfaces for sub-systems characterised by complex software and feedback loops to circuit diagram of train and/or between the systems. Software (Train Control Monitoring System, TCMS) can be implemented later in a separate cycle
Detailed defi nition of all interfaces
Evidence for IRL Description of deviations pursuant to checklists„non-functional / functional requirements“
Tech. specifi cations available for procuring elements and subordinate system (incl. interface description)
Approval of interfaces (protocols)
Approval of data interfaces (protocols)
Assurance of properties through verifi cation and validation (scope for stand-alone systems)
Assurance of properties through verifi cation and validation
First sample(experimental set-up if system qualifi cation is brought forward) is not integrated into superior system, Test is not integ-rated into superior system (stand-alone)
First sample(experimental set-up if system qualifi cation is brought forward) is integrated into superior system);Test of the system is integrated into standing (static) superior system
First sample (near-series product if system qualifi cation is brought forward) is integrated into superior system;Testing under test conditions (TRL 6) or trial operation (TRL 7) conditions
Series product is integrated into superior system;
Test under conditions for approval or acceptance operation
Series product is integrated into superior system;
Deployment under conditions of specifi c operation
4 5 6 / 7 8 9
Evidence of fulfi lment of all functional requirements to the extent defi ned and verifi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all functional requirements (static)
Evidence of fulfi lment of all functional requirements (dynamic)
Evidence of fulfi lment of all functional requirements (approval / acceptance)
Evidence of fulfi lment of all functional requirements(operational deployment)
Evidence of fulfi lment of all requirements placed on construction elements to the extent defi ned and veri-fi able for type test and fi rst article inspection (FAI)
Evidence of fulfi lment of all requirements placed on construction elements(static)
Evidence of fulfi lment of all requirements placed on construction elements (dynamic)
Evidence of fulfi lment of all requirements placed on cons-truction elements (approval / acceptance)
Evidence of fulfi lment of all requirements placed on construction elements(operational deployment)
Evidence of fulfi lment of requirements placed on subordinate system (FAI report)
Type test protocols (prior to integration)
Type test protocols (integration static)
Type test protocols(integration dynamic)
Commissioning approvalApproval certifi cate Acceptance protocol
No reports of necessary design modifi cations within one annual cycle
III IV.I IV.II IV.III V
Defi ned input from superior system triggers defi ned function in non-integrated subordinate system (test environment, e.g. signal on pin x triggers door opening)
Defi ned interaction fulfi ls / triggers defi ned function / feedback from the subordinate system
From the viewpoint of the subordinate system, test of connection to superior system and other systems
Fulfi lment of requirements placed on interaction
Protocol (FST) Type test protocol (static) Type test protocol (dynamic) Authorisation of serviceApproval certifi cate Acceptance protocol
No reports of necessary design modifi cations within one annual cycle
Projectphases
Tender/clarification Concept Intermediatedesign Finaldesign Production
Assurance of properties Assurance of properties through
Production Typetestpriortoin-tegration/firstarticle
inspection(FAI)
Staticcommissioning
Dynamiccommissioning
Authorisationforplacingthevehicleinservice
Operation/
warranty
Commissioning approval
Determination of the IRL based on achievement of all desired results for the respective level
48
Application of the qe process model in a project
QEactionplan,illustratedbyadoorsystem(Fig.22)
TRL IRL Tender/clarification Concept Intermediatedesign Finaldesign Production Typetestpriortointegration/firstarticleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Authorisationforplacingthevehicleinservice
Warranty
3.1 I Identifi cation of “new function” also to be bolted securely when not in service
3.2 II Detailed conceptual speci-fi cation for new function „Door also to be bolted securely when not in service“Use caseThorough discussion
3.3 II.I Draft for realising new function D-FMEAApproval by customer Customer confi rms integration capability
3.4 III.II Drawings / part lists Approval by customerPhasing into supply chainFEM calculation for safety-relevant bolts
4 III.III Before FAI prototype realisation and testing in comparable door systemcomplete type test, in particular stress test with 2,500 PaTilting testEvidence of operating forceVibration test
5 IV.I Process steps Reference process
6 IV.II Process steps Reference process
7 IV.II Process steps Reference process
8 IV.III Process steps Reference process
9 V Process steps Reference process
Separate detailed view available at www.bahnindustrie.info
49
Application of the qe process model in a project
TRL IRL Tender/clarification Concept Intermediatedesign Finaldesign Production Typetestpriortointegration/firstarticleinspection(FAI)
Staticcommissioning
Dynamiccommissioning
Authorisationforplacingthevehicleinservice
Warranty
3.1 I Identifi cation of “new function” also to be bolted securely when not in service
3.2 II Detailed conceptual speci-fi cation for new function „Door also to be bolted securely when not in service“Use caseThorough discussion
3.3 II.I Draft for realising new function D-FMEAApproval by customer Customer confi rms integration capability
3.4 III.II Drawings / part lists Approval by customerPhasing into supply chainFEM calculation for safety-relevant bolts
4 III.III Before FAI prototype realisation and testing in comparable door systemcomplete type test, in particular stress test with 2,500 PaTilting testEvidence of operating forceVibration test
5 IV.I Process steps Reference process
6 IV.II Process steps Reference process
7 IV.II Process steps Reference process
8 IV.III Process steps Reference process
9 V Process steps Reference process
50
GlossaryAncillaryfunctionFunctionthatisnotthemainfunction.Asub-functionofaproductmaybeanancillaryfunctioninrelationtotheproduct.Itmaybethemainfunctioninrelationtothepartoftheproductinwhichthissub-functionoccurs[VDI2221].
AssemblyAcombinationofelementstructuresformingaunitthatcannotyetbeusedindependently[EN15380-2].
BlackboxRepresentationofasystemthatexecutesfunctionswithonlyinputandoutput.
BoundaryconditionUninfluenceableconditionthatmustbetakenintoconsiderationasapredeterminedproper-ty.[EN15380-5].
DevelopmentAnalysisandprocessingofnewfindingsandtheirapplication.Creationofnewproductsthroughtargetedandmethodologicalconsiderations,experimentationanddesigns.
Deviationisfundamental:Thedeviationoccursatafundamentallevelandhasanimpactontheobjectbeingexamined;basicchangesarerequiredtohandlethedeviationintheobjectbeingexamined.Example:theenergyistransmittedbyadifferentoperatingprinciple(electricinsteadofpneu-matic),anddifferentpartsmustbeused.
Deviationisidentical/unimportant:Thedeviationisnotcrucialand/orisofsecondaryim-portance,andimpactontheobjectbeingexaminedisnegligible;nochangesarerequiredforhandlingthedeviationintheobjectbeingexamined.Forexample,thecolourinsideanequipmentboxischangedfromlightbluetolightgrey(therearenorequirementsrelatingtothecolour).
Deviationismarked:Thedeviationisclearandcrucialandthereisanimpactontheobjectbeingexamined;nobasicchangesarerequiredforhandlingthedeviationintheobjectbeingexamined.Forexample,anenergyabsorptionelementisdesignedforaslightlyhigherenergyabsorp-tion,andtheoperatingprinciplesremainasbefore;thepartismodified.
ElementAunitcomprisedofseveralconstructionelementsisanassembly[derivedfromEN15380-2].
ElementstructureFunctionalstructuresareimplementedbyactivestructures–thatis,throughphysical,chem-icalorothereffects–andtheirstructure.Theactivestructuresdeterminetheconstructionelements,partsorcomponentswithwhichtheactiveandthefunctionalstructurescanbe
Glossary
51
realised.Severalelementscanbecombinedaselementstructures.Functionsareimplementedbyelementsorelementstructures.
FunctionThere are several different definitions of this term. The following definition based on EN 15380-4 should be used for application of the QE guideline:
Afunctionexecutedbytechnicalmeansand/orhumanstransforms(viewedasa“blackbox”)inputparameters(material,energy,information)intotarget-orientedoutputparameters(ma-terial,energy,information).Functionscanbedescribedusinganounandaverb(e.g.convertenergy,enableaccess).Questionssuchas“Whatisthepurpose?”or“Whatdoesthesystemachieve?”leadtoidentificationofthefunction.
FunctionalrequirementExpressesthespecialdemandorabilityofafunctionintheFunctionalBreakdownStructure(FBS).
Pleasenote:functionalrequirementsandusecasesaregenerallyinitiallyderivedfromthepassengersorfreight/loadtobetransportedandthewishesoftheoperators.Laterinthedevelopmentprocess,functionalrequirementsofthefittersandsuppliersareadded.TheyexpresstherequirementsplacedonacertainfunctionalitydescribedintheFBS–forexampleinrelationtointeroperabilitywithotherfunctions,safety,operation,function/behaviourorfunctionalarchitecture/designrestrictions.Thefunctionaldesignationisnormallyspecifiedevenmorepreciselyinthedetailsoftheproperties,whichsupplymoreinformationaboutreli-ability,availability,performancecapability,quality,documentation,inputandoutputdataandbehaviourinrealtime.Thesesuperiorfunctionalobjectives,whichareelaboratedforenviron-mentalconditions,designcharacteristicsandselectedtargetgroupsandtargetobjects,are“requirementsplacedonafunction”[EN15380-4].
IntegrationReferstotheinteractionbetweensystems.
IntegrationreadinesslevelTheintegrationreadinessmodelevaluatesthedegreeoffulfilmentofthefunctionalityoftheinteractionofseveralsystems.Itindicatesthestatusofasystemvis-à-visthesuperiorsystem:doesitfulfilalltherequirementsforintegrationintoasuperiorsystemandforfulfillingitsrequirementsinthisenvironment?
LevelofreadinessAlevelofreadinessdescribesthereadinessofanobservedfieldinrelationtoacertainmethodoramodelforactionormanagement.Differentamountsofagreement–betweenthedefinedcriteria(attributesrelevanttodecision-making)andadegreeoffulfilmentofthecriteria–resultinvariouslevelsofreadiness.Oneormorerequirementsareassignedtoeachoftheselevelsofreadiness.Alevelofreadinessisregardedasattainedonlyifthecriteriadescribedthereandthosede-scribedintheprecedingstageareshowntobemet.Thelevelsofreadinessaccordinglybuildononeanother[AHL2005].
Glossary
52
MainfunctionCrucialfunctionofaproductorofanassembly[EN15380-2].Functionthatdescribesamainpurposeofaproduct[VDI2221].
NewsystemThenewsystemistheresultorproductthatistobedevelopedtofulfiltherequirements.
OperatingprincipleTheoperatingprinciplereferstotheconnectionbetweenthephysicaleffect,geometricalfeaturesandmaterialfeatures(effectivegeometry,effectiveactionandmaterial).Itallowsrecognitionoftheprincipleofthesolutionforfulfillingasub-function[VDI2206].
OverallfunctionTotalityofallfunctionsthataproductrealisesorisintendedtorealise.Theoverallfunctioncanbedividedintosub-functions.Theoverallfunctionisderivedfromthetask;itfulfilstheoveralltaskoftheproduct[VDI2221].
PartAproductthatcanbeunequivocallyidentified,whichisregardedasindivisibleforacertainplanningandcontrolpurpose,and/orcannotbetakenapartwithoutbeingdestroyed[EN15380-2].
ProductPlannedorachievedresultofwork[EN15380-5].Theproductfulfilsthefunctionandiscomprisedofproductgroups[EN15380-2].
ProductgroupAproductgroupfulfilsthefunctionofanassemblyoracomponent.
ProductstructureTheproductstructureresultsfromthephysicalimplementationofthefunctionalstructure.
QualityengineeringQualitytechniquesforqualitativeassuranceofaproductdevelopment.Qualityengineeringmethodsareusedfordefining,monitoringandcontrollingconformityofthedevelopedprod-uctswiththerequirementsandfordeterminingtheneedforqualityassurance.
ReferenceprocessThereferenceprocessrepresentstheidealprocessandprovidesabasisforcomparisons.
ReferencesystemThereferencesystemrepresentsthesystemwithwhichsomethingelseistobecompared.Thenewsystemiscomparedwiththereferencesystem.
RequirementQualitativeand/orquantitativedeterminationofpropertiesorconditionsforaproduct;therequirementsmaybegivendifferentweightings[VDI2221].
Glossar
53
Sub-functionEveryfunctionthatcanbeidentifiedbydividingupasuperiorfunction.Sub-functionscanbemainfunctionsandancillaryfunctions.Sub-functionscanbearrangedinahierarchy[VDI2221].
Sub-systemArailvehicleisbuiltupofsub-systems.Pleasenote:EN15380-5definestenmainsystems,alsocalled1stlevelsystems.Themainsystemsarecomprisedof2ndlevelsub-systems.Inthisguideline,theterm“sub-system”isregardedasequivalenttotheterm“mainsystem/first-levelsystem”asinEN15380-5.
SystemSystemsexecutefunctions[VDI2221].Setofinterrelatedobjectsconsideredinacertaincontextasawholeandregardedasseparat-edfromtheirenvironment[EN15380-5].Note1ontheterm:asystemisgenerallydefinedwithaviewtoachieveagivenobjective,e.g.byperformingadefinitefunction.Note2ontheterm:examplesofasystem:adrivesystem,awatersupplysystem,astereosystem,acomputer.Note3ontheterm:asystemisconsideredtobeseparatedfromtheenvironmentandfromotherexternalsystemsbyanimaginarysurface,whichcutsthelinksbetweenthemandthesystem.
SystemlevelLevelofgroupedsystems[EN15380-5].
TechnologyreadinessmodelThetechnologyreadinessmodelevaluatesthedegreeoffulfilmentofthefunctionalcapabili-tyofaseparatedsystem.Itfocusesonfulfilmentoftherequirementsplacedonthesystem.Itdescribestheperformanceofthissystem.
Glossar
54
Literature[AHL2005]Ahlemann:2005Ahlemann,F.;Schroeder,C.;Teuteberg,F.:Kompetenz-undReifegradmodellefürdasProjektmanagement.In:Ahlemann,F.;Teuteberg,F.(eds.):ISPRI-ArbeitsberichtNr.01/2005.Osnabrück:ISPRI–ForschungszentrumfürInformations-systemeinProjekt-undInnovationsnetzwerken,2005.
[AKK2013]Akkasoglu:2013MethodikzurKonzeptionundApplikationanwendungsspezi-fischerReifegradmodelleunterBerücksichtigungderInformationsunsicherheit.
[AST2008]ASTRIUM/DIN/DLR:2008AbschlussberichtzumINS224Projekt:RisikokontrollierteAnwendungvonInnovation&technologischemFortschritt–Standardi-sierteEntscheidungshilfenzurReifegradbewertungimProdukt–Lebenszyklus–Machbar-keitsstudie.
[BUN2010]BundesministeriumVerkehr,Bau,Stadtentwicklung:2010HandbuchEisenbahn-fahrzeuge,LeitfadenfürHerstellungundZulassung.
[EN15380]EN15380-1/-2/-3/-4/-5Bahnanwendungen–KennzeichnungssystematikfürSchienenfahrzeuge–Teil1:Grundlagen(2006),Teil2:Produktgruppen(2006),Teil3:KennzeichnungvonAufstellungs-undEinbauorten(2006),Teil4:Funktionsgruppen(2013),Teil5:Systemstruktur(2014).
[VDI2206]VDI2206:2004-06EntwicklungsmethodikfürmechatronischeSysteme.
[VDI2221]VDI2221:1993-05MethodikzumEntwickelnundKonstruierentechnischerSystemeundProdukte,Berlin:BeuthVerlag.
[VDI2803]VDI2803:1996FunktionenanalyseGrundlagenundMethode.
Literature
55
Abbildungsverzeichnis
Fig.1: QEprocessmodel 9Fig.2: ProcessstepsintheQEprocessmodel 10Fig.3: Genericreferenceprocess:productdevelopmentprocess 13Fig.4: Outlineoftheproductdevelopmentprocess(PDP) 14Fig.5: Thecascadeinthesupplychain 16Fig.6: Basicstructureofreadinessmodels[AKK2013] 17Fig.7: Briefdescriptionoftechnologyandintegrationreadinessmodels 19Fig.8: Comparisonoftechnologyandintegrationreadinessmodels(TRL/IRL) 20Fig.9: Outlineofdeterminationofreadinesslevels 22Fig.10: Analysisfromthefunctionandcomponentviews.Theproductstructureresults fromthephysicalimplementationofthefunctionalstructure 28Fig.11: Structureofthechecklists 29Fig.12: Outlineofnon-functionalchecklist 30Fig.13: Outlineoffunctionalchecklist–example 33Fig.14: DeterminationofQEactionsdependingondeviation(phaseandcategory) 35Fig.15: RecommendationofsuitableQEactions 36Fig.16: Readinesslevelsinrealisationofmainfunctionsbyconstruction elementstructures 38Fig.17: FlowdiagramforapplyingtheQEprocessmodel,illustratedwitha customerproject 39Fig.18: Flowdiagramandapplicationofchecklistsduringapplication oftheQEprocessmodeltoacustomerproject 40Fig.19: Approachfordeterminingthedeviationsbetweenanewsystem tobeanalysedandatried-and-testedreferencesystem 43Fig.20: Determiningandcomparingthefunctionalstructureswiththe functionsdescribedinEN15380-4forspecificsystems 44Fig.21: Approachfordetermininglevelsofreadinessbasedontheassessmentmatrix 46Fig.22: QEactionplan,illustratedbyadoorsystem 48
List of figures
56
LiabilitydisclaimerThisguidelinerepresentsastandardasarecommendationandisfreelyavailableforalltouse.Notwithstandingtheformoftheguidelineasarecommendation,usersarefreetoagreewiththeauthorstomakebindingreferencetothisguideline.Iftheguidelineisapplied,theusersshallberesponsibleforcorrectapplicationandimple-mentationoftherecommendations.Applicationoftheguidelinedoesnotrelievetheusersofanyresponsibilityfortheirownactions.Neitherdoesapplicationoftheguidelineobviateanylegalorregulatoryrequirements.Thepublisherdoesnotacceptanyliabilityorguaranteethatthefollowingrecommendationsareup-to-date,correct,complete,orofacertainquality.Liabilityclaimsagainstthepublisher,whichrelatetodamagecausedbytheapplicationofthisguideline,areexcluded.Theguidelinewaspreparedtothebestofourknowledgeandbelief.Shouldauserfindanyerrorsoranystatementallowingdifferinginterpretations,werequestthatthepublisherbenotified.
Liability disclaimer
57
ContactTheorganisationsinvolvedinthepreparationofthisdocumentmaybecontactedviathefollowingpersons:
SebastianBartels sebastian.bartels@deutschebahn.comDr.BenBoese ben.boese@transport.alstom.comStefanBrecht stefan.brecht@bode-kassel.comSaschaErmeling sascha.ermeling@knorr-bremse.comJanineFriedl janine.friedl@transport.alstom.comChristophHeine christoph.heine@knorr-bremse.comMartinJessen martin.jessen@de.transport.bombardier.comAngelaKönig angela.koenig@deutschebahn.comDr.MatthiasMüller matthias.ma.mueller@deutschebahn.comDr.MarkusNasshan markus.nasshan@siemens.comDr.AlexanderOrellano alexander.orellano@de.transport.bombardier.comReinhardOtto reinhard.otto@deutschebahn.comMartinRedhardt martin.redhardt@de.transport.bombardier.comProf.Dr.UlrichRudolph u.rudolph@htw-berlin.deMarcusSchmid marcus.schmid@voith.comNormanSchulz norman.schulz@stadlerrail.deMarkusSchulze markus.schulze@stadlerrail.deStephanSchwandt stephan.schwandt@stadlerrail.deDominikWeidtmann dominik.weidtmann@transport.alstom.comAxelWeinknecht axel.weinknecht@deutschebahn.com
Ansprechpartner
58
59
VerbandderBahnindustrieinDeutschland(VDB)e.V.
Universitätsstraße2D-10117Berlin-Mitte
Tel.:+4930206289–0Fax:+4930206289–50
Email:info@bahnindustrie.infoInternet:www.bahnindustrie.info
VersiondatedSeptember2015
Recommended