Pålidelighed engineering

Pålidelighed engineering er ingeniør, der lægger vægt pålidelighed i lifecycle management af et produkt. Pålidelighed eller pålideligheden, beskriver et systems evne eller en komponent til at fungere under angivne betingelser for en bestemt periode. Pålidelighed engineering repræsenterer en sub-disciplin inden for systemudvikling. Pålidelighed er teoretisk defineres som sandsynligheden for svigt, som frekvensen af ​​fejl, eller i form af tilgængelighed, som en sandsynlighed stammer fra pålidelighed og vedligeholdelse. Maintainability og vedligeholdelse er ofte defineret som en del af "pålidelighed engineering" i Reliability programmer. Pålidelighed spiller en central rolle i omkostningseffektiviteten af ​​systemerne.

Selvom stokastiske parametre definerer og påvirker pålidelighed, ifølge P. O'Conner og A. Barnard, der Pålidelighed ikke opnås ved matematik og statistik. "Næsten al undervisning og litteratur om emnet understrege disse aspekter, og ignorere det faktum, at de grænser for usikkerhed, der er involveret i høj grad afkræfte kvantitative metoder til forudsigelse og måling"

Pålidelighed engineering tæt forbundet med sikkerhed teknik og til system sikkerhed, at de bruger fælles metoder til deres analyse og kan kræve input fra hinanden. Pålidelighed engineering fokuserer på omkostninger ved fejl forårsaget af systemet nedetid, udgifter til reservedele, reparation udstyr, personale og omkostningerne ved garantikrav. Sikkerhed engineering normalt understreger ikke koste, men bevare liv og natur, og derfor beskæftiger kun med bestemte farlige systemet fejltilstande. Høj pålidelighed niveauer også skyldes god teknisk, fra sans for detaljer og næsten aldrig fra kun re-aktiv fiasko management.

En tidligere USA forsvarsminister, økonom James R. Schlesinger, sagde engang: "Pålidelighed er, trods alt, ingeniør i sin mest praktiske form."

Oversigt

Pålidelighed teknik til komplekse systemer kræver en anden, mere omfattende systemer tilgang end for ikke-komplekse systemer. Pålidelighed engineering kan indebære:

  • Brug undersøgelser og kravspecifikation
  • Iboende Design Pålidelighed: Hardware- og software-design, System Diagnostics design
  • Funktionel analyse
  • Human Factors / Fejl
  • Produktion og montage inducerede fejl
  • Vedligeholdelse inducerede fejl
  • Transport inducerede fejl
  • Opbevaring inducerede fejl
  • Manglende / pålidelighedstest
  • Reservedele strømpe
  • Teknisk dokumentation
  • Data og oplysninger erhvervelse / organisation

Effektiv pålidelighed engineering kræver forståelse af det grundlæggende i brudmekanismer for hvilke erfaringer, brede tekniske færdigheder og god viden fra mange forskellige særlige områder af teknik, som:

  • Tribologi
  • Stress
  • Brudmekanik / Træthed
  • Varmeteknik
  • Fluid mekanik / chok lastning engineering
  • Elektroteknik
  • Kemiteknik

Pålidelighed kan defineres på følgende måder:

  • Tanken om, at en vare er egnet til et formål med hensyn til tid
  • Kapaciteten af ​​en konstrueret, produceret eller vedligeholdt element til at udføre som påkrævet over tid
  • Kapaciteten af ​​en befolkning på designet, produceret eller vedligeholdt elementer til at udføre som påkrævet i løbet angivne tidspunkt
  • Modstanden mod svigt af et element over tid
  • Sandsynligheden for et element for at udføre en ønsket funktion under angivne betingelser for et bestemt tidsrum
  • Holdbarheden af ​​et objekt.

Mange engineering teknikker anvendes i pålidelighed engineering, såsom pålidelighed risikoanalyse, svigt og effekter analyse, fejltilstande, mekanismer og effekter analyse, fejl træ analyse, materiale stress og slid beregninger, træthed og krybning analyse, finite element metoden, pålidelighed forudsigelse, termisk analyse, korrosion analyse, menneskelige fejl analyse, pålidelighed testning, statistisk usikkerhed skøn, Monte Carlo simuleringer, design af eksperimenter, pålidelighed centreret vedligeholdelse, svigt rapportering og korrigerende ledelse handlinger. På grund af det store antal pålidelighed teknikker, deres bekostning, og de varierende grader af pålidelighed, der kræves for forskellige situationer, de fleste projekter udvikler en pålidelig program plan om at angive pålidelighed opgaver, der vil blive udført for den specifikke system.

I overensstemmelse med oprettelsen af ​​sikkerhedsmæssige tilfælde, for eksempel ARP4761, målet er at give et robust sæt kvalitative og kvantitative beviser for, at brug af en komponent eller et system ikke vil være forbundet med uacceptable risici. De grundlæggende skridt at tage er at:

  • Først grundigt identificere relevante usikkerhedsfaktorer "farer", f.eks potentielle forhold, begivenheder, menneskelige fejl, fejltilstande, interaktioner, brudmekanismer og grundlæggende årsager, efter specifikt analyser eller afprøvninger
  • Vurdere den dermed forbundne risiko-systemet, ved specifik analyse eller afprøvning
  • Foreslå afbødning, f.eks krav, design ændringer, afsløring, vedligeholdelse, uddannelse, hvorved risici kan sænkes og kontrolleret for på et acceptabelt niveau.
  • Bestem den bedste afbødning og få en aftale om de endelige, acceptable risikoniveauer, eventuelt baseret på cost-benefit-analyse

Risiko er kombinationen af ​​sandsynligheden og alvoren af ​​den manglende hændelse.

I en deminimus definition, sværhedsgraden af ​​fiaskoer omfatter udgifter til reservedele, mandetimer, logistik, skader og nedetid af maskiner, der kan forårsage produktionstab. En mere fuldstændig definition af fiasko også kan betyde skader, lemlæstelse og død af mennesker i systemet, og det samme til uskyldige tilskuere - i dette tilfælde, Pålidelighed Engineering bliver System Safety. Hvad der er acceptabelt, bestemmes af forvaltningsmyndigheden eller kunder eller foretaget samfund. Resterende risiko er den risiko, der resterer, når alle pålidelighed aktiviteter er færdig og omfatter un-identificerede risiko og er derfor ikke helt kvantificeres.

Pålidelighed og tilgængelighed programplan

