Жүйелердің сенімділігі және қауіпсіздігі

Жүйелердегі сенімділік инженериясы – жабдықтың қатесіз жұмыс істеу қабілетін арттыруға бағытталған маңызды сала. Қауіпсіздік, қолжетімділік, R(t) функциясы туралы біліңіз.

24 мин оқу

100%

Дереккөз: Reliability engineering — Wikipedia

Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.

Мазмұны

Кіріспе

Сенімділік инженериясы – жабдықтың ақаусыз жұмыс істеу қабілетін баса көрсететін жүйелік инженерияның кіші саласы. Сенімділік – белгілі бір жүйе немесе компоненттің белгіленген жағдайларда, белгілі бір мерзім ішінде жұмыс істеу қабілетін сипаттайды. Сенімділік, қолжетімділікпен тығыз байланысты, ол компоненттің немесе жүйенің белгілі бір сәтте немесе уақыт аралығында жұмыс істеу қабілеті ретінде сипатталады. Сенімділік функциясы теориялық тұрғыда t уақытындағы табысқа жету ықтималдығы ретінде анықталады және R(t) деп белгіленеді. Іс жүзінде ол әртүрлі әдістер арқылы есептеледі, ал оның мәні 0 мен 1 аралығында болады, мұнда 0 – табысқа жету ықтималдығының жоқтығын, ал 1 – толық табысқа жетуді білдіреді. Бұл ықтималдық, егжей-тегжейлі (ақаулардың физикасы) талдау, бұрынғы деректер жиынтығы немесе сенімділікті сынау және сенімділікті модельдеу арқылы бағаланады. Қолжетімділік, сынаққа қабілеттілік, техникалық қызмет көрсету және жөндеу жиі сенімділік бағдарламаларындағы "сенімділік инженериясының" бөлігі ретінде қарастырылады. Сенімділік жүйелердің тиімділігіне маңызды рөл атқарады. Сенімділік инженериясы жоғары деңгейдегі инженерлік белгісіздік пен сәтсіздік тәуекелдерін болжау, алдын алу және басқарумен айналысады. Стохастикалық параметрлер сенімділікті анықтайды және оған әсер етеді, бірақ сенімділікке тек математика мен статистика арқылы ғана қол жеткізілмейді. "Осы тақырыптағы барлық оқулықтар мен әдебиеттер осы аспектілерге баса назар аударады және нақтылы белгісіздіктің ауқымдары болжау мен өлшеудің сандық әдістерін негізінен күшсіз етеді деген шындықты елемеуге бейім". Мысалы, "сәтсіздік ықтималдығын" теңдеуде символ немесе мән ретінде көрсету оңай, бірақ оның нақты шамасын іс жүзінде болжау өте қиын, себебі ол көп факторлы, сондықтан сенімділік теңдеуінің болуы сенімділіктің дәл болжамды өлшеміне тең болмайды. Сенімділік инженериясы сапа инженериясымен, қауіпсіздік инженериясымен және жүйелік қауіпсіздікпен тығыз байланысты, өйткені олар талдау үшін ортақ әдістерді қолданады және бір-бірінен деректерді талап етуі мүмкін. Жүйе сенімді және қауіпсіз болуы керек деуге болады. Сенімділік инженериясы жүйе тоқтаған кезде туындайтын шығындарға, қосалқы бөлшектерге, жөндеу жабдықтарына, персоналға және кепілдік талаптарына байланысты шығындарға назар аударады.

Sub discipline of systems engineering that emphasizes dependability

Reliability engineering is a sub discipline of systems engineering that emphasizes the ability of equipment to function without failure. Reliability describes the ability of a system or component to function under stated conditions for a specified period. Reliability is closely related to availability, which is typically described as the ability of a component or system to function at a specified moment or interval of time. The reliability function is theoretically defined as the probability of success at time t, which is denoted R(t). In practice, it is calculated using different techniques, and its value ranges between 0 and 1, where 0 indicates no probability of success while 1 indicates definite success. This probability is estimated from detailed (physics of failure) analysis, previous data sets, or through reliability testing and reliability modeling. Availability, testability, maintainability, and maintenance are often defined as a part of "reliability engineering" in reliability programs. Reliability often plays a key role in the cost effectiveness of systems. Reliability engineering deals with the prediction, prevention, and management of high levels of "lifetime" engineering uncertainty and risks of failure. Although stochastic parameters define and affect reliability, reliability is not only achieved by mathematics and statistics. "Nearly all teaching and literature on the subject emphasize these aspects and ignore the reality that the ranges of uncertainty involved largely invalidate quantitative methods for prediction and measurement." For example, it is easy to represent "probability of failure" as a symbol or value in an equation, but it is almost impossible to predict its true magnitude in practice, which is massively multivariate, so having the equation for reliability does not begin to equal having an accurate predictive measurement of reliability. Reliability engineering relates closely to Quality Engineering, safety engineering, and system safety, in that they use common methods for their analysis and may require input from each other. It can be said that a system must be reliably safe. Reliability engineering focuses on the costs of failure caused by system downtime, cost of spares, repair equipment, personnel, and cost of warranty claims.

Тарих

Сенімділік сөзі 1816 жылға дейін жетеді және алғаш рет ақын Сэмюэл Тейлор Колриджге қатысты. Екінші дүниежүзілік соғысқа дейін бұл термин көбінесе қайталанатындықпен байланысты болды; тест (кәндей-дағы ғылым саласында) бірдей нәтижелер бірнеше рет алынса, "сенімді" деп есептелді. 1920 жылдары доктор Уолтер А. Шевхарт Белл зертханасында статистикалық процестерді басқару арқылы өнімді жақсартуды ұсынды. Сол шамада Валодди Вейбулл шаршауға қатысты статистикалық модельдерді жасап жатты. Сенімділік инженериясының дамуы сапамен бірге жүрді. Сенімділік сөзінің қазіргі қолданысын 1940 жылдары АҚШ әскері анықтады, күтілген уақытта және белгіленген мерзімде жұмыс істейтін өнімді сипаттайды. Екінші дүниежүзілік соғыста көптеген сенімділік мәселелері сол кездегі электрондық жабдықтардың сенімсіздігіне және шаршау мәселелеріне байланысты болды. 1945 жылы М. А. Майнер ASME журналында "Шаршаудағы жинақталған зақым" атты маңызды мақаласын жариялады. Әскери саласында сенімділік инженериясының негізгі қолданысы – радар жүйелерінде және басқа электроникада қолданылатын вакуумдық түтіктер, олардың сенімділігі өте қиын және қымбат болып шықты. IEEE 1948 жылы Сенімділік қоғамын құрды. 1950 жылы АҚШ Қорғаныс министрлігі әскери жабдықтардың сенімділік әдістерін зерттеу үшін "Электрондық жабдықтардың сенімділігі жөніндегі кеңесшіл тобын" (AGREE) құрды. Бұл топ үш негізгі жолды ұсынды:

Компоненттердің сенімділігін арттыру. Жеткізушілерге сапа және сенімділік талаптарын белгілеу. Өрістегі деректерді жинап, ақаулардың түпкі себептерін анықтау. 1960 жылдары компоненттер мен жүйелер деңгейінде сенімділікті сынауға көбірек мән берілді. Сол кезде MIL STD 781 әскери стандарты құрылды. Осы кезеңде RCA әскери 217 нұсқаулығының көп қолданылатын алдыңғы нұсқасын жариялады, ол электрондық компоненттердің ақаулық деңгейін болжау үшін қолданылды. Тек компоненттердің сенімділігіне және эмпирикалық зерттеулерге (мысалы, Mil Std 217) назар аудару баяу төмендеді. Тұтынушы өнеркәсіптерінде қолданылатын тәжірибелі тәсілдер пайда болды. 1980 жылдары теледидарлар қатты жартылай өткізгіштерден жасала бастады. Автомобильдерде микрокомпьютерлердің әртүрлі түрлері пайда болды, олар қозғалтқыш бөлімінде де, приборлық тақтада да орналасты. Үлкен кондиционерлер, микротолқынды пештер және басқа да түрлі құрылғылар электрондық басқару жүйелерін алды. Байланыс жүйелері ескі механикалық коммутациялық жүйелерді алмастыру үшін электрониканы қабылдады. Bellcore телекоммуникация үшін тұтынушының болжамдау әдістемесін шығарды, ал SAE автомобиль саласы үшін ұқсас SAE870050 құжатын әзірледі. Болжамдардың сипаты онжылдық бойында өзгерді және интегралдық схемалардың (IC) күрделілігі ғана ақаулық деңгейін анықтайтын фактор емес екені анық болды. Кам Вонг ванна қисығын сұраққа тоғыстырған мақала жариялады. Осы онжылдықта көптеген компоненттердің ақаулық деңгейі 10 есеге төмендеді. Бағдарламалық қамтамасыз ету жүйелердің сенімділігі үшін маңызды болды. 1990 жылдары ИК-ті дамыту қарқыны күшейді. Жеке микрокомпьютерлерді кеңінен қолдану кең тарады, ал жеке компьютерлер нарығы Мур заңы бойынша ИК тығыздықтарын ұстап тұруға және әр 18 айда екі есеге көбейтуге көмектесті. Сенімділік инженериясы сәтсіздіктің физикасын түсінуге қарай өзгерді. Компоненттердің ақаулық деңгейі төмендеді, бірақ жүйелік деңгейдегі мәселелер маңыздырақ болды. Жүйелік ойлау маңыздырақ болды. Бағдарламалық жасақтама үшін сенімділікке сапалы тәсіл ұсынатын CMM моделі (Capability Maturity Model) әзірленді. ISO 9000 сертификаттаудың жобалау және әзірлеу бөлігінің бөлігі ретінде сенімділік өлшемдерін қосты. Әлемдік желінің кеңеюі қауіпсіздік және сенімнің жаңа мәселелерін тудырды. Бұрынғы жеткілікті сенімді ақпараттың жоқтығы мәселесі қазір күмәнді құндылықтағы көп ақпаратпен алмастырылды. Тұтынушылардың сенімділік мәселелерін деректерді пайдалану арқылы онлайн режимінде талқылауға болады. Микроэлектромеханикалық жүйелер (МЭМЖ), қолмен ұсталатын GPS және ұялы телефон мен компьютерді біріктіретін қолмен ұсталатын құрылғылар сияқты жаңа технологиялар сенімділікті сақтау үшін қиындықтар туғызды. Өнімді әзірлеу уақыты осы онжылдықта қысқаруды жалғастырды және үш жылда жасалған жұмыс 18 айда жасалды. Бұл сенімділік құралдары мен міндеттерін даму процесінің өзімен тығыз байланыстыру қажеттігін білдірді. Көп жағдайда сенімділік күнделікті өмірдің және тұтынушылар күтілімдерінің бөлігіне айналды.

