Quality Engineering during Design phase of Rail Vehicles ... · 3.6 Determining methods for assuring results (QE action plan) 34 3.7 Presentation of systems’ status based on readiness

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 orientation/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


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


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



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.


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

}{


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.


22


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)


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


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


Projectphases

Tender/clarification Concept Intermediatedesign Finaldesign Production Production Typetestpriortointegration/first

articleinspection(FAI)

Staticcommissioning

Dynamiccommissioning

Issueofcommissioning

approval

Operation/warranty

ments“ and „functional requirements“



Please note: The second part of the table is shown on the next two pages.

Separate detailed view available at www.bahnindustrie.info

23


PDPdevelopmentphase






Model


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)


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.


Defi nition of assurance of properties (verifi cation / validation principle)


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






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)








4 5 6 / 7 8 9





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(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



Projectphases



Staticcommissioning



approval

Operation/warranty


24


Schematicdiagramofdeterminationofreadinesslevels(Fig.9)Part2

Projectphases



Staticcommissioning



approval

Operation/warranty

PDPdevelopmentphase






Model


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?)


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






Deployment under conditions of specifi coperation

4 5 6 / 7 8 9


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


25


Projectphases



Staticcommissioning



approval

Operation/warranty

PDPdevelopmentphase






Model


TRL Leveloftechnology

readiness3.1 3.2 3.3 3.4

IRL

Levelofintegrationreadiness

I II.I II.II II.III

Functionview




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


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 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






Deployment under conditions of specifi coperation

4 5 6 / 7 8 9




From the viewpoint of subordinate system, test of connection to superior system and other systems


Report (FAI) Type test report (static) Type test report (dynamic) Commissioning approvalApproval certifi cate Acceptance report


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 superiorsystem (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


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.)


37


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


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


5 6


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.


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).


43


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


46


PDP development phase





Physical state / test conditions

Model


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)


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.


Defi nition of assurance of pro-perties (verifi cation / validation principle)


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


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


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


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 data interfaces (protocols)


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 (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


Test under conditions for approval or acceptance operation



4 5 6 / 7 8 9





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 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





From the viewpoint of the subordinate system, test of connection to superior system and other systems


Protocol (FST) Type test protocol (static) Type test protocol (dynamic) Authorisation of serviceApproval certifi cate Acceptance protocol


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


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


PDP development phase





Physical state / test conditions

Model


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)


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.


Defi nition of assurance of pro-perties (verifi cation / validation principle)


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


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


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


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 data interfaces (protocols)


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 (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


Test under conditions for approval or acceptance operation



4 5 6 / 7 8 9





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 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





From the viewpoint of the subordinate system, test of connection to superior system and other systems


Protocol (FST) Type test protocol (static) Type test protocol (dynamic) Authorisation of serviceApproval certifi cate Acceptance protocol


Projectphases

Tender/clarification Concept Intermediatedesign Finaldesign Production

Assurance of properties Assurance of properties through

Production Typetestpriortoin-tegration/firstarticle

inspection(FAI)

Staticcommissioning



Operation/

warranty

Commissioning approval

Determination of the IRL based on achievement of all desired results for the respective level

48


QEactionplan,illustratedbyadoorsystem(Fig.22)

TRL IRL Tender/clarification Concept Intermediatedesign Finaldesign Production Typetestpriortointegration/firstarticleinspection(FAI)

Staticcommissioning



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


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


8 IV.III Process steps Reference process

9 V Process steps Reference process


49


TRL IRL Tender/clarification Concept Intermediatedesign Finaldesign Production Typetestpriortointegration/firstarticleinspection(FAI)

Staticcommissioning



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


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



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 [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]önig [email protected]üller [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Ansprechpartner

58

59

VerbandderBahnindustrieinDeutschland(VDB)e.V.

Universitätsstraße2D-10117Berlin-Mitte

Tel.:+4930206289–0Fax:+4930206289–50

Email:[email protected]:www.bahnindustrie.info

VersiondatedSeptember2015

Documents

Quality Engineering during Design phase of Rail Vehicles ... · 3.6 Determining methods for assuring results (QE action plan) 34 3.7 Presentation of systems’ status based on readiness