Et pålidelighed program planen bruges til at dokumentere præcist, hvad "bedste praksis" er nødvendige for et bestemt system, samt tydeliggøre kundernes krav til pålidelighed vurdering. Til stor skala, komplekse systemer, bør pålideligheden programmet planen være et særskilt dokument. Ressource beslutsomhed for arbejdskraft og budgetter til test og andre opgaver er afgørende for et vellykket program. I almindelighed kan mængden af ​​arbejde, der kræves for et effektivt program for komplekse systemer er stort.

Et pålidelighed program plan er afgørende for at nå et højt niveau af pålidelighed, testbarhed, vedligeholdelse og det resulterende system Tilgængelighed og er udviklet tidligt i systemudvikling og raffineret over systemer livscyklus. Det præciseres ikke kun, hvad pålideligheden ingeniør gør, men også de opgaver, der udføres af andre interessenter. Et pålidelighed program plan er godkendt af øverste programforvaltningen, som er ansvarlig for tildeling af tilstrækkelige midler til gennemførelsen.

Et pålidelighed program Planen kan også bruges til at evaluere og forbedre tilgængeligheden af ​​et system af strategien for at fokusere på at øge testability & amp; vedligeholde og ikke på pålidelighed. Forbedring af vedligeholdelse er generelt lettere end pålidelighed. Maintainability skøn er generelt også mere nøjagtige. , Fordi usikkerheden i pålidelighed skøn er i de fleste tilfælde meget store, er det dog sandsynligt, at dominere tilgængeligheden problemet; selv i tilfælde Vedligeholdelsesevne niveauer er meget høje. Når pålidelighed ikke er under kontrol mere komplicerede spørgsmål kan opstå, ligesom mangel på arbejdskraft, reservedel tilgængelighed, logistiske forsinkelser, manglende reparation faciliteter, store omkostninger retro-fit og kompleks konfiguration management og andre. Problemet med upålidelighed kan også steget på grund af "dominoeffekt" af vedligeholdelse inducerede fejl efter reparationer. Kun at fokusere på vedligeholdelse er derfor ikke nok. Hvis fejl er forhindret, ingen af ​​de andre er af nogen betydning, og derfor pålidelighed generelt betragtes som den vigtigste del af tilgængelighed. Pålidelighed skal evalueres og forbedres i relation til både tilgængelighed og omkostninger ved ejerskab. Men som GM og Toyota sent har opdaget, TCO omfatter også down-stream omkostninger erstatningsansvar, når pålidelighed beregninger ikke i tilstrækkelig grad eller præcist løse kundernes personlige kropslige risici. Ofte er der behov for en afvejning mellem de to. Der kan være en maksimal forhold mellem tilgængelighed og ejeromkostninger. Testbarhed af et system bør også tages op i planen, da dette er forbindelsen mellem pålidelighed og vedligeholdelse. Vedligeholdelsen strategi kan påvirke pålideligheden af ​​et system, selv om det aldrig kan bringe det over den iboende pålidelighed.

Pålideligheden Planen bør klart give en strategi for tilgængelighed kontrol. Om der kun tilgængelighed eller også ejeromkostninger er vigtigere afhænger af brugen af ​​systemet. For eksempel, at et system er en kritisk link i et produktionssystem - fx en stor olie-platform - normalt tilladt at have en meget høj ejeromkostninger, hvis dette kan oversættes til endnu en mindre stigning i ledighed, da den manglende adgang til resultaterne platform i et massivt tab af indtægter, som let kan overstige de høje omkostninger ved ejerskab. En korrekt pålidelighed plan bør altid behandle Ramt analyse i sin samlede sammenhæng. Ramt står i dette tilfælde for pålidelighed, tilgængelighed, vedligeholdelse / vedligeholdelse og testbarhed i kontekst til kundens behov.

Pålidelighed krav

For ethvert system, en af ​​de første opgaver for pålidelighed engineering er i tilstrækkelig grad specificere pålidelighed og vedligeholde krav afledt af generelle tilgængelighed behov, og endnu vigtigere, fra ordentlig fejl analyse eller foreløbige testresultater. Krav bør begrænse designerne fra design bestemte upålidelige systemer. Indstilling kun tilgængelighed målene ikke er hensigtsmæssig. Det er en bred misforståelse om Pålidelighed Krav Engineering. Pålidelighed krav fat selve systemet, herunder test og krav til vurdering, og tilknyttede opgaver og dokumentation. Pålidelighed krav er inkluderet i den relevante system eller delsystem kravspecifikationer, testplaner og kontrakt udsagn. Oprettelse af ordentlige krav lavere niveau er kritisk.

Levering af kun kvantitative minimumsmål ikke tilstrækkeligt af forskellige årsager. En af grundene er, at en fuld validering af en kvantitativ pålidelighed fordeling på lavere niveauer for komplekse systemer ikke kan foretages som følge af 1) Det forhold, at kravene er probabilistiske 2) Den ekstremt høje usikkerheder involveret til påvisning af overholdelse af alle disse probabilistiske krav 3) Pålidelighed er en funktion af tid og præcise skøn over en pålidelighed nummer per post er kun tilgængelige meget sent i projektet, nogle gange endda kun mange år efter i service-brug. Sammenlign denne problem med den fortsætter balancering af eksempelvis lavere niveau systemet masse krav i udviklingen af ​​et fly, som allerede er ofte en stor virksomhed. Bemærk, at i dette tilfælde gør masserne kun adskiller sig med hensyn til kun nogle%, er ikke en funktion af tiden data er ikke-probabilistiske og tilgængelig allerede i CAD modeller. I tilfælde af pålidelighed, kan niveauerne af upålidelighed ændre sig med faktorer af årtier som følge af meget mindre afvigelser i design, proces eller noget andet. Oplysningerne er ofte ikke tilgængelige uden store usikkerheder i udviklingsfasen. Dette gør denne fordeling problem næsten umuligt at gøre i en nyttig, praktisk, forsvarlig måde, er Wich ikke medføre massiv over- eller under specifikation. Er derfor behov for en pragmatisk tilgang. For eksempel; brugen af ​​generelle niveauer / klasser af kvantitative krav kun afhængigt af alvoren af ​​svigt effekter. Også validering af resultaterne er en langt mere subjektive opgave end for nogen anden form for krav. Pålidelighed parametre -i form af MTBF - er langt de mest usikre designparametre i ethvert design.