Improve component reliability. Establish quality and reliability requirements for suppliers. Collect field data and find root causes of failures. In the 1960s, more emphasis was given to reliability testing on component and system levels. The famous military standard MIL STD 781 was created at that time. Around this period also the much used predecessor to military handbook 217 was published by RCA and was used for the prediction of failure rates of electronic components. The emphasis on component reliability and empirical research (e. g. Mil Std 217) alone slowly decreased. More pragmatic approaches, as used in the consumer industries, were being used. In the 1980s, televisions were increasingly made up of solid state semiconductors. Automobiles rapidly increased their use of semiconductors with a variety of microcomputers under the hood and in the dash. Large air conditioning systems developed electronic controllers, as did microwave ovens and a variety of other appliances. Communications systems began to adopt
electronics to replace older mechanical switching systems. Bellcore issued the first consumer prediction methodology for telecommunications, and SAE developed a similar document SAE870050 for automotive applications. The nature of predictions evolved during the decade, and it became apparent that die complexity wasn't the only factor that determined failure rates for integrated circuits (ICs). Kam Wong published a paper questioning the bathtub curve—see also reliability centered maintenance. During this decade, the failure rate of many components dropped by a factor of 10. Software became important to the reliability of systems. By the 1990s, the pace of IC development was picking up. Wider use of stand alone microcomputers was common, and the PC market helped keep IC densities following Moore's law and doubling about every 18 months. Reliability engineering was now changing as it moved towards understanding the physics of failure. Failure rates for components kept dropping, but system level issues became more prominent. Systems thinking has become more and more important. For software, the CMM model (Capability Maturity Model) was developed, which gave a more qualitative approach to reliability. ISO 9000 added reliability measures as part of the design and development portion of certification. The expansion of the World Wide Web created new challenges of security and trust. The older problem of too little reliable information available had now been replaced by too much information of questionable value. Consumer reliability problems could now be discussed online in real time using data. New technologies such as micro electromechanical systems (MEMS), handheld GPS, and hand held devices that combine cell phones and computers all represent challenges to maintaining reliability. Product development time continued to shorten through this
decade and what had been done in three years was being done in 18 months. This meant that reliability tools and tasks had to be more closely tied to the development process itself. In many ways, reliability has become part of everyday life and consumer expectations.

Шолу

Сенімділік – бұл өнімнің белгіленген пайдалану мерзімі бойында және белгіленген жұмыс жағдайларында, тұтынушының күтулеріне сай немесе одан да жоғары деңгейде өз қызметін атқару мүмкіндігінің шамасы.

Сенімділікті бағалаудың негіздері

Сенімділік тәуекелдерін бағалауда көптеген инженерлік әдістер қолданылады, мысалы, сенімділік блок-схемалары, қауіп-қатерлерді талдау, ақаулық режимі және әсерлерін талдау (FMEA), ақаулық ағашын талдау (FTA), сенімділікті орталықтандырған техникалық қызмет көрсету, (әдеттегі) жүктеме және материалдың кернеуі мен тозуын есептеу, (әдеттегі) шаршау және жыртылуды талдау, адам қателерін талдау, өндіріс ақауларын талдау, сенімділікті сынау және т.б. Бұл талдаулар тиімді болу үшін дұрыс және егжей-тегжейлі жүргізілуі керек. Сенімділік техникасының көптігі, олардың шығындары және әр түрлі жағдайларда талап етілетін сенімділіктің әртүрлі деңгейлері болғандықтан, көптеген жобалар сенімділік бағдарламасының жоспарын әзірлейді, ол сенімділік міндеттерін (жұмыс мәлімдемесі (SoW) талаптары) нақтылайды, бұл нақты жүйе үшін орындалады. Қауіпсіздік жағдайларын құруға сәйкес, мысалы ARP4761 бойынша, сенімділікті бағалаудың мақсаты компонент немесе жүйені пайдалану қабылдауға болмайтын тәуекелмен байланысты емес екендігіне сапалық және сандық дәлелдемелердің берік жиынтығын ұсыну болып табылады. Негізгі қадамдар: Ынанымсыздықтың "қауіптерін", мысалы, ықтимал жағдайларды, оқиғаларды, адам қателерін, ақаулық режимдерін, өзара әрекеттесулерді, ақаулық механизмдерін және негізгі себептерді нақты талдау немесе сынақтар арқылы толық анықтау. Жүйелік тәуекелді арнайы талдау немесе сынақ арқылы бағалау. Қауіпті азайту шараларын, мысалы, талаптарды, жобалауды өзгертуді, анықтау логикасын, техникалық қызмет көрсетуді және оқытуды ұсыну, осы арқылы тәуекелдерді азайту және оларды қолайлы деңгейде бақылауға болады. Ең жақсы азайтуды анықтау және шығындар мен пайданың талдауына негізделген, мүмкін, соңғы, қолайлы тәуекел деңгейлері туралы келісімге келу. Бұл жерде тәуекел - бұл ақаулық оқиғасының (сценарийдің) пайда болу ықтималдығы мен ауырлығының комбинациясы. Ауырлық деңгейі жүйе қауіпсіздігі немесе жүйе қолжетімділігі тұрғысынан қарастырылуы мүмкін. Қауіпсіздікке қатысты сенімділікті жүйелік қол жетімділікке қатысты сенімділіктен мүлдем басқа бағыт ретінде қарастыруға болады. Қолжетімділік пен қауіпсіздік динамикалық шиеленісті болуы мүмкін, өйткені жүйені тым қолжетімді ұстау қауіпсіз болмауы мүмкін. Инженерлік жүйені қауіпсіз күйге тым тез мәжбүрлеу жүйенің қол жетімділігіне кедергі келтіретін жалған дабылдарды тудырады. Де-минимиз анықтамасында ақаулардың ауырлығы қосалқы бөлшектердің, жұмыс уақытының, логистиканың, зақымданудың (екіншілік ақаулар) және өндірістің жоғалуына әкелетін машиналардың тоқтап қалуының құнын қамтиды. Ақаудың толық анықтамасы жүйедегі адамдардың жарақаттануын, бөлшектенуін және өлімін білдіруі мүмкін (шахта апаттарына, өнеркәсіптік апаттарға, ғарыш шаттлының сәтсіздіктеріне куә болу) және бейкүнә адамдарға (Бхопал, Лав Канал, Чернобыль немесе Сендай сияқты қалалардың азаматтарына куә болу және 2011 жылғы Тохоку жер сілкінісі мен цунами құрбандары) – осы жағдайда сенімділік инженериясы жүйе қауіпсіздігіне айналады. Қабылдауға болатын нәрсені басқарушы орган немесе тұтынушылар немесе зардап шеккен қауымдастықтар анықтайды. Қалдық тәуекел - барлық сенімділік іс-шаралары аяқталғаннан кейін қалған тәуекел, ол анықталмаған тәуекелді қамтиды, сондықтан оны толықтай өлшеу мүмкін емес. Техникалық жүйелердің күрделілігі, мысалы, жобалау мен материалдарды жетілдіру, жоспарлы тексерулер, қателіксіз жобалау және резервтік артықшылық тәуекелді азайтып, шығындарды арттырады. Тәуекелді ALARA (оның төменгі деңгейі ақылға қонымды) немесе ALAPA (оның төменгі деңгейі практикалық тұрғыда қол жетімді) деңгейлеріне дейін төмендетуге болады.