Endvidere bør kravene pålidelighed design drive et design til at indarbejde funktioner, der forhindrer fejl opstår eller begrænse konsekvenserne af fejl i første omgang! Ikke kun for at lave nogle forudsigelser, kan dette potentielt distrahere engineering indsats for en slags regnskabsmæssige arbejde. Et design krav bør være så præcis nok, så en designer kan "design for at" det og kan også vise sig-gennem analyse eller afprøvnings-, at kravet er nået, og om muligt inden nogle et erklæret tillid. Enhver form for pålidelighed krav bør være detaljeret og kunne være afledt af fejlanalyse eller andre nogen form for pålidelighed test. Også, er der behov for krav om kontrolarbejdet f.eks krævede overbelastning belastninger og test nødvendige tid. At udlede disse krav på en effektiv måde, bør der anvendes en systemteknik baseret risikovurdering og -reduktion logik. Disse praktiske krav design skal drive design og ikke kun bruges til kontrolformål. Disse krav er på denne måde stammer fra fiasko analyse eller indledende test. Forståelse af denne forskel med kun ren kvantitativ kravspecifikation er altafgørende for udviklingen af ​​vellykkede systemer.

Vedligeholdelsen krav fat omkostninger til reparationer samt reparationstid. Testbarhed krav giver sammenhængen mellem pålidelighed og vedligeholdelse, og bør behandle sporbarhed af fejltilstande, isolation niveauer og skabelse af diagnostik.

Som anført ovenfor, bør pålidelighed ingeniører også behandle krav til forskellige pålidelighed opgaver og dokumentation under systemudvikling, test, produktion og drift. Disse krav er generelt anført i kontrakten opgørelse af arbejde og afhænger af, hvor meget spillerum kunden ønsker at give entreprenøren. Pålidelighed opgaver omfatter forskellige analyser, planlægning, og manglende rapportering. Opgave valg afhænger kritisk af systemet samt omkostninger. En sikkerhedskritisk system, kan kræve en formel fejl rapportering og review-proces i hele udviklingen, mens en ikke-kritisk Systemet kan stole på testrapporter endelige. De mest almindelige pålidelighed program opgaver er dokumenteret i pålidelighed program standarder, såsom MIL-STD-785 og IEEE 1332. Manglende rapportering analyse og afhjælpende foranstaltninger systemer er en fælles tilgang til produkt / proces pålidelighed overvågning.

Pålidelighed kultur

Praktisk, kan de fleste fejl i sidste ende spores tilbage til en grundlæggende årsager til den type menneskelige fejl af nogen art. For eksempel, menneskelige fejl i:

  • Brug studier
  • Krav analyse / indstilling
  • Konfiguration kontrol
  • Forudsætninger
  • Beregninger / simuleringer / FEM-analyse
  • Design
  • Konstruktionstegninger
  • Afprøvning
  • Statistisk analyse
  • Produktion
  • Kvalitetskontrol
  • Vedligeholdelse
  • Vedligeholdelsesmanualer
  • Forkert tilbagemeldinger af oplysninger
  • etc.

Men mennesker er også meget godt i detektering af svigt, korrektion af fejl og improvisere, når unormale situationer opstår. Den politik, menneskelige handlinger skal være helt udelukkes enhver design og produktion proces for at forbedre pålidelighed kan ikke være derfor effektive. Nogle opgaver er bedre udført af mennesker og nogle er bedre udføres af maskiner. Endvidere kan menneskelige fejl i ledelse og organisering af data og oplysninger, eller misbrug eller misbrug af poster, der også bidrager til upålidelighed. Dette er kernen grunden til kan kun opnås et højt niveau af pålidelighed for komplekse systemer ved at følge en robust systemudvikling proces med ordentlig planlægning og udførelse af validering og verificering opgaver. Dette omfatter også omhyggelig organisering af data og udveksling af oplysninger og skabe en "pålidelighed kultur" i samme forstand som havende en "sikkerhedskultur" er altafgørende for udviklingen af ​​sikkerhedskritiske systemer.

Design for pålidelighed

Pålidelighed design begynder med udviklingen af ​​en model. Pålidelighed og tilgængelighed modeller bruger blokdiagrammer og fejl træer for at give en grafisk middel til at vurdere forholdet mellem de forskellige dele af systemet. Disse modeller kan indeholde forudsigelser baseret på manglende satser taget fra historiske data. Mens forudsigelser er ofte ikke korrekt i absolut forstand, er de værdifulde til at vurdere relative forskelle i design alternativer. Maintainability parametre, for eksempel MTTR, er andre indgange til disse modeller.

Den vigtigste fundamentale initierende årsager og brudmekanismer skal identificeres og analyseres med engineering værktøjer. Der bør fastsættes en bredt sæt af praktiske retningslinjer og praktiske ydeevne og pålidelighed krav til designere, så de kan generere lave stressede designs og produkter, der beskytter eller er beskyttet mod skader og overdreven slitage. Korrekt Validering af input belastninger kan være nødvendig og verifikation for pålidelighed "præstation" af testning kan være nødvendig.

En af de vigtigste design teknikker er redundans. Det betyder, at hvis en del af systemet ikke, der er en alternativ sti succes, såsom et backup-system. Grunden til dette er den ultimative design valg er relateret til det faktum, at høje tillid pålidelighed beviser for nye dele / elementer er ofte ikke til rådighed eller ekstremt dyrt at opnå. Ved at skabe redundans, sammen med en høj grad af overvågning fiasko og undgåelse af fælles årsag fiaskoer, selv et system med relativ dårlig enkelt kanal pålidelighed, kan gøres meget pålidelige på systemniveau. Ingen test af pålidelighed skal kræves til dette. Endvidere ved anvendelse af redundans og anvendelsen af ​​forskellige design og fremstillingsprocesser for de enkelte uafhængige kanaler, er mindre følsomhed over for kvalitetsproblemer oprettet og kan opnås meget høje niveau af pålidelighed på alle tidspunkter af udviklingsomkostningerne cyklusser. Redundans kan også anvendes i systemteknik ved at dobbeltklikke kontrolkravene, data, design, beregninger, software og tests for at overvinde systematiske fejl.

Et andet design teknik til at undgå svigt kaldes fysik fiasko. Denne teknik bygger på at forstå de fysiske statiske og dynamiske brudmekanismer. Den tegner sig for variation i belastning, styrke og stress, der fører til svigt ved højt niveau af detaljer, muligt med anvendelse af moderne finite element metode software programmer, der kan håndtere komplekse geometrier og mekanismer som krybning, stress afslapning, træthed og probabilistisk design. Materialet eller komponent kan re-designet til at reducere sandsynligheden for fiasko og for at gøre det mere robust over for variation. En anden almindelig design teknik er komponent derating: Valg komponenter, hvis tolerance væsentligt overstiger den forventede stress, som ved hjælp af en tungere gauge ledning, der overstiger den normale specifikation for det forventede elektrisk strøm.