Many engineering techniques are used in reliability risk assessments, such as reliability block diagrams, hazard analysis, failure mode and effects analysis (FMEA), fault tree analysis (FTA), Reliability Centered Maintenance, (probabilistic) load and material stress and wear calculations, (probabilistic) fatigue and creep analysis, human error analysis, manufacturing defect analysis, reliability testing, etc. These analyses must be done properly and with much attention to detail to be effective. Because of the large number of reliability techniques, their expense, and the varying degrees of reliability required for different situations, most projects develop a reliability program plan to specify the reliability tasks (statement of work (SoW) requirements) that will be performed for that specific system. Consistent with the creation of safety cases, for example per ARP4761, the goal of reliability assessments is to provide a robust set of qualitative and quantitative evidence that the use of a component or system will not be associated with unacceptable risk. The basic steps to take are to:

Thoroughly identify relevant unreliability "hazards", e. g. potential conditions, events, human errors, failure modes, interactions, failure mechanisms, and root causes, by specific analysis or tests. Assess the associated system risk, by specific analysis or testing. Propose mitigation, e. g. requirements, design changes, detection logic, maintenance, and training, by which the risks may be lowered and controlled at an acceptable level. Determine the best mitigation and get agreement on final, acceptable risk levels, possibly based on cost/benefit analysis. The risk here is the combination of probability and severity of the failure incident (scenario) occurring. The severity can be looked at from a system safety or a system availability point of view. Reliability for safety can be thought of as a very different focus from reliability for system availability. Availability and safety can exist in dynamic tension as keeping a system too available can be unsafe. Forcing an engineering system into a safe state too quickly can force false alarms that impede the availability of the system. In a de minimis definition, the severity of failures includes the cost of spare parts, man hours, logistics, damage (secondary failures), and downtime of machines which may cause production loss. A more complete definition of failure also can mean injury, dismemberment, and death of people within the system (witness mine accidents, industrial accidents, space shuttle failures) and the same to innocent bystanders (witness the citizenry of cities like Bhopal, Love Canal, Chernobyl, or Sendai, and other victims of the 2011 Tōhoku earthquake and tsunami)—in this case, reliability engineering becomes system safety. What is acceptable is determined by the managing authority or customers or the affected communities. Residual risk is the risk that is left over after all reliability activities have finished, and includes the unidentified risk—and is therefore not completely quantifiable. The complexity of the technical systems such as improvements of design and materials, planned inspections, fool proof design, and backup redundancy decreases risk and increases the cost. The risk can be decreased to ALARA (as low as reasonably achievable) or ALAPA (as low as practically achievable) levels.

Сенімділік және қолжетімділік бағдарламасының жоспары

Сенімділік бағдарламасын іске қосу – бұл жай ғана бағдарламалық қамтамасыз етуді сатып алу емес; бұл сенімді өнімдер мен процестерді қамтамасыз ететін міндеттердің тізімі ғана емес. Сенімділік бағдарламасы – бұл бірегей өнімдер мен процестерге тән күрделі оқу және білім жүйесі. Ол басшылықпен қамтамасыз етіледі, команда ішінде дамыған дағдыларға негізделген, бизнес-процестерге интеграцияланған және бекітілген стандартты жұмыс тәжірибелерін орындау арқылы жүзеге асырылады. Сенімділік бағдарламасының жоспары нақты бір (ішкі) жүйе үшін қандай «үздік тәжірибелер» (тапсырмалар, әдістер, құралдар, талдаулар және сынақтар) қажет екенін, сондай-ақ сенімділікті бағау үшін клиенттердің талаптарын нақтылау үшін құжаттау үшін қолданылады. Ірі, күрделі жүйелер үшін сенімділік бағдарламасының жоспары жеке құжат ретінде жасалуы тиіс. Бағдарламаның сәтті болуы үшін сынақтар мен басқа да тапсырмаларға қажетті еңбек ресурстарын және бюджетті анықтау маңызды. Жалпы алғанда, күрделі жүйелер үшін тиімді бағдарламаны жүзеге асыру үшін қажетті жұмыс көлемі зор. Сенімділік бағдарламасының жоспары жоғары деңгейде сенімділікке, сынаққа, техникалық қызмет көрсетуге қол жеткізу және осының нәтижесінде жүйеге қолжетімділікке қол жеткізу үшін маңызды және жүйе әзірлеу кезінде ерте қалыптастырылып, жүйенің өмірлік циклы бойына жетілдіріледі. Ол сенімділік инженерінің қандай жұмыс істейтінін ғана емес, сонымен қатар басқа мүдделі тараптардың атқаратын тапсырмаларын да анықтайды. Тиімді сенімділік бағдарламасының жоспары бағдарламаның жоғарғы басшылығынан бекітілуі керек, ол оны іске асыру үшін жеткілікті ресурстарды бөлуге жауапты. Сенімділік бағдарламасының жоспары жүйенің қолжетімділігін бағалау және жақсарту үшін де қолданылуы мүмкін, бұл сенімділікті емес, сынаққа және техникалық қызмет көрсетуге бағытталған стратегия арқылы жүзеге асырылады. Техникалық қызмет көрсетуді жақсарту, сенімділікті жақсартуға қарағанда көбінесе оңайырақ. Сонымен қатар, техникалық қызмет көрсетуді бағалау (жөндеу жиілігі) көбінесе дәлірек болады. Алайда, сенімділік бағалаудағы белгісіздіктер көп жағдайда өте үлкен болғандықтан, олар қолжетімділікті есептеуде басымдық алады (болжамның белгісіздік мәселесі), тіпті техникалық қызмет көрсету деңгейі өте жоғары болған жағдайда да. Сенімділік бақылауда болмаған жағдайда, еңбек ресурстарының (жұмыскерлер/клиенттік қызмет көрсету мүмкіндігі) жетіспеушілігі, қосалқы бөлшектердің болуы, логистикалық кешігулер, жөндеу орталықтарының жетіспеушілігі, кең ауқымды жаңартулар және күрделі конфигурацияны басқару шығындары сияқты күрделі мәселелер туындауы мүмкін. Сенімділік мәселесі жөндеуден кейін техникалық қызмет көрсетуден туындаған ақаулардың «домино әсерінен» де күшейе алады. Сондықтан тек техникалық қызмет көрсетуді қамтамасыз ету жеткіліксіз. Егер ақаулардың алдын алуға қол жеткізілсе, басқа мәселелердің ешқайсысы маңызды емес, сондықтан сенімділік қолжетімділіктің ең маңызды бөлігі ретінде қарастырылады. Сенімділікті қолжетімділік және жалпы меншік құнына (TCO) қатысты бағалау және жақсарту қажет, себебі қосалқы бөлшектердің құны, техникалық қызмет көрсетуге жұмсалатын еңбек сағаттары, тасымалдау шығындары, сақтау шығындары, бөлшектердің ескіру тәуекелі және т.б. Бірақ GM және Toyota кейінірек анықтағандай, TCO клиенттердің денсаулығына қатысты тәуекелдерді жеткілікті немесе дәл қарастырмаған жағдайда, жауапкершілік шығындарын да қамтиды. Көбінесе екі аралықта компромисске келу қажет. Қолжетімділік пен меншік құны арасында максималды қатынас болуы мүмкін. Жүйенің сынаққа қабілеттілігі жоспарда қарастырылуы тиіс, өйткені бұл сенімділік пен техникалық қызмет көрсету арасындағы байланыс. Техникалық қызмет көрсету стратегиясы жүйенің сенімділігіне әсер етуі мүмкін (мысалы, профилактикалық және/немесе болжамды техникалық қызмет көрсету арқылы), бірақ ол оны өзіне тән сенімділіктен жоғары көтере алмайды. Сенімділік жоспарында қолжетімділікті бақылау стратегиясы нақты көрсетілуі тиіс. Қолжетімділік немесе меншік құны маңыздырақ болуы жүйенің қолданылуына байланысты. Мысалы, өндіріс жүйесінің маңызды буыны болып табылатын жүйе, мысалы, ірі мұнай платформасы, бұл шығын қолжетімділіктің тіпті аздап өсуіне әкелсе, меншік құны өте жоғары болуы мүмкін, өйткені платформаның қолжетімсіздігінен туындаған үлкен кіріс жоғалуы жоғары меншік құнынан оңай асып түседі. Дұрыс сенімділік жоспары әрқашан клиенттің қажеттіліктеріне қатысты RAMT талдауын толық контексте қарастыруы керек. RAMT – бұл сенімділік, қолжетімділік, техникалық қызмет көрсету/техникалық қызмет көрсету және сынаққа қабілеттілік.