En anden effektiv måde at behandle usikkerhedsfaktorer spørgsmål er at udføre analyser for at kunne forudsige nedbrydning og være i stand til at forhindre uplanlagt ned begivenheder / fejl opstår. RCM programmer kan anvendes til dette.

Mange opgaver, teknikker og analyser er specifikke for bestemte brancher og applikationer. Almindeligvis omfatter disse:

Resultaterne præsenteres i løbet af systemdesign anmeldelser og logistik anmeldelser. Pålidelighed er blot et krav blandt mange systemkrav. Engineering handel undersøgelser bruges til at bestemme den optimale balance mellem pålidelighed og andre krav og begrænsninger.

Pålidelighed forudsigelse og forbedring

Pålidelighed forudsigelse er kombinationen af ​​oprettelsen af ​​en ordentlig pålidelighed model sammen med estimering af inputparametre for denne model, og endelig at give et systemniveau estimat for produktionen pålidelighed parametre.

Nogle anerkendte pålidelighed engineering specialister - f.eks Patrick O'Connor, R. Barnard - har hævdet, at for meget vægt ofte er givet til forudsigelse af pålidelighed parametre og større indsats bør afsættes til forebyggelse af fejl. Fejl kan og bør forhindres i første omgang for de fleste tilfælde. Vægt på kvantificering og fastsættelse af mål i form af MTBF kan give den opfattelse, at der er en grænse for størrelsen af ​​pålidelighed, der kan opnås. I teorien er der ingen iboende begrænsning og højere pålidelighed behøver ikke at være dyrere i udviklingen. En anden af ​​deres argumenter er, at forudsigelse af pålidelighed baseret på historiske data kan være meget misvisende, da en sammenligning gælder kun for præcis det samme design, produkter, fremstillingsprocesser og vedligeholdelse under nøjagtig de samme belastninger og miljømæssig sammenhæng. Selv en mindre ændring i detaljer i nogen af ​​disse kan få store virkninger på pålidelighed. Endvidere normalt de upålidelige og vigtige elementer er oftest udsættes for mange modifikationer og ændringer. Engineering design er i de fleste brancher opdateret ofte. Dette er grunden til, at de almindelige statistiske metoder og processer, som anvendes i den medicinske industri eller forsikring gren er ikke så effektive til ingeniør. En anden overraskende men logisk argument er, at for at være i stand til præcist at forudsige pålidelighed ved prøvning, de nøjagtige mekanismer for fiasko må have været kendt i de fleste tilfælde, og derfor - i de fleste tilfælde - kan forebygges! Efter den forkerte vej ved at forsøge at kvantificere og løse en kompleks pålidelighed engineering problem i form af MTBF eller Sandsynlighed og brug af re-aktiv tilgang er nævnt af Barnard som "Playing the Numbers Game" og anses for dårlig praksis.

For eksisterende systemer, er det hævdes, at ansvarlige programmer direkte ville analysere og forsøge at rette den egentlige årsag til opdagede fejl og derved kan gøre den indledende MTBF estimat fuldt ugyldig som nye antagelser af effekten af ​​plasteret / redesign skal ske. Et andet praktisk problem vedrører en generel mangel på detaljerede svigt data og ikke i overensstemmelse filtrering af svigt data eller ignorere statistiske fejl, som er meget højt for sjældne begivenheder. Meget klare retningslinjer skal være til stede for at kunne tælle og sammenligne fejl, relateret til forskellige typer af dybereliggende årsager. Sammenligning anden type årsager kan føre til fejlagtige skøn og forkerte forretningsmæssige beslutninger om fokus for forbedring.

For at udføre en ordentlig kvantitativ pålidelighed forudsigelse for systemer kan være svært og kan være meget dyrt, hvis det gøres ved at teste. På en del-niveau, kan der opnås resultater ofte med højere selvtillid så mange prøver, kan anvendes til den tilgængelige test finansielle budget, men desværre disse tests kan mangle gyldigheden på systemniveau på grund af de antagelser, der skulle foretages en del niveau test. Disse forfattere hævder, at det ikke kan understreges nok, at test for pålidelighed bør gøres for at skabe fejl i første omgang, lære af dem og til at forbedre systemet / del. Den generelle konklusion drages, at en nøjagtig og en absolut forudsigelse - ved datafelt sammenligning eller afprøvning - af pålidelighed i de fleste tilfælde ikke er muligt. En undtagelse kan være fejl, der skyldes slid-out problemer som træthed fiaskoer. I indledningen af ​​MIL-STD-785 er der skrevet, at pålideligheden forudsigelse bør anvendes med stor forsigtighed, hvis ikke kun bruges til sammenligning i samhandelen-off studier.

Se også: Risikovurdering # Kvantitativ risikovurdering - Kritikere afsnit

Pålidelighed teori

Pålidelighed er defineret som sandsynligheden for, at en enhed vil udføre sin tilsigtede funktion i en bestemt periode, under nærmere angivne vilkår. Matematisk kan dette udtrykkes som,

Der er et par vigtige elementer i denne definition:

  • Pålidelighed er baseret på "tilsigtede funktion:" Generelt er dette forstås drift uden fejl. Men selv om ingen enkelt del af systemet svigter, men systemet som helhed ikke gør, hvad der var hensigten, så er det stadig opkræves mod systemets pålidelighed. Systemet kravspecifikation er kriteriet mod hvilken pålidelighed måles.
  • Pålidelighed gælder for en bestemt periode. I praksis betyder det, at et system har en bestemt chance for, at det vil fungere uden fejl før tid. Pålidelighed engineering sikrer, at komponenter og materialer vil opfylde kravene i den specificerede tid. Bortset tidsenheder kan undertiden anvendes.
  • Pålidelighed er begrænset til drift under angivne betingelser. Denne begrænsning er nødvendig, fordi det er umuligt at designe et system for ubegrænset betingelser. En Mars Rover vil have forskellige nærmere angivne betingelser end en familie bil. Driftsmiljøet skal løses i løbet af design og test. Det samme rover kan være nødvendigt at operere i varierende forhold, der kræver yderligere kontrol.

Kvantitative system, pålidelighed parametre - teori

Kvantitative krav specificeres ved hjælp af pålidelighed parametre. Den mest almindelige pålidelighed parameter er den gennemsnitlige tid til at mislykkes, som også kan angives som den manglende sats) eller antallet af fejl i en given periode. Disse parametre kan være nyttige for højere systemkrav niveauer og systemer, der drives hyppigt, såsom de fleste køretøjer, maskiner og elektronisk udstyr. Pålidelighed stiger som de MTTF stiger. Den MTTF er sædvanligvis angivet i timer, men kan også anvendes sammen med andre måleenheder, såsom miles eller cykler. Brug MTTF værdier lavere systemets niveauer kan være meget misvisende, specielt hvis de fejl Modes og mekanismer Det drejer sig ikke er specificeret med det.