Implementing a reliability program is not simply a software purchase; it is not just a checklist of items that must be completed that ensure one has reliable products and processes. A reliability program is a complex learning and knowledge based system unique to one's products and processes. It is supported by leadership, built on the skills that one develops within a team, integrated into business processes, and executed by following proven standard work practices. A reliability program plan is used to document exactly what "best practices" (tasks, methods, tools, analysis, and tests) are required for a particular (sub)system, as well as clarify customer requirements for reliability assessment. For large scale complex systems, the reliability program plan should be a separate document. Resource determination for manpower and budgets for testing and other tasks is critical for a successful program. In general, the amount of work required for an effective program for complex systems is large. A reliability program plan is essential for achieving high levels of reliability, testability, maintainability, and the resulting system availability, and is developed early during system development and refined over the system's life cycle. It specifies not only what the reliability engineer does, but also the tasks performed by other stakeholders. An effective reliability program plan must be approved by top program management, which is responsible for the allocation of sufficient resources for its implementation. A reliability program plan may also be used to evaluate and improve the availability of a system by the strategy of focusing on increasing testability & maintainability and not on reliability. Improving maintainability is generally easier than improving reliability. Maintainability estimates (repair rates) are also generally more accurate. However, because the uncertainties in the reliability estimates are in most cases very large, they are likely to dominate the availability calculation (prediction uncertainty problem), even when maintainability levels are very high. When reliability is not under control, more complicated issues may arise, like manpower (maintainers/customer service capability) shortages, spare part availability, logistic delays, lack of repair facilities, extensive retrofit and complex configuration management costs, and others. The problem of unreliability may be increased also due to the "domino effect" of maintenance induced failures after repairs. Focusing only on maintainability is therefore not enough. If failures are prevented, none of the other issues are of any importance, and therefore reliability is generally regarded as the most important part of availability. Reliability needs to be evaluated and improved related to both availability and the total cost of ownership (TCO) due to the cost of spare parts, maintenance man hours, transport costs, storage costs, part obsolete risks, etc. But, as GM and Toyota have belatedly discovered, TCO also includes the downstream liability costs when reliability calculations have not sufficiently or accurately addressed customers' bodily risks. Often a trade off is needed between the two. There might be a maximum ratio between availability and cost of ownership. The testability of a system should also be addressed in the plan, as this is the link between reliability and maintainability. The maintenance strategy can influence the reliability of a system (e. g., by preventive and/or predictive maintenance), although it can never bring it above the inherent reliability. The reliability plan should clearly provide a strategy for availability control. Whether only availability or also cost of ownership is more important depends on the use of the system. For example, a system that is a critical link in a production system—e. g., a big oil platform—is normally allowed to have a very high cost of ownership if that cost translates to even a minor increase in availability, as the unavailability of the platform results in a massive loss of revenue which can easily exceed the high cost of ownership. A proper reliability plan should always address RAMT analysis in its total context. RAMT stands for reliability, availability, maintainability/maintenance, and testability in the context of the customer's needs.

Сенімділік талаптары

Кез келген жүйе үшін сенімділік инженериясының алғашқы міндеттерінің бірі – жалпы қолжетімділік қажеттіліктерінен туындайтын және, ең бастысы, дұрыс жобалау қателіктерін талдау немесе алдын ала прототиптік сынақтар нәтижелерінен алынған сенімділік пен техникалық қызмет көрсету талаптарын тиісті деңгейде нақтылау болып табылады. Нақты талаптар (жобалауға мүмкіндік беретін) жобалаушыларды сенімсіз элементтерді/құрылымдарды/интерфейстерді/жүйелерді жобалаудан шектеуі керек. Тек қана қолжетімділік, сенімділік, сынаққа қабілеттілік немесе техникалық қызмет көрсету мақсаттарын белгілеу (мысалы, максималды қателік деңгейі) жеткіліксіз. Бұл – сенімділік талаптарын жобалау туралы кең таралған қате түсінік. Сенімділік талаптары жүйенің өзіне, соның ішінде сынақ пен бағалау талаптарына, олармен байланысты міндеттер мен құжаттамаға қатысты. Сенімділік талаптары тиісті жүйе немесе жүйе бөлімшесінің техникалық талаптарына, сынақ жоспарларына және шарттарға енгізілуі керек. Төменгі деңгейдегі талаптарды жасау өте маңызды. Ақпарат көбінесе әзірлеу кезеңінде үлкен белгісіздіктермен қолжетімді болмайды. Бұл осы бөлу мәселесін пайдалы, практикалық және жарамды түрде шешуді дерлік мүмкін емес етеді, нәтижесінде ерекшеліктердің шамадан тыс немесе жеткіліксіз болуына әкеледі. Сондықтан, прагматикалық тәсіл қажет – мысалы, сәтсіздік салдарының ауырлығына ғана байланысты сандық талаптардың жалпы деңгейлерін/санаттарын қолдану. Сонымен қатар, нәтижелерді растау кез келген басқа талаптарға қарағанда көбірек субъективті міндет болып табылады. (Сандық) сенімділік параметрлері – MTBF тұрғысынан – кез келген жобадағы ең белгісіз жобалау параметрлері болып табылады. Сонымен қатар, сенімділік жобалау талаптары жүйенің (немесе бөлігінің) жобалауын ақаулардың пайда болуын болдырмайтын немесе ақаулардың салдарларын бірінші кезекте шектеуге мүмкіндік беретін мүмкіндіктерді қосуға бағыттауы керек. Бұл болжамдар жасауға көмектесумен қатар, инженерлік күш-жігерді есептеу жұмысына бұрмаламайды. Жобалау талабы дизайнердің оған «жобалау» үшін жеткілікті дәл болуы керек, сондай-ақ талдау немесе сынақ арқылы талап орындалғанын дәлелдеуге болады, және мүмкін болса, белгілі бір сенімділік деңгейінде. Сенімділік талаптарының кез келген түрі егжей-тегжейлі болуы керек және ол ақаулық талдауынан (Элементтік кернеу және шаршау талдауы, Сенімділік қауіп талдауы, FTA, FMEA, Адам факторы талдауы, Функционалдық қауіп талдауы және т.б.) немесе кез келген сенімділік сынағынан туындауы мүмкін. Сондай-ақ, тексеру сынақтарына (мысалы, қажетті жүктемелік кернеулер) және сынақ уақытына қойылатын талаптар да қажет. Осы талаптарды тиімді түрде анықтау үшін жүйелік инженерияға негізделген тәуекелді бағалау және азайту логикасын қолдану керек. Жүйелердің неге және қалай бұзылуы мүмкін екендігі туралы толық ақпаратты қамтитын берік қауіптер журналы жүйелерін құру керек. Талаптар осылай анықталып, қадағалануы керек. Бұл практикалық жобалау талаптары жобалауды басқарады және тек тексеру мақсатында ғана қолданылмайды. Осы талаптар (көбінесе жобалау шектеулері) ақаулық талдауынан немесе алдын ала сынақтардан осылай туындайды. Бұл айырмашылықты түсіну, тек сандық (логистикалық) талаптарды анықтаумен (мысалы, қателік деңгейі / MTBF мақсаты) салыстырғанда, сәтті (кешенді) жүйелерді әзірлеуде маңызды. Техникалық қызмет көрсету талаптары жөндеуге кететін шығындарды, сондай-ақ жөндеу уақытын қамтиды. Сынаққа қабілеттілік талаптары (сынақ талаптарымен шатастырылмауы керек) сенімділік пен техникалық қызмет көрсету арасындағы байланысты қамтамасыз етеді және ақаулық түрлерін анықтауды (белгілі бір жүйе деңгейінде), оқшаулау деңгейлерін және диагностиканы (процедураларды) құруды қарастыруы керек. Сонымен қатар, басқарудағы адам қателері; деректер мен ақпаратты ұйымдастыру; немесе элементтерді дұрыс пайдаланбау немесе теріс пайдалану да сенімсіздікке әкелуі мүмкін. Осы себепті күрделі жүйелердің жоғары сенімділігіне тек жүйелік инженерия процесін қатаң сақтау арқылы қол жеткізілуі мүмкін, сондай-ақ растау және тексеру тапсырмаларын дұрыс жоспарлау және орындау арқылы. Бұл сонымен қатар деректерді және ақпаратты мұқият ұйымдастыруды және бөлісуді, сондай-ақ «сенімділік мәдениетін» құруды қамтиды, дәл сол сияқты, қауіпсіздікке маңызды жүйелерді әзірлеуде «қауіпсіздік мәдениетін» сақтау өте маңызды.

For any system, one of the first tasks of reliability engineering is to adequately specify the reliability and maintainability requirements allocated from the overall availability needs and, more importantly, derived from proper design failure analysis or preliminary prototype test results. Clear requirements (able to be designed to) should constrain the designers from designing particular unreliable items/constructions/interfaces/systems. Setting only availability, reliability, testability, or maintainability targets (e. g., max. failure rates) is not appropriate. This is a broad misunderstanding about Reliability Requirements Engineering. Reliability requirements address the system itself, including test and assessment requirements, and associated tasks and documentation. Reliability requirements are included in the appropriate system or subsystem requirements specifications, test plans, and contract statements. The creation of proper lower level requirements is critical. The information is often not available without huge uncertainties within the development phase. This makes this allocation problem almost impossible to do in a useful, practical, valid manner that does not result in massive over or under specification. A pragmatic approach is therefore needed—for example: the use of general levels/classes of quantitative requirements depending only on severity of failure effects. Also, the validation of results is a far more subjective task than any other type of requirement. (Quantitative) reliability parameters—in terms of MTBF—are by far the most uncertain design parameters in any design. Furthermore, reliability design requirements should drive a (system or part) design to incorporate features that prevent failures from occurring, or limit consequences from failure in the first place. Not only would it aid in some predictions, this effort would keep from distracting the engineering effort into a kind of accounting work. A design requirement should be precise enough so that a designer can "design to" it and can also prove—through analysis or testing—that the requirement has been achieved, and, if possible, within some a stated confidence. Any type of reliability requirement should be detailed and could be derived from failure analysis (Finite Element Stress and Fatigue analysis, Reliability Hazard Analysis, FTA, FMEA, Human Factor Analysis, Functional Hazard Analysis, etc.) or any type of reliability testing. Also, requirements are needed for verification tests (e. g., required overload stresses) and test time needed. To derive these requirements in an effective manner, a systems engineering based risk assessment and mitigation logic should be used. Robust hazard log systems must be created that contain detailed information on why and how systems could or have failed. Requirements are to be derived and tracked in this way. These practical design requirements shall drive the design and not be used only for verification purposes. These requirements (often design constraints) are in this way derived from failure analysis or preliminary tests. Understanding of this difference compared to only purely quantitative (logistic) requirement specification (e. g., Failure Rate / MTBF target) is paramount in the development of successful (complex) systems. The maintainability requirements address the costs of repairs as well as repair time. Testability (not to be confused with test requirements) requirements provide the link between reliability and maintainability and should address detectability of failure modes (on a particular system level), isolation levels, and the creation of diagnostics (procedures). Furthermore, human errors in management; the organization of data and information; or the misuse or abuse of items, may also contribute to unreliability. This is the core reason why high levels of reliability for complex systems can only be achieved by following a robust systems engineering process with proper planning and execution of the validation and verification tasks. This also includes the careful organization of data and information sharing and creating a "reliability culture", in the same way, that having a "safety culture" is paramount in the development of safety critical systems.

Сенімділікті қамтамасыз ететін жобалау

Сенімділік үшін жобалау (DfR) – өнімнің қызмет ету ортасында, өмірлік циклы бойы сенімділік талаптарына сай келуін қамтамасыз ететін құралдар мен процедураларды қамтитын процесс. DfR өнімнің жобалау кезеңінде жүзеге асырылып, өнімнің сенімділігін алдын ала жақсартуға бағытталған. DfR көбінесе Design for Excellence (DfX) стратегиясының құрамдас бөлігі ретінде қолданылады.

Статистикаға негізделген тәсіл (яғни МТБФ)

Сенімділік жобалау (жүйе) моделін әзірлеуден басталады. Сенімділік және қолжетімділік модельдері жүйенің әртүрлі бөліктері арасындағы қатынастарды бағалау үшін блок-схемалар мен ақаулық ағашын талдауды графикалық құрал ретінде пайдаланады. Бұл модельдер тарихи деректерден алынған сәтсіздік жиілігіне негізделген болжамдарды қамтуы мүмкін. (Кіріс деректері) болжамдары абсолюттік мағынада әрдайым дұрыс болмаса да, олар жобалау нұсқаларының салыстырмалы айырмашылықтарын бағалау үшін құнды. Мысалы, жөндеуге кеткен орташа уақыт (MTTR) сияқты техникалық қызмет көрсету параметрлерін де мұндай модельдерге кіріс ретінде қолдануға болады. Ең маңызды бастапқы себептері мен ақаулық механизмдерін инженерлік құралдармен анықтау және талдау қажет. Дизайнерлерге өнімнің сенімділігі мен қызмет ету мерзімін арттыратын, зақымдану мен тозудан қорғайтын немесе қорғалатын төмен кернеулі жобаларды жасауға көмектесетін практикалық нұсқаулар берілуі керек. Сынақ арқылы сенімділіктің "жұмысын" тексерумен қатар, кіріс жүктемелерін (талаптарды) дұрыс растау да қажет болуы мүмкін. Ең маңызды жобалау техникаларының бірі – артықшылық. Яғни, жүйенің бір бөлігі сәтсіз болса, резервтік жүйе сияқты басқа сәттілік жолы болуы керек. Бұл таңдаудың себебі жаңа бөлшектер немесе жүйелер үшін жоғары сенімділік дәлелдерінің көбінесе қолжетімсіз немесе алуы өте қымбат болуымен байланысты. Артықшылықты, ақауларды жоғары деңгейде бақылаумен және жалпы себептерге байланысты ақауларды болдырмаумен біріктіру арқылы, тіпті салыстырмалы түрде нашар бір арналы (бөлшек) сенімділігі бар жүйе де жүйелік деңгейде (миссиялық сенімділікке дейін) өте сенімді болуы мүмкін. Мұндай жағдайда сенімділікті сынау қажет емес. Артықшылықпен қатар, бір тәуелсіз арналар үшін әртүрлі жобаларды немесе өндіріс процестерін (мысалы, ұқсас бөлшектердің әртүрлі жеткізушілері арқылы) пайдалану сапа мәселелеріне (мысалы, бір жеткізушіде ерте сәтсіздіктер) сезімталдықты азайтады, бұл даму циклінің барлық кезеңдерінде (жастық шақтан ұзақ мерзімді өмірге дейін) өте жоғары сенімділікке қол жеткізуге мүмкіндік береді. Артықшылықты жүйелік инженерияда талаптарды, деректерді, жобаларды, есептеулерді, бағдарламалық жасақтаманы және жүйелі ақауларды жою үшін екі рет тексеру арқылы да қолдануға болады. Сенімділік мәселелерін шешудің тағы бір тиімді жолы – тозуды болжайтын талдау жүргізу, бұл жоспарланбаған тоқтаулардың/сәтсіздіктердің алдын алуға мүмкіндік береді. Бұл үшін RCM (Сенімділікке бағытталған техникалық қызмет көрсету) бағдарламаларын қолдануға болады.

Reliability design begins with the development of a (system) model. Reliability and availability models use block diagrams and Fault Tree Analysis to provide a graphical means of evaluating the relationships between different parts of the system. These models may incorporate predictions based on failure rates taken from historical data. While the (input data) predictions are often not accurate in an absolute sense, they are valuable to assess relative differences in design alternatives. Maintainability parameters, for example Mean time to repair (MTTR), can also be used as inputs for such models. The most important fundamental initiating causes and failure mechanisms are to be identified and analyzed with engineering tools. A diverse set of practical guidance as to performance and reliability should be provided to designers so that they can generate low stressed designs and products that protect, or are protected against, damage and excessive wear. Proper validation of input loads (requirements) may be needed, in addition to verification for reliability "performance" by testing. One of the most important design techniques is redundancy. This means that if one part of the system fails, there is an alternate success path, such as a backup system. The reason why this is the ultimate design choice is related to the fact that high confidence reliability evidence for new parts or systems is often not available, or is extremely expensive to obtain. By combining redundancy, together with a high level of failure monitoring, and the avoidance of common cause failures; even a system with relatively poor single channel (part) reliability, can be made highly reliable at a system level (up to mission critical reliability). No testing of reliability has to be required for this. In conjunction with redundancy, the use of dissimilar designs or manufacturing processes (e. g. via different suppliers of similar parts) for single independent channels, can provide less sensitivity to quality issues (e. g. early childhood failures at a single supplier), allowing very high levels of reliability to be achieved at all moments of the development cycle (from early life to long term). Redundancy can also be applied in systems engineering by double checking requirements, data, designs, calculations, software, and tests to overcome systematic failures. Another effective way to deal with reliability issues is to perform analysis that predicts degradation, enabling the prevention of unscheduled downtime events / failures. RCM (Reliability Centered Maintenance) programs can be used for this.

Физикалық ақаулықтарға негізделген тәсіл

Электрондық құрастырулар үшін, бұзылу физикасы деп аталатын жаңа тәсілге бет бұру күшейді. Бұл техника физикалық статикалық және динамикалық ақау механизмдерін түсінуге негізделген. Ол жүктеме, беріктік және кернеудегі өзгерістерді, олардың ақауға қалай әкелетінін егжей-тегжейлі түрде қарастырады. Мұндай мүмкіндіктер қазіргі заманғы шекті элементтер әдісін (FEM) қолдану арқасында пайда болады, бұл бағдарламалар күрделі геометрияларды және механизмдерді, мысалы, иілу, кернеуді жеңілдету, шаршау және ықтималдық жобалауды (Монте-Карло әдістері / DOE) басқара алады. Материалды немесе компонентті ақау болу ықтималдығын азайту және оны осындай өзгерістерге төтеп беруге жарамды ету үшін қайта жобалауға болады. Тағы бір көп қолданылатын жобалау тәсілі – компоненттерді номиналдық көрсеткіштен төмендету, яғни, күтілетін кернеу деңгейінен әлдеқайда артық сипаттамалары бар компоненттерді таңдау, мысалы, күтілетін электр тогына қатысты, әдеттегіден қалың электр сымдарын қолдану.

Тілдің маңызы