I andre tilfælde er pålidelighed angivet som sandsynligheden for missionens succes. For eksempel kan pålideligheden af ​​en planlagt fly flyvning angives som en dimensionsløs sandsynlighed eller en procentsats, som i systemet sikkerhed teknik.

Et særligt tilfælde af missionens succes er single-shot udstyr eller system. Disse er anordninger eller systemer, der forbliver relativt hvilende og kun opererer én gang. Eksempler omfatter bil airbags, termiske batterier og missiler. Single-shot pålidelighed er specificeret som en sandsynlighed på én gang succes, eller er indordnet i en beslægtet parameter. Single-shot missil pålidelighed kan angives som et krav om sandsynligheden for et hit. For sådanne systemer, sandsynligheden for fiasko på efterspørgslen er pålideligheden foranstaltning - som faktisk er et utilgængelighed nummer. Denne PFD stammer fra dumpeprocent og mission tid for ikke-repareres systemer.

For repareres systemer, er det fremstillet af dumpeprocent og middelværdi-tid-til-reparation og test interval. Denne foranstaltning kan ikke være unik for et givet system, da denne foranstaltning afhænger af den type af efterspørgslen. Ud over krav systemniveau, kan pålidelighed krav specificeres for kritiske undersystemer. I de fleste tilfælde er pålidelighed parametre specificeres med passende statistiske konfidensintervaller.

Pålidelighed modellering

Pålidelighed modellering er processen med at forudsige eller forstå pålideligheden af ​​en komponent eller et system forud for dets gennemførelse. To typer af analyser, der ofte bruges til at modellere et komplet system tilgængelighed adfærd er skyld træ analyse og pålidelighed blokdiagrammer. På komponentniveau samme type analyse kan anvendes sammen med andre. Inputtet til modellerne kan komme fra mange kilder: Test, Tidligere operationel erfaring feltdata eller data håndbøger fra samme eller blandede industrier kan anvendes. I alle tilfælde skal de data, der anvendes med stor forsigtighed, da forudsigelser er kun gyldige, hvis det samme produkt i samme forbindelse er brugt. Ofte forudsigelser kun lavet til at sammenligne alternativer.

For en del niveau forudsigelser, to separate områder af undersøgelsen er almindelige:

  • Fysik for fiasko tilgang benytter en forståelse af de fysiske svigt involverede mekanismer, såsom mekanisk revne reproduktion eller kemisk korrosion nedbrydning eller fiasko;
  • Delene understrege modelmetode er en empirisk metode til forudsigelse baseret på tælling af antallet og typen af ​​komponenter i systemet, og stress de gennemgår under drift.

Software pålidelighed eren mere udfordrende område, der skal overvejes, når det er en betydelig komponent til systemets funktionalitet.

Pålidelighed testkrav

Pålidelighed testkrav kan følge fra enhver analyse for der skal begrundes det første estimat for fiasko sandsynlighed, svigt eller virkning. Beviser kan genereres med en vis grad af tillid ved at teste. Med software-baserede systemer, sandsynligheden er en blanding af software og hardware-baserede fiaskoer. Test pålidelighed krav er problematisk af flere grunde. En enkelt test er i de fleste tilfælde utilstrækkelig til at generere tilstrækkeligt statistiske data. Flere test eller langvarige tests er normalt meget dyre. Nogle test er simpelthen upraktisk, og miljømæssige forhold kan være svært at forudsige over en systemer livscyklus.

Pålidelighed engineering bruges til at designe en realistisk og økonomisk overkommelig test program, der giver empirisk bevis for, at systemet opfylder dens pålidelighed krav. Statistiske tillid niveauer er vant til at løse nogle af disse bekymringer. En vis parameter udtrykkes sammen med en tilsvarende konfidensniveau: for eksempel en MTBF på 1000 timer ved 90% konfidensniveau. Fra denne specifikation, pålideligheden ingeniør kan for eksempel designe en test med eksplicitte kriterier for det antal timer, og antallet af fejl, indtil kravet efterleves eller mislykkedes. Er mulige forskellige slags tests.

Kombinationen af ​​krævede pålidelighed niveau og krævede konfidensniveau i høj grad påvirker udviklingen omkostningerne og risikoen for både kunden og producenten. Care er nødvendig for at udvælge den bedste kombination af krav - f.eks omkostningseffektivitet. Pålidelighed test kan udføres på forskellige niveauer, såsom komponent, delsystem og systemet. Desuden skal mange faktorer behandles under test og drift, såsom ekstreme temperaturer og luftfugtighed, stød, vibrationer eller andre miljømæssige faktorer. For systemer, der skal vare mange år, kan være nødvendig accelererede life tests.

Pålidelighed test

Formålet med pålidelighed test er at opdage potentielle problemer med design så tidligt som muligt og i sidste ende give tillid til, at systemet opfylder dens pålidelighed krav.

Pålidelighed test kan udføres på flere niveauer, og der er forskellige typer af test. Komplekse systemer kan testes på komponentniveau, kredsløb, enhed, enhed, delsystem og system niveau. For eksempel udfører miljøbelastning screening test på lavere niveauer, såsom stykke dele eller små forsamlinger, fanger problemer, før de forårsager svigt på højere niveauer. Test provenu under hvert niveau af integration gennem fuld-up-system test, udviklingsmæssige test, og operationel afprøvning, og derved reducere program risiko. Men test ikke mindske upålidelighed risiko.

Med hver test kunne gøres både en statistisk type 1 og type 2 fejl og afhænger af stikprøvestørrelsen, testtid, antagelser og behov forholdet diskrimination. Der er risiko for forkert at acceptere et dårligt design og risikoen for forkert at afvise et godt design.

Det er ikke altid muligt at teste alle systemkrav. Nogle systemer er dyre at teste; nogle brudformer kan tage år at observere; nogle komplekse interaktioner resulterer i et stort antal mulige sager test; og nogle tests kræver brug af begrænsede test intervaller eller andre ressourcer. I sådanne tilfælde kan anvendes forskellige tilgange til test, såsom accelereret liv test, design af eksperimenter og simuleringer.

Det ønskede niveau af statistisk sikkerhed spiller også en rolle i pålidelighedstest. Statistisk sikkerhed øges ved at øge enten testtiden eller antallet af testede varer. Pålidelighed testplaner er designet til at opnå den specificerede pålidelighed på det angivne konfidensniveau med det mindste antal test enheder og test tid. Forskellige testplaner resultere i forskellige risikoniveauer til producent og forbruger. Den ønskede pålidelighed, statistisk tillid og risikoniveauer for hver side påvirke den ultimative test planen. Kunden og udvikler bør på forhånd aftale om, hvordan pålidelighed krav vil blive testet.

Et centralt aspekt af pålidelighed test er at definere "fiasko". Selv om dette kan synes indlysende, er der mange situationer, hvor det ikke er klart, om en fejl er virkelig skyld i systemet. Variationer i testbetingelser, operatør forskelle, vejr og uventede situationer skaber forskelle mellem kunden og systemudvikler. Én strategi for at løse dette problem er at bruge en scoring konference proces. En scoring konference omfatter repræsentanter fra kunden, udvikleren, test organisation, pålideligheden organisation, og nogle gange uafhængige observatører. Den scoring konference processen er defineret i opgørelsen af ​​arbejdet. Hver testcase anses af gruppen og "scorede" som en succes eller fiasko. Denne scoring er det officielle resultat, der anvendes af pålideligheden ingeniør.

Som en del af kravene fase pålideligheden ingeniør udvikler en teststrategi med kunden. Testen strategi gør afvejninger mellem de behov, pålidelighed organisation, som ønsker så mange data som muligt, og begrænsninger som omkostninger, tidsplan og tilgængelige ressourcer. Testplaner og procedurer er udviklet til hver pålidelighed test, og resultaterne er dokumenteret.

Accelereret test

Formålet med accelereret liv test er at fremkalde fiasko felt i laboratoriet på et langt hurtigere tempo ved at give en hårdere, men ikke desto mindre repræsentativt, miljø. I en sådan test, produktet forventes at svigte i laboratoriet ligesom det ville have undladt på området, men i langt mindre tid. Hovedformålet med en accelereret test er et af følgende:

En accelereret test program kan opdeles i følgende trin:

Almindelige måde at bestemme et liv stress forhold er

Software pålidelighed

Software pålidelighed er en særlig aspekt af pålidelighed engineering. Systemets pålidelighed, per definition, omfatter alle dele af systemet, herunder hardware, software, understøttende infrastruktur, operatører og procedurer. Traditionelt, pålidelighed engineering fokuserer på kritiske hardware dele af systemet. Da den udbredte brug af digital integrerede kredsløb teknologi, har software blevet en stadig mere kritisk del af de fleste elektronik og dermed næsten alle nutidens systemer.

Der er betydelige forskelle, men i hvordan software og hardware opfører sig. De fleste hardware upålidelighed er resultatet af en komponent eller materiale fejl, der resulterer i at systemet ikke udfører sin tilsigtede funktion. Reparation eller udskiftning af hardware komponent genskaber systemet til dets oprindelige driftstilstand. Men software ikke undlade i samme forstand, at hardware svigter. I stedet software upålidelighed er resultatet af uventede resultater af software operationer. Selv relativt små softwareprogrammer kan have astronomisk store kombinationer af input og stater, der er umuligt udtømmende at teste. Gendannelse software til sin oprindelige tilstand fungerer kun, indtil den samme kombination af input og stater resulterer i den samme utilsigtede resultat. Software pålidelighed engineering skal tage højde for dette.

På trods af denne forskel i kilden til fiasko mellem software og hardware, har flere software pålidelighed modeller baseret på statistik blevet foreslået at kvantificere, hvad vi oplever med software: jo længere softwaren kører, jo højere sandsynlighed for, at det i sidste ende vil blive brugt i en uprøvet måde og udviser en latent fejl, der resulterer i en manglende ,,.

Som med hardware, software pålidelighed afhænger af gode krav, design og implementering. Software pålidelighed engineering er stærkt afhængig en disciplineret softwareudvikling proces at foregribe og design mod utilsigtede konsekvenser. Der er mere overlap mellem software kvalitet engineering og software pålidelighed engineering end mellem hardware kvalitet og pålidelighed. En god software udviklingsplan er et centralt aspekt af software pålidelighed programmet. Den software udviklingsplan beskriver design og kodning standarder, peer reviews, unit test, konfigurationsstyring, software målinger og software modeller, der skal anvendes under softwareudvikling.

En fælles pålidelighed metrisk er antallet af software fejl, som regel udtrykt som fejl per tusind linjer kode. Denne metrik, sammen med software gennemførelsestid, er nøglen til de fleste software pålidelighed modeller og skøn. Teorien er, at software pålidelighed stiger som antallet af fejl falder eller går ned. Etablering af en direkte forbindelse mellem fejl tæthed og gennemsnitlig tid-mellem-fiasko er svært, men på grund af den måde, software fejl er fordelt i koden, deres sværhedsgrad, og sandsynligheden for kombinationen af ​​input, der er nødvendige for at støde på fejlen. Ikke desto mindre fejl tæthed tjener som en nyttig indikator for pålideligheden ingeniør. Andre software målinger, såsom kompleksitet, anvendes også. Denne metrik er fortsat kontroversielt, da ændringer i softwareudvikling og verifikation praksis kan have dramatisk indvirkning på de samlede defekt satser.

Test er endnu vigtigere for software end hardware. Selv de bedste softwareudvikling resulterer i nogle software fejl, der er næsten ikke målbart indtil testet. Som med hardware, er software testet på flere niveauer, startende med de enkelte enheder, gennem integration og fuld-up-system test. I modsætning til hardware, er det tilrådeligt at springe niveauer af softwaretest. I alle faser af test, er software fejl opdages, korrigeret, og re-testet. Pålidelighed skøn opdateres baseret på fejlen tæthed og andre målinger. På et system niveau, kan opsamles gennemsnitlig tid-mellem-fiasko data og bruges til at estimere pålidelighed. I modsætning til hardware, der udfører nøjagtig den samme test på præcis den samme software konfiguration ikke giver øget statistisk tillid. I stedet software pålidelighed bruger forskellige målinger, såsom kode dækning.

Til sidst, er softwaren integreret med hardwaren i top-niveau-system, og software pålidelighed indordnet ved systemets pålidelighed. Software Engineering Institute modenhed kapacitet model er et fælles middel til at vurdere den overordnede udvikling af software proces for pålidelighed og kvalitet formål.

Pålidelighed engineering vs sikkerhedsteknik