Сенімділік инженерлері, ақауды немесе қауіпті сипаттау үшін сандық немесе сапалық әдістерді қолданғанда, қауіптерді нақты анықтау және мәселелерді шешу үшін тілге сүйенеді. Қолданылатын тіл функцияның/элементтің/жүйенің және оның күрделі ортасының осы функцияның/элементтің/жүйенің ақаулығына қатысты реттелген сипаттамасын жасауға көмектесуі тиіс. Жүйелік инженерия проблеманы (және онымен байланысты қауіптерді) сипаттау үшін дұрыс сөздерді табуға байланысты, сондықтан оларды инженерлік шешімдер арқылы оңай шешуге болады. Джек Ринг жүйелік инженердің жұмысы – «жобаны тілге айналдыру» дейді. (Ring және басқалар, 2000 ж.) Бөлшектердің/жүйенің ақаулары үшін сенімділік инженерлері «қашан» болжауға қарағанда «неліктен және қалай» дегенге көбірек назар аударуы керек. Ақаудың «неге» пайда болғанын түсіну (мысалы, компоненттердің күшін шамадан тыс қолдану немесе өндіріс мәселелері салдарынан) жобалар мен процестерді жақсартуға көбірек мүмкіндік береді. Өнімнің пайдалану ортасындағы реакциясын жеделдету үшін, жоғары температураны, төмен температураны, жоғары ылғалдылықты және климаттық ортадағы температура өзгерістерін симуляциялау үшін әртүрлі экологиялық сынақ жабдықтарын пайдалану арқылы ҒЗТ, жобалау және өндірісте күтілетін сапаға жететінін тексеруге болады. Сенімділікті тексеруді сенімділікті сынау деп те атайды, ол өнімнің өмір сүру мерзімі мен күтілетін өнімділігіне негізделіп, модельдеу, статистика және басқа әдістерді пайдалану арқылы өнімнің сенімділігін бағалауды білдіреді. Нарықтағы көптеген өнімдерге сенімділікті сынау қажет, мысалы, автомобильдер, интегралды схемалар, табиғи ресурстарды өндіруге арналған ауыр машиналар, ұшақтардың автоматты бағдарламалық жасақтамасы. Сенімділікті сынау бірнеше деңгейде жүргізілуі мүмкін және сынаудың әртүрлі түрлері бар. Күрделі жүйелерді компонент, схемалық тақта, блок, құрастыру, кіші жүйе және жүйе деңгейінде сынауға болады. (Сынақ деңгейінің номенклатурасы қолданысқа қарай өзгереді.) Мысалы, төменгі деңгейдегі экологиялық стресстік сынақтарды жүргізу, яғни бөлшектерді немесе шағын құрастырмаларды сынау, жоғары деңгейдегі ақауларды тудырмас бұрын проблемаларды анықтауға көмектеседі. Сынақ интеграцияның әр деңгейінде толық жүйелік сынақ, дамыту сынағы және операциялық сынақ арқылы жүргізіледі, осылайша бағдарлама тәуекелін азайтады. Дегенмен, сынақ сенімсіздік тәуекелін азайта алмайды. Әр сынақ кезінде сынақ көлеміне, сынақ уақытына, болжамдарға және қажетті ажырату коэффициентіне байланысты I және II типтегі статистикалық қателер болуы мүмкін. Жақсы жобаны қателікпен қабылдамау (I типтегі қате) және нашар жобаны қателікпен қабылдау (II типтегі қате) тәуекелі бар. Барлық жүйелік талаптарды сынау әрқашан мүмкін емес. Кейбір жүйелерді сынау өте қымбатқа түседі, кейбір ақаулық түрлерін байқауға жылдар қажет болуы мүмкін, кейбір күрделі өзара әрекеттесулер көптеген мүмкін сынақ жағдайларын тудырады, ал кейбір сынақтар шектеулі сынақ диапазонды немесе басқа ресурстарды пайдалануды қажет етеді. Мұндай жағдайларда, (өте) жеделдетілген өмір сүруді сынау, эксперименттерді жобалау және модельдеу сияқты сынақтарға басқа тәсілдер қолданылуы мүмкін. Сенімділікті сынауда статистикалық сенімнің қажетті деңгейі де маңызды рөл атқарады. Статистикалық сенімділікті сынақ уақытын немесе сыналған элементтердің санын арттыру арқылы арттыруға болады. Сенімділікті сынау жоспарлары белгіленген сенімділік деңгейінде сынақ бірліктерінің ең аз санымен және сынақ уақытында белгіленген сенімділікті қамтамасыз ету үшін жасалады. Әр түрлі сынақ жоспарлары өндіруші мен тұтынушы үшін әртүрлі деңгейде тәуекел тудырады. Әр тарап үшін қажетті сенімділік, статистикалық сенімділік және тәуекел деңгейлері түпкілікті сынақ жоспарына әсер етеді. Тапсырыс беруші мен әзірлеуші сенімділік талаптары қалай сыналатындығы туралы алдын ала келісуі керек. Сенімділікті сынаудың маңызды аспектісі – «ақауды» анықтау. Бұл түсінікті болып көрінсе де, жүйеде ақаулық орын алды ма, жоқ па, анықтау қиын жағдайлар көптеген кездеседі. Сынақ жағдайларының өзгеруі, операторлардың айырмашылығы, ауа райы және күтпеген жағдайлар тапсырыс беруші мен жүйе әзірлеуші арасында айырмашылықтар тудыруы мүмкін. Бұл мәселені шешудің бір жолы – бағалау конференциясын өткізу. Бағалау конференциясына тапсырыс берушінің, әзірлеушінің, сынақ ұйымының, сенімділік ұйымының өкілдері және кейде тәуелсіз бақылаушылар қатысады. Конференцияның балл беру процесі жұмыстың сипаттамасында белгіленеді. Әр сынақ жағдайын топ талқылайды және «сәтті» немесе «сәтсіз» деп бағалайды. Бұл бағалау сенімділік инженері пайдаланатын ресми нәтиже болып табылады. Талаптарды анықтау кезеңінде сенімділік инженері тапсырыс берушімен сынақ стратегиясын әзірлейді. Сынақ стратегиясы сенімділік ұйымының, мүмкіндігінше көп деректерді алу қажеттігі, және шығын, кесте және қол жетімді ресурстар сияқты шектеулер арасындағы компромисті қарастырады. Әр сенімділік сынағы үшін сынақ жоспарлары мен процедуралары әзірленеді және нәтижелер құжатталады. Сенімділікті сынау фотоника саласында кең таралған. Лазерлердің сенімділігін сынау мысалдары ретінде өмір сүруді сынау және «жағу» сынағын атауға болады. Бұл сынақтар бақыланатын жағдайларда лазерлер тобының өте жеделдетілген қартаюын қамтиды. Бұл сынақтардан алынған деректер лазердің күтілетін өмір сүру мерзімін болжау үшін қолданылады.

Reliability engineers, whether using quantitative or qualitative methods to describe a failure or hazard, rely on language to pinpoint the risks and enable issues to be solved. The language used must help create an orderly description of the function/item/system and its complex surrounding as it relates to the failure of these functions/items/systems. Systems engineering is very much about finding the correct words to describe the problem (and related risks), so that they can be readily solved via engineering solutions. Jack Ring said that a systems engineer's job is to "language the project." (Ring et al. 2000) For part/system failures, reliability engineers should concentrate more on the "why and how", rather that predicting "when". Understanding "why" a failure has occurred (e. g. due to over stressed components or manufacturing issues) is far more likely to lead to improvement in the designs and processes used Through the use of various environmental test equipment to simulate the high temperature, low temperature, and high humidity, and temperature changes in the climate environment, to accelerate the reaction of the product in the use environment, to verify whether it reaches the expected quality in R&D, design, and manufacturing. Reliability verification is also called reliability testing, which refers to the use of modeling, statistics, and other methods to evaluate the reliability of the product based on the product's life span and expected performance. Most product on the market requires reliability testing, such as automotive, integrated circuit, heavy machinery used to mine nature resources, Aircraft auto software. Reliability testing may be performed at several levels and there are different types of testing. Complex systems may be tested at component, circuit board, unit, assembly, subsystem and system levels. (The test level nomenclature varies among applications.) For example, performing environmental stress screening tests at lower levels, such as piece parts or small assemblies, catches problems before they cause failures at higher levels. Testing proceeds during each level of integration through full up system testing, developmental testing, and operational testing, thereby reducing program risk. However, testing does not mitigate unreliability risk. With each test both statistical type I and type II errors could be made, depending on sample size, test time, assumptions and the needed discrimination ratio. There is risk of incorrectly rejecting a good design (type I error) and the risk of incorrectly accepting a bad design (type II error). It is not always feasible to test all system requirements. Some systems are prohibitively expensive to test; some failure modes may take years to observe; some complex interactions result in a huge number of possible test cases; and some tests require the use of limited test ranges or other resources. In such cases, different approaches to testing can be used, such as (highly) accelerated life testing, design of experiments, and simulations. The desired level of statistical confidence also plays a role in reliability testing. Statistical confidence is increased by increasing either the test time or the number of items tested. Reliability test plans are designed to achieve the specified reliability at the specified confidence level with the minimum number of test units and test time. Different test plans result in different levels of risk to the producer and consumer. The desired reliability, statistical confidence, and risk levels for each side influence the ultimate test plan. The customer and developer should agree in advance on how reliability requirements will be tested. A key aspect of reliability testing is to define "failure". Although this may seem obvious, there are many situations where it is not clear whether a failure is really the fault of the system. Variations in test conditions, operator differences, weather and unexpected situations create differences between the customer and the system developer. One strategy to address this issue is to use a scoring conference process. A scoring conference includes representatives from the customer, the developer, the test organization, the reliability organization, and sometimes independent observers. The scoring conference process is defined in the statement of work. Each test case is considered by the group and "scored" as a success or failure. This scoring is the official result used by the reliability engineer. As part of the requirements phase, the reliability engineer develops a test strategy with the customer. The test strategy makes trade offs between the needs of the reliability organization, which wants as much data as possible, and constraints such as cost, schedule and available resources. Test plans and procedures are developed for each reliability test, and results are documented. Reliability testing is common in the Photonics industry. Examples of reliability tests of lasers are life test and burn in. These tests consist of the highly accelerated aging, under controlled conditions, of a group of lasers. The data collected from these life tests are used to predict laser life expectancy under the intended operating characteristics.

Сынау әдісі

Жүйелі сенімділік сынау әдісі – біріншіден, сенімділік мақсатын анықтау, содан кейін өнімділікпен байланысты сынақтар жүргізіп, өнімнің сенімділігін бағалау болып табылады. Қазіргі заманғы өнеркәсіптердегі сенімділікті растау сынағы өнімнің жалпы сенімділік деңгейімен қалай байланысты екенін және жеке сынақтардың кепілдік құны мен тұтынушылардың қанағаттануына қандай әсер ететінін нақты анықтауы тиіс.

Бағдарламалық қамтамасыз етудің сенімділігі

Бағдарламалық қамтамасыз етудің сенімділігі – сенімділік инженериясының ерекше бір саласы. Ол бағдарламалық жасақтаманы сенімді, яғни ақауларға төзімді ету үшін қажетті негіздер мен техникаларға бағытталған. Жүйелік сенімділік, анықтама бойынша, жүйенің барлық құрамдастарын қамтиды: аппараттық бөліктер, бағдарламалық қамтамасыз ету, қолдау инфрақұрылымы (маңызды сыртқы интерфейстерді қоса), операторлар және процедуралар. Әдетте, сенімділік инженериясы жүйенің маңызды аппараттық бөліктеріне назар аударады. Бірақ цифрлық интегралды схемалар технологиясының кеңінен қолданылуымен бағдарламалық қамтамасыз ету көптеген электрондық құрылғылардың және, демек, қазіргі заманғы жүйелердің маңызды бөлігіне айналды. Сондықтан бағдарламалық қамтамасыз етудің сенімділігі жүйелік сенімділік саласында маңызды орын алды. Дегенмен, бағдарламалық және аппараттық жасақтаманың жұмыс істеу принциптерінде маңызды айырмашылықтар бар. Көптеген жағдайда аппараттық құралдың сенімсіздігіне компоненттің немесе материалдың бұзылуы себеп болады, нәтижесінде жүйе өз функциясын орындамайды. Аппараттық компонентті жөндеу немесе ауыстыру жүйені бастапқы жұмыс жағдайына келтіреді. Ал бағдарламалық қамтамасыз ету аппараттық сияқты жай ғана бұзылмайды. Керісінше, бағдарламалық қамтамасыз етудің сенімсіздігі бағдарламалық операциялардың күтпеген нәтижелерінен туындайды. Тіпті салыстырмалы түрде кішкентай бағдарламалардың да кіріс мәліметтері мен күйлердің астрономиялық түрде көп комбинациялары болуы мүмкін, оларды толыққанды тексеру мүмкін емес. Бағдарламаны бастапқы күйіне қайтару тек сол кіріс мәліметтері мен күйлердің комбинациясы қайтадан күтпеген нәтижеге әкелгенше жұмыс істейді. Бағдарламалық қамтамасыз етудің сенімділігін қамтамасыз ету үшін мұны ескеру қажет. Бағдарламалық және аппараттық жасақтамадағы ақаулардың себебіндегі осы айырмашылыққа қарамастан, бағдарламалық жасақтамамен алынған тәжірибелерді өлшеу үшін статистикалық негізде бірнеше сенімділік модельдері ұсынылған: бағдарламалық жасақтама неғұрлым ұзақ жұмыс істесе, оны сынап көрмеген жағдайда қолдану және жасырын ақаулықты көрсету ықтималдығы артады (Shooman 1987), (Musa 2005), (Denney 2005). Аппараттық жасақтамадағыдай, бағдарламалық қамтамасыз етудің сенімділігі талаптардың, жобалаудың және іске асырудың сапасына байланысты. Бағдарламалық қамтамасыз етудің сенімділігін арттыру үшін тәртіпті бағдарламалық инженерия процесіне сүйену қажет, ол күтпеген салдарларды болжауға және олардан қорғануға мүмкіндік береді. Бағдарламалық жасақтаманың сапасы мен сенімділігі арасындағы байланыс аппараттық жасақтаманың сапасы мен сенімділігіне қарағанда тығыз. Бағдарламалық жасақтаманы әзірлеу жоспары – бағдарламалық сенімділік бағдарламасының маңызды бөлігі. Жоспар бағдарламалық жасақтаманы әзірлеу кезінде қолданылатын жобалау және кодтау стандарттарын, өзара тексерулерді, бірлік тесттерін, конфигурациялық басқаруды, бағдарламалық метрикаларды және модельдерді сипаттайды. Көбінесе қолданылатын сенімділік көрсеткіші – кодтың әрбір жолына шаққандағы бағдарламалық ақаулардың саны (FLOC), әдетте мың жол кодқа шаққандағы ақаулар саны ретінде көрсетіледі. Бұл көрсеткіш, бағдарламалық жасақтаманың орындалу уақытымен бірге, бағдарламалық сенімділік модельдері мен бағалауларында маңызды рөл атқарады. Теория бойынша, ақаулардың саны (немесе ақаулық тығыздығы) төмендеген сайын бағдарламалық қамтамасыз етудің сенімділігі артады. Дегенмен, кодта ақаулардың таралу жолы, олардың ауырлығы және ақаулықты анықтау үшін қажетті кіріс комбинациясының ықтималдығы салдарынан ақаулық тығыздығы мен орташа уақыт арасындағы тікелей байланысты орнату қиын. Бірақ ақаулық тығыздығы сенімділік инженері үшін пайдалы көрсеткіш болып табылады. Күрделілік сияқты басқа бағдарламалық метрикалар да қолданылады. Бұл көрсеткіш әлі де даулы, өйткені бағдарламалық жасақтаманы әзірлеу және тексеру тәжірибесіндегі өзгерістер жалпы ақаулар деңгейіне елеулі әсер етуі мүмкін. Бағдарламалық жасақтаманы тексеру – бағдарламалық сенімділіктің маңызды аспектісі. Тіпті ең жақсы бағдарламалық жасақтаманы әзірлеу процесінде де кейбір ақаулар болады, оларды тек тексеру арқылы анықтауға болады. Бағдарламалық жасақтама бірліктерден бастап, интеграциялық және толық жүйелік тексеруге дейін бірнеше деңгейде тексеріледі. Барлық тексеру кезеңдерінде ақаулар анықталып, түзетіліп, қайта тексеріледі. Сенімділік бағалаулары ақаулық тығыздығы және басқа көрсеткіштер негізінде жаңартылады. Жүйелік деңгейде орташа уақыт арасындағы ақаулық туралы мәліметтер жиналып, сенімділікті бағау үшін қолданылады. Аппараттық жасақтамадан айырмашылығы, дәл сол бағдарламалық конфигурацияда дәл сол тестті қайтадан орындау статистикалық сенімділікті арттырмайды. Оның орнына, бағдарламалық сенімділік кодты қамту сияқты басқа көрсеткіштерді пайдаланады. Бағдарламалық инженерия институтының қабілеттілік деңгейі моделі – сенімділік және сапа мақсатында бағдарламалық жасақтаманы әзірлеу процесін бағаудың кең таралған құралы.