Pålidelighed engineering adskiller sig fra sikkerhed teknik med hensyn til den form for farer, der anses. Pålidelighed engineering er i den eneste berørte med omkostningerne ende. Det vedrører alle Pålidelighed farer, der kan forvandle sig til hændelser med et bestemt niveau af tab af indtægter for virksomheden eller kunden. Disse kan koste grund af tab af produktion på grund af systemets utilgængelighed, uventede høje eller lave krav til reservedele, reparationsomkostninger, mandetimer, re-design, afbrydelser på normale produktion og mange andre indirekte omkostninger.

Sikkerhed teknik, på den anden side, er mere specifik og reguleres. Det drejer sig kun meget specifikke og system sikkerhedsrisici, der potentielt føre til alvorlige ulykker, og er primært beskæftiger sig med tab af menneskeliv, tab af udstyr, eller miljøskader. Den tilhørende systemkrav funktionelle pålidelighed krav er nogle gange ekstremt høj. Det beskæftiger sig med uønskede farlige begivenheder i samme forstand som pålidelighed engineering, men normalt ikke direkte se på omkostningerne og ikke beskæftiger sig med reparation handlinger efter svigt / ulykker. En anden forskel er niveauet for virkningen af ​​fejl på samfundet og kontrollen med regeringer. Sikkerhed engineering er ofte strengt kontrolleret af regeringerne.

Desuden kan sikkerhed teknik og pålidelighed engineering har endda modstridende krav. Dette vedrører systemets niveau arkitektur valg. For eksempel er det i toget signal kontrolsystemer er almindelig praksis at anvende et fejlsikkert system design koncept. I dette koncept skal fuldt kontrolleret til en ekstrem lav dumpeprocent svigt Forkert-side. Disse fejl er relateret til mulige alvorlige effekter, ligesom frontale kollisioner. Systemer er designet på en sådan måde, at den langt størstedelen af ​​fejl simpelthen vil resultere i en midlertidig eller totalt tab af signaler eller åbne kontakter af relæer og generere RED lys for alle tog. Dette er den sikre tilstand. Alle tog stoppes øjeblikkeligt. Dette fejlsikker logik kunne desværre sænke systemets pålidelighed. Årsagen til dette er den højere risiko for falsk udløsning som enhver fuld eller midlertidig, intermitterende svigt hurtigt er låst i en nedlukning tilstand. Forskellige løsninger er tilgængelige for dette problem. Se kapitel Fault Tolerance nedenfor.

Fejltolerance

Pålidelighed kan øges her ved hjælp af en 2oo2 redundans på en del eller systemniveau, men det betyder til gengæld sænke sikkerhedsniveauet. Fejltolerant stemmeret systemer kan øge både pålidelighed og sikkerhed på et system-niveau. I dette tilfælde kan øges den såkaldte "operationelle" eller "mission" pålidelighed samt sikkerheden af ​​et system. Dette er også almindelig praksis i Aerospace systemer, der har brug fortsat tilgængelighed og ikke har en fejlsikker tilstand.

Grundlæggende pålidelighed og mission pålidelighed

Ovenstående eksempel på en 2oo3 fejltolerant system, øger både mission pålidelighed samt sikkerhed. Dog vil "grundlæggende" systemets pålidelighed i dette tilfælde stadig være lavere end en ikke overflødige eller 2oo2 system! Grundlæggende pålidelighed refererer til alle fiaskoer, herunder dem, der måske ikke resultere i systemfejl, men resulterer i vedligeholdelse reparation handlinger, logistisk omkostninger, brug af reservedele mv For eksempel, udskiftning eller reparation af 1 kanal i en 2oo3 afstemningssystem, der er stadig opererer med én mislykkedes kanal bidrager til grundlæggende upålidelighed, men ikke mission upålidelighed. Også for eksempel svigt af baglygten for et luftfartøj ikke betragtes som et tab mission fiasko, men faktisk bidrager til den grundlæggende upålidelighed.

Detekterbarhed og fælles årsag fiaskoer

Ved brug af fejltolerante systemer eller systemer, der er udstyret med beskyttelsesfunktioner, sporbarhed af fejl og undgåelse af fælles årsag fiaskoer bliver altafgørende for sikker funktion og / eller mission pålidelighed.

Pålidelighed kontra kvalitet

Den daglige brug Udtrykket "kvaliteten af ​​et produkt" er løst forstås dens iboende grad af ekspertise. I industrien er dette gjort mere præcis ved at definere kvalitet at være "overensstemmelsen med kravene i starten af ​​brug". Antages produktspecifikationerne tilstrækkeligt indfange kunde eller behov, kvalitetsniveauet kan nu nøjagtigt målt ved den del af solgte enheder, der opfylder de detaljerede produktspecifikationer.

Men er krav og relaterede produktspecifikationer valideret? Vil det senere resultere i slidte elementer af træthed af korrosion mekanismer eller på grund af vedligeholdelse inducerede fiaskoer. Hvor mange af disse systemer stadig mødes funktion og fullfill behovene efter en uges drift? Hvad ydeevne tab ser vi? Eller var det resultere i en komplet fiasko system? Hvad sker der efter afslutningen af ​​en et års garanti periode? Og hvad efter 50 år Det er der "pålidelighed" kommer i. Kvalitet er et øjebliksbillede ved starten af ​​liv og hovedsageligt relateret til styring af produktspecifikationer og pålidelighed er mere et system-niveau film af dag-til-dag drift for mange år. Tid nul fejl er fremstilling fejl, undsluppet afsluttende prøve. De yderligere defekter, der vises over tid er "pålidelighed fejl" eller pålidelighed nedfald. Disse pålidelighed spørgsmål kan lige så vel opstå på grund af Iboende design spørgsmål, som kan have noget at gøre med ikke-overensstemmelsesafprøvninger produktspecifikationer. Elementer, der er produceret perfekt - ifølge alle produktspecifikationer - kan mislykkes over tid på grund manglende mekanisme. Teoretisk set vil alle elementer funktionelt mislykkes i uendelig tid. Kvalitetsniveauet kan beskrives med en enkelt fraktion defekt. At beskrive pålideligheden nedfald en sandsynlighed model, der beskriver den del nedfald over tid er nødvendig. Dette er kendt som det liv distributionsmodel.

Kvalitet er derfor relateret til fremstilling og Pålidelighed er mere beslægtet med valideringen af ​​sub-system eller lavere post krav og design og livscyklus løsninger. Elementer, der ikke overholder varespecifikationen i almindelighed vil gøre værre med hensyn til pålidelighed, men det behøver ikke altid at være tilfældet. Den fulde Kvantificering af denne kombinerede forhold er generelt meget vanskeligt. I tilfælde fremstilling varianser kan reduceres effektivt, seks sigma værktøjer kan bruges til at finde optimale procesløsninger og kan derved også øge pålideligheden. Andre Pålidelighed Solutions er generelt findes ved enten at forenkle et system, forståelse alle mekanismer fiasko involverede, øge robustheden og eventuelt at bruge redundans og fejltolerante systemer i tilfælde af høje tilgængelighed behov.