Software reliability is a special aspect of reliability engineering. It focuses on foundations and techniques to make software more reliable, i. e., resilient to faults. System reliability, by definition, includes all parts of the system, including hardware, software, supporting infrastructure (including critical external interfaces), operators and procedures. Traditionally, reliability engineering focuses on critical hardware parts of the system. Since the widespread use of digital integrated circuit technology, software has become an increasingly critical part of most electronics and, hence, nearly all present day systems. Therefore, software reliability has gained prominence within the field of system reliability. There are significant differences, however, in how software and hardware behave. Most hardware unreliability is the result of a component or material failure that results in the system not performing its intended function. Repairing or replacing the hardware component restores the system to its original operating state. However, software does not fail in the same sense that hardware fails. Instead, software unreliability is the result of unanticipated results of software operations. Even relatively small software programs can have astronomically large combinations of inputs and states that are infeasible to exhaustively test. Restoring software to its original state only works until the same combination of inputs and states results in the same unintended result. Software reliability engineering must take this into account. Despite this difference in the source of failure between software and hardware, several software reliability models based on statistics have been proposed to quantify what we experience with software: the longer software is run, the higher the probability that it will eventually be used in an untested manner and exhibit a latent defect that results in a failure (Shooman 1987), (Musa 2005), (Denney 2005). As with hardware, software reliability depends on good requirements, design and implementation. Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design against unintended consequences. There is more overlap between software quality engineering and software reliability engineering than between hardware quality and reliability. A good software development plan is a key aspect of the software reliability program. The software development plan describes the design and coding standards, peer reviews, unit tests, configuration management, software metrics and software models to be used during software development. A common reliability metric is the number of software faults per line of code (FLOC), usually expressed as faults per thousand lines of code. This metric, along with software execution time, is key to most software reliability models and estimates. The theory is that the software reliability increases as the number of faults (or fault density) decreases. Establishing a direct connection between fault density and mean time between failure is difficult, however, because of the way software faults are distributed in the code, their severity, and the probability of the combination of inputs necessary to encounter the fault. Nevertheless, fault density serves as a useful indicator for the reliability engineer. Other software metrics, such as complexity, are also used. This metric remains controversial, since changes in software development and verification practices can have dramatic impact on overall defect rates. Software testing is an important aspect of software reliability. Even the best software development process results in some software faults that are nearly undetectable until tested. Software is tested at several levels, starting with individual units, through integration and full up system testing. All phases of testing, software faults are discovered, corrected, and re tested. Reliability estimates are updated based on the fault density and other metrics. At a system level, mean time between failure data can be collected and used to estimate reliability. Unlike hardware, performing exactly the same test on exactly the same software configuration does not provide increased statistical confidence. Instead, software reliability uses different metrics, such as code coverage. The Software Engineering Institute's capability maturity model is a common means of assessing the overall software development process for reliability and quality purposes.

Құрылымдық сенімділік

Құрылымдық сенімділік немесе құрылымдардың сенімділігі – құрылымдардың қалып-күйіне сенімділік теориясын қолдану. Ол бетон және болат конструкцияларды қоса алғанда, әртүрлі типтегі құрылымдарды жобалау және күтіп ұстау ісінде қолданылады. Құрылымдық сенімділік зерттеулерінде жүктемелер мен кедергілер ықтималдық айнымалылар ретінде модельделеді. Осы тәсілді пайдалану арқылы құрылымның істен шығу ықтималдығы есептеледі.

Қауіпсіздік техникасымен салыстыру

Қауіпсіздік пен қолжетімділік сенімділігі көбінесе тығыз байланысты. Инженерлік жүйенің қолжетімділігін жоғалту шығындарға әкелуі мүмкін. Метро жүйесі қолжетімді болмаса, метро операторы жүйе тоқтаған әр сағат үшін ақша жоғалтады. Егер қауіпсіздік бұзылса, метро операторы одан да көп шығын көреді. Сенімділік анықтамасы ақауға тап болмау ықтималдығымен байланысты. Ақау қауіпсіздікті, қолжетімділікті немесе екеуін де жоғалтуға себеп болуы мүмкін. Маңызды жүйеде қауіпсіздікті немесе қолжетімділікті жоғалтуға жол беруге болмайды. Сенімділік инженериясы жауапты тарапқа қаржылық зиян келтіруі мүмкін ақауларды азайтуға бағытталған, ал қауіпсіздік инженериясы негізінен адам өмірін, денсаулықты зақымдауды немесе жабдыққа зиян келтіруі мүмкін нақты ақау түрлерін азайтуға қатысты. Сенімділік қауіптері компанияның немесе клиенттің кірісін жоғалтуға әкелетін жағдайларға айналуы мүмкін, мысалы, жүйе қолжетімсіздігінен өндіріс тоқтауына байланысты тікелей және жанама шығындар; қосалқы бөлшектерге күтпеген жоғары немесе төмен сұраныс; жөндеу құны; жұмыс уақыты; қайта жобалау немесе өндірістің үзілуі. Қауіпсіздік инженериясы көбінесе нақты салаларға, қолдануларға немесе аймақтарға қатысты және қатаң реттеледі. Ол негізінен ауыр апаттарға әкелуі мүмкін жүйелік қауіпсіздік қауіптеріне назар аударады, соның ішінде: адам өмірін жоғалту; жабдықтың қирауы; немесе қоршаған ортаға зиян келтіру. Сондықтан, жүйе функционалдық сенімділігіне қойылатын талаптар өте жоғары болады. Ол сенімділік инженериясы сияқты қаламаған ақаулармен айналысса да, тікелей шығындарға көңіл аз бөлінеді және ақаулықтан кейінгі жөндеу шараларына қатысы жоқ. Тағы бір айырмашылық – бұл ақаулардың қоғамға тигізетін әсерінің деңгейі, бұл үкіметтер мен реттеуші органдардың (мысалы, ядролық, ғарыш, қорғаныс, теміржол және мұнай өнеркәсібі) қатаң бақылауын тудырады. Күнделікті қолданыста "өнім сапасы" термині оның ішкі табиғатындағы жоғары деңгейді білдіреді. Өнеркәсіпте сапа "пайдалану басталғанда талаптарға немесе ерекшеліктерге сәйкестік" деп нақтырақ анықталады. Егер түпкілікті өнімнің ерекшеліктері бастапқы талаптарды және клиенттің/жүйенің қажеттіліктерін толық қамтитын болса, сапа деңгейін ерекшеліктерге сәйкес келетін өнім бірліктерінің үлесі ретінде өлшеуге болады. Өндірілген тауарлардың сапасы көбінесе кепілдік мерзімі ішіндегі кепілдік талаптарының санына бағытталған. Сапа – өмір бойының басындағы және кепілдік мерзіміндегі бағалау, ол өнімнің төменгі деңгейдегі ерекшеліктерін бақылаумен байланысты. Бұл өндіріс қателіктерінің соңғы сапа бақылауынан өткен жағдайларын қамтиды. Теориялық тұрғыдан алғанда, сапа деңгейін ақаулы өнімдердің үлесімен сипаттауға болады. Жүйелік инженерияның бір бөлігі ретінде сенімділік көп жылдар бойы ақаулық деңгейін үнемі бағалауды қамтиды. Теориялық тұрғыдан алғанда, барлық элементтер шексіз уақыт ішінде сәтсіздікке ұшырайды. Уақыт өте келе пайда болатын ақаулар сенімділік зақымдануы деп аталады. Сенімділік зақымдануын сипаттау үшін уақыт өте келе зақымдану үлесін сипаттайтын ықтималдық модель қажет. Бұл өмірді бөлу моделі деп аталады. IEEE сенімділік қоғамы, Американдық сапа қоғамы (ASQ) және сенімділік инженерлері қоғамы (SRE).

Reliability for safety and reliability for availability are often closely related. Lost availability of an engineering system can cost money. If a subway system is unavailable the subway operator will lose money for each hour the system is down. The subway operator will lose more money if safety is compromised. The definition of reliability is tied to a probability of not encountering a failure. A failure can cause loss of safety, loss of availability or both. It is undesirable to lose safety or availability in a critical system. Reliability engineering is concerned with overall minimisation of failures that could lead to financial losses for the responsible entity, whereas safety engineering focuses on minimising a specific set of failure types that in general could lead to loss of life, injury or damage to equipment. Reliability hazards could transform into incidents leading to a loss of revenue for the company or the customer, for example due to direct and indirect costs associated with: loss of production due to system unavailability; unexpected high or low demands for spares; repair costs; man hours; re designs or interruptions to normal production. Safety engineering is often highly specific, relating only to certain tightly regulated industries, applications, or areas. It primarily focuses on system safety hazards that could lead to severe accidents including: loss of life; destruction of equipment; or environmental damage. As such, the related system functional reliability requirements are often extremely high. Although it deals with unwanted failures in the same sense as reliability engineering, it, however, has less of a focus on direct costs, and is not concerned with post failure repair actions. Another difference is the level of impact of failures on society, leading to a tendency for strict control by governments or regulatory bodies (e. g. nuclear, aerospace, defense, rail and oil industries). The everyday usage term "quality of a product" is loosely taken to mean its inherent degree of excellence. In industry, a more precise definition of quality as "conformance to requirements or specifications at the start of use" is used. Assuming the final product specification adequately captures the original requirements and customer/system needs, the quality level can be measured as the fraction of product units shipped that meet specifications. Manufactured goods quality often focuses on the number of warranty claims during the warranty period. Quality is a snapshot at the start of life through the warranty period and is related to the control of lower level product specifications. This includes time zero defects i. e. where manufacturing mistakes escaped final Quality Control. In theory the quality level might be described by a single fraction of defective products. Reliability, as a part of systems engineering, acts as more of an ongoing assessment of failure rates over many years. Theoretically, all items will fail over an infinite period of time. Defects that appear over time are referred to as reliability fallout. To describe reliability fallout a probability model that describes the fraction fallout over time is needed. This is known as the life distribution model. the IEEE Reliability Society, the American Society for Quality (ASQ), and the Society of Reliability Engineers (SRE).

Француз стандарттары

FIDES FIDES әдістемесі (UTE C 80 811) ақаулар физикасына негізделген және сынақ деректерінің, өрістегі қайтымдардың және қолданыстағы модельдеудің талдауымен қолдалады. UTE C 80–810 немесе RDF2000 RDF2000 әдістемесі француз телекоммуникациясы тәжірибесіне негізделген.