Pålidelighed operationel vurdering

Efter et system er produceret, pålidelighed engineering overvåger, vurderer og korrigerer fejl og mangler. Overvågningen omfatter elektronisk og visuel overvågning af kritiske parametre identificeret under fejlen træet analyse projekteringsfasen. Dataindsamlingen er stærkt afhængig af beskaffenheden af ​​systemet. De fleste store organisationer har kvalitet kontrolgrupper, der indsamler manglende data om køretøjer, udstyr og maskiner. Forbruger produktfejl er ofte spores med antallet af afkast. For systemer i hvilende opbevaring eller på standby, er det nødvendigt at etablere en formel overvågningsprogram til at inspicere og teste stikprøver. Eventuelle ændringer i systemet, såsom marken opgraderinger eller tilbagekaldelse reparationer, kræve yderligere pålidelighed test for at sikre pålideligheden af ​​ændringen. Da det ikke er muligt at forudse alle de fejltilstande i et givet system, især dem med et menneskeligt element, vil der opstår fejl. Pålideligheden Programmet omfatter også en systematisk årsagsanalyse, der identificerer de årsagssammenhænge, ​​der er involveret i svigt, således at effektive korrigerende handlinger kan gennemføres. Når det er muligt, er systemfejl og korrigerende handlinger indberettes til pålidelighed engineering organisation.

En af de mest almindelige metoder til at gælde for en pålidelighed operationel vurdering er fiasko rapportering, analyse og afhjælpende foranstaltninger systemer. Denne systematiske tilgang udvikler en pålidelighed, sikkerhed og logistik vurdering baseret på Fejl / Incident rapportering, ledelse, analyse og korrigerende / forebyggende handlinger. Organisationer i dag er ved at vedtage denne metode og udnytte kommercielle systemer såsom en web baseret skænderi applikation gør det muligt for en organisation at skabe en fiasko / hændelse datalager, hvorfra statistikker kan udledes til at se præcise og ægte pålidelighed, sikkerhed og kvalitet forestillinger.

Det er ekstremt vigtigt at have én fælles kilde skænderi for alle ende poster. Desuden bør testresultater kunne fanget her på en praktisk måde. Manglende vedtagelse en let at håndtere og vedligeholde integreret system vil sandsynligvis resultere i en fiasko skænderi program.

Nogle af de fælles output fra et skænderi systemet indeholder: Field MTBF, MTTR, Reservedele Forbrug, Pålidelighed Vækst, Manglende / Hændelser fordeling efter type, placering, del nej, serienummer, symptom osv.

Brugen af ​​tidligere data til at forudsige pålideligheden af ​​nye sammenlignelige systemer / elementer kan være misvisende, da pålidelighed er en funktion af led i brug og kan blive påvirket af små ændringer i design / fremstilling.

Pålidelighed organisationer

Systemer af nogen væsentlig kompleksitet er udviklet af organisationer af mennesker, såsom en kommerciel virksomhed eller en offentlig myndighed. Pålideligheden engineering organisation skal være i overensstemmelse med virksomhedens organisationsstruktur. For små, ikke-kritiske systemer, kan pålidelighed engineering være uformel. Som kompleksitet vokser, opstår behovet for en formel pålidelighed funktion. Fordi pålidelighed er vigtigt for kunden, kan kunden selv præcisere visse aspekter af pålideligheden organisation.

Der er flere almindelige typer af pålidelighed organisationer. Projektlederen eller maskinchef kan anvende en eller flere pålidelighed ingeniører direkte. I større organisationer, er der som regel et produkt forsikring eller speciale engineering organisation, som kan omfatte pålidelighed, vedligeholdelse, kvalitet, sikkerhed, menneskelige faktorer, logistik etc. I så fald, pålideligheden ingeniør rapporter til produktet forsikringen leder eller speciale Engineering Manager .

I nogle tilfælde kan en virksomhed ønsker at etablere en uafhængig pålidelighed organisation. Dette er ønskeligt at sikre, at systemets pålidelighed, som ofte er dyrt og tidskrævende, er det ikke urimeligt forbigået på grund af budget og tidsplan pres. I sådanne tilfælde pålideligheden ingeniør arbejder for projektet fra dag til dag, men er faktisk ansat og betalt af en separat organisation i virksomheden.

Fordi pålidelighed engineering er afgørende for tidlig systemdesign, er det blevet almindeligt, at pålidelighed ingeniører, men organisationen er struktureret, til at arbejde som en del af et integreret produkt teamet.

Certificering

American Society for Kvalitet har et program til at blive en Certified Pålidelighed Engineer, CRE. Certificering er baseret på uddannelse, erfaring og en certificeringstest: periodisk re-certificering er nødvendig. Liget af viden til testen indeholder: pålidelighed ledelse, design evaluering, produktsikkerhed, statistiske værktøjer, design og udvikling, modellering, pålidelighed testning, indsamling og anvendelse af data mv

En anden højt respekteret certificeringsprogram er CRP. For at opnå certificering skal kandidaterne udfylde en række kurser med fokus på vigtige Pålidelighed Engineering emner, ansøge den lærde mængde viden på arbejdspladsen og offentligt præsentere denne ekspertise i en industri konference eller tidsskrift.

Pålidelighed ingeniøruddannelse

Nogle universiteter tilbyder graduate grader i pålidelighed engineering. Andre pålidelighed ingeniører har typisk en ingeniøruddannelse, som kan være i en hvilken som helst inden for teknik, fra et godkendt universitet eller college program. Mange ingeniøruddannelser tilbyder pålidelighed kurser, og nogle universiteter har hele pålidelighed ingeniøruddannelser. En pålidelighed ingeniør kan registreres som en professionel ingeniør af staten, men dette er ikke kræves af de fleste arbejdsgivere. Der er mange professionelle konferencer og industrien uddannelsesprogrammer til rådighed for pålidelighed ingeniører. Der findes flere faglige organisationer for pålidelighed ingeniører, herunder IEEE Pålidelighed Society, American Society for Kvalitet og Society of Reliability Engineers.

  0   0
Forrige artikel Bellmawr School District
Næste artikel Klima Sårbarhed Monitor

Kommentarer - 0

Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha