परीक्षण किए गए महत्वपूर्ण जीवन-या-मृत्यु प्रणालियों में सॉफ़्टवेयर का उपयोग कैसे किया जाता है?


51

उदाहरण के लिए, एक हवाई जहाज, जिसका विरोध किया गया है, एक वेबसाइट, एक प्रणाली है जहां कुछ प्रणालियों में कोई भी विफलता पूरी तरह से अस्वीकार्य है, जैसे कि उड़ान की निगरानी में त्रुटियों के कारण ऑटोपायलट की खराबी हो सकती है और गोता लगा सकता है। जाहिर है, ऐसा नहीं होता है क्योंकि बोइंग और एयरबस के शानदार इंजीनियरों के पास ऑटोपायलट में जांच होती है ताकि यह सुनिश्चित हो सके कि यह अचानक तय नहीं होता है कि गोता एक पूरी तरह से स्वीकार्य और सुरक्षित पैंतरेबाज़ी है। या शायद कंप्यूटर क्रैश हो जाता है, और नए फ्लाई-बाय-वायर विमान में पायलट अब वास्तव में विमान को नहीं उड़ा सकते हैं। बेशक, एक दुर्घटना (सॉफ्टवेयर और विमान दोनों के) को रोकने के लिए इन प्रणालियों में निर्मित विभिन्न सुरक्षा प्रक्रियाएं और अतिरेक हैं।

हालाँकि, दूसरी ओर, यह काफी स्पष्ट है कि सॉफ़्टवेयर पूर्ण स्रोत नहीं है - दोनों खुले स्रोत और बंद स्रोत सॉफ़्टवेयर नियमित रूप से क्रैश होते हैं, और केवल सबसे सरल "हैलो वर्ल्ड" प्रोग्राम विफल नहीं होता है। एरोनॉटिक, मेडिकल और अन्य जीवन-या-मृत्यु उद्योगों में सॉफ़्टवेयर सिस्टम डिज़ाइन करने वाले इंजीनियर अपने सॉफ़्टवेयर का परीक्षण कैसे कर सकते हैं ताकि यह विफल न हो (और यदि यह विफल हो जाता है, तो कम से कम इनायत से विफल हो)?

मैं सख्त उम्मीद कर रहा हूं कि आप सभी जाने वाले नहीं हैं: "ओह, मैं बोइंग / एयरबस / (कुछ अन्य कंपनी) के लिए काम करता हूं और यह नहीं है! अपनी अगली उड़ान / अस्पताल की यात्रा पर मज़े करो।"


8
Therac25 के मामले को ध्यान में रखते हुए और पैट्रियट बैटरी जो संलग्न नहीं थी, जाहिर है कि अच्छी तरह से पर्याप्त नहीं है।
लोरेन Pechtel

@ ठीक है, मुझे इसमें कोई संदेह नहीं है कि अपवाद नहीं हैं। दूसरी ओर, मैंने कभी भी एक महत्वपूर्ण सॉफ़्टवेयर त्रुटि का अनुभव करने के लिए एयरबस ए 320 (एक फ्लाई-बाय-वायर विमान) के बारे में कभी नहीं पढ़ा है जिसके परिणामस्वरूप निकट चोट / चोट / मृत्यु हुई, और 4000 से अधिक हो गए हैं।
waiwai933

3
"हैलो वर्ल्ड" भी विफल हो सकता है। lol
xandy

1
@waiwai - वास्तव में, एक साल या उससे पहले हुआ था - एक दोषपूर्ण सेंसर ने संकेत दिया कि विमान बहुत तेजी से चढ़ रहा था और स्टाल के बारे में था। कंप्यूटर की स्तरीय उड़ान में लौटने का प्रयास वास्तव में एक गोता था। कोई दुर्घटना नहीं हुई, लेकिन यात्रियों और ढीली वस्तुओं को केबिन के चारों ओर फेंके जाने से चोटें / क्षति हुई।
टॉम क्लार्कसन

6
क्या वे पायलट लाइसेंस के साथ मृत्यु-पंक्ति कैदियों का उपयोग नहीं करते हैं?
जेएफओ

जवाबों:


29

मैंने औद्योगिक नियंत्रण में बहुत काम किया है। यह एयरोस्पेस जैसे शानदार उद्योग में होना जरूरी नहीं है। लगभग हर औद्योगिक मशीन में गंभीर चोट या मृत्यु होने की पर्याप्त क्षमता होती है। जब लोग घायल हुए थे तब मैं आसपास था। यदि आप अपना अधिकांश समय किसी कार्यालय में डेस्क पर बिताते हैं, तो आप शायद इस बात से आश्चर्यचकित होंगे कि अधिकांश फैक्ट्री की नौकरियां कितनी खतरनाक हो सकती हैं (और निश्चित रूप से हाल ही में थीं)। अब हमारे पास मशीन की सुरक्षा के बेहतर तरीके हैं। यहां बताया गया है कि यह व्यवहार में कैसे काम करता है (हालांकि यह अधिकार क्षेत्र से क्षेत्राधिकार में भिन्न होता है):

यूएस में OSHA मानक हैं, और यूरोपीय संघ में समान (आमतौर पर अधिक सख्त) दिशानिर्देश हैं। ये आम तौर पर जोखिम के विश्लेषण के लिए आपको आवश्यकता होती है। इसका मतलब है कि आप सभी खतरों की एक सूची बनाते हैं और फिर उन खतरों को वर्गीकृत करते हैं, चीजों को ध्यान में रखते हैं जैसे कि किसी व्यक्ति को कितनी बार जोखिम से अवगत कराया जाएगा, जोखिम से बचना कितना आसान है (गति, आदि पर निर्भर करता है), और क्या परिणाम की गंभीरता (कट, विच्छेदन, मृत्यु, आदि) है।

बहुत सारे विश्लेषणों का रखवाली खतरों से करना है। यदि आप अपनी मशीन के चारों ओर एक बड़ा पिंजरा लगाते हैं और इसे कसकर बोल्ट करते हैं, तो मशीन के घटकों को रखवाली नहीं कर सकते हैं, तो आपकी मशीन सुरक्षित मानी जाती है। यदि आपको एक उपकरण की आवश्यकता होती है, तो उसे एक रखरखाव कार्य माना जाता है, और रखरखाव करने वाले लोगों को प्रशिक्षित किया जाता है कि कैसे मशीन पर सुरक्षित रूप से काम करना है। वास्तविकता में, हालांकि, अधिकांश मशीनों को ऑपरेटरों के साथ नियमित रूप से बातचीत करने की आवश्यकता होती है, इसलिए हमें गार्डिंग या हल्के पर्दे आदि में एक्सेस दरवाजे लगाने होंगे, उन दरवाजों और हल्के पर्दे पर नजर रखने की जरूरत है और ऑपरेटर को खुद को उजागर करने की खतरों की शक्ति एक "नियंत्रण विश्वसनीय" तरीके से बंद किया जाना है।

उस विश्लेषण के आधार पर, जोखिम को विभिन्न श्रेणियों में रखा जाता है। एक सामान्य वर्गीकरण स्केल श्रेणी 1 से श्रेणी 4 (एन 954-1 मानक के आधार पर) है। उन श्रेणियों के आधार पर, आपको मशीन स्तर की सुरक्षा और सुरक्षा का एक निश्चित स्तर प्रदान करना आवश्यक है।

उदाहरण के लिए, श्रेणी 4 की आवश्यकता है कि:

इन भागों में से प्रत्येक में एक भी गलती सुरक्षा समारोह के नुकसान का कारण नहीं है।

एकल दोष का पता सुरक्षा फ़ंक्शन के अगले अनुरोध के साथ या उससे पहले लगाया जाता है, या यदि यह संभव नहीं है, तो दोषों का एक संचय सुरक्षा फ़ंक्शन के नुकसान का कारण नहीं हो सकता है।

व्यवहार में इसे प्राप्त करना मुश्किल हो सकता है, लेकिन मानक घटकों की उपलब्धता से सरल हो जाता है जो कि श्रेणी 4 से प्रमाणित हैं। उदाहरण के लिए, इन प्रणालियों में एक सामान्य घटक एक सुरक्षा रिले है। ये केवल यांत्रिक रिले से अधिक हैं:

  • वे दोहरी निरर्थक इनपुट चैनलों की निगरानी करने के लिए डिज़ाइन किए गए हैं, इसलिए यदि आपके पास एक सेंसर है जो एक गलती की स्थिति का पता लगाता है (जैसे कि एक गार्ड दरवाजा खुला), तो इसमें आमतौर पर निरर्थक सर्किट के साथ दो संपर्क होते हैं। रिले दोनों चैनलों पर नज़र रखता है, और यदि कोई भी खुलता है, तो यह आपके एक्ट्यूएटर्स को बिजली छोड़ देता है, लेकिन अगर वे दोनों एक ही समय में बाहर नहीं निकलते हैं, तो यह एक गलती की स्थिति में प्रवेश करता है और मशीन की मरम्मत होने तक फिर से शुरू नहीं किया जा सकता है ।
  • रिले उन पंक्तियों पर विद्युत दालों का भी उपयोग करता है और उन संकेतों का उपयोग पार या शॉर्ट तारों के लिए निगरानी करने के लिए करता है, इसलिए यह तारों की गलती का पता लगा सकता है।
  • आउटपुट पक्ष पर, यह आउटपुट कॉइल को चलाने के लिए दोहरे सर्किट के एक सेट का उपयोग करता है, इसलिए यदि एक "पर" स्थिति में दोष है, तो दूसरे को आउटपुट को सक्रिय होने से रोकना चाहिए। इसके अतिरिक्त इनकी निगरानी की जाती है और यदि कोई खराबी पाई जाती है, तो यह ऑपरेशन को रोकता है। कॉइल स्वयं वास्तव में दोहरी शक्ति निर्देशित रिले हैं जिसका अर्थ आउटपुट पर अनावश्यक भौतिक रिले हैं, साथ ही गारंटी देता है कि प्रत्येक एकल रिले पर संपर्क शारीरिक रूप से एक साथ जुड़े हुए हैं, ताकि 4 में से एक संपर्क, खुद से चिपक न सके। इन पर भी नजर रखी जाती है।
  • इसमें आपके द्वारा नियंत्रित लोड को बंद करने के लिए एक सहायक सामान्य रूप से बंद संपर्क की निगरानी के लिए एक इनपुट भी शामिल है। यदि यह आउटपुट को बंद कर देता है, तो इसे सामान्य रूप से बंद संपर्क को देखने के लिए संलग्न करना होता है, जिसका अर्थ है कि यह मोटर संपर्ककर्ता को बंद कर देता है, या जो कुछ भी था, उसे फिर से चालू स्थिति में संचालित करने की अनुमति है।

जैसा कि आप बता सकते हैं, ये जटिल उपकरण हैं। प्रत्येक सुरक्षा रिले के लिए विशिष्ट लागत $ 200 से $ 600 रेंज में हैं। जाहिर है इन उपकरणों में सॉफ्टवेयर है। अपनी सुरक्षा रिले को प्रमाणित करने के लिए, आपको आमतौर पर इस तरह से एक डिजाइन का पालन करना होगा:

  • दो निरर्थक प्रोसेसर, आमतौर पर अलग-अलग डिजाइनों के आधार पर विभिन्न विक्रेताओं से लिए जाते हैं।
  • प्रत्येक प्रोसेसर पर चलने वाले कोड को अलग-अलग परिस्थितियों में काम करने वाली दो टीमों द्वारा विकसित किया जाना है। यह एकल सॉफ़्टवेयर बग को विफलता का एकल बिंदु होने से रोकता है।
  • दोनों प्रोसेसर के आउटपुट को सहमत होना पड़ता है या फिर सुरक्षा रिले दोष।

एक बार जब आप अपनी मशीन के लिए अपनी सुरक्षा प्रणाली को डिजाइन करते हैं, तो सुरक्षा रेटेड घटकों का उपयोग करके, फिर आपको एक पेशेवर इंजीनियर द्वारा डिजाइन की समीक्षा और मुहर लगानी होगी। फिर आप मशीन का निर्माण करें। फिर पी। एंग। यह सुनिश्चित करने के लिए मशीन के निर्माण की समीक्षा करेगा कि यह डिजाइन के लिए बनाया गया था। वे इसे प्रलेखित करेंगे, और यह सुनिश्चित करने के लिए इस पर कुछ परीक्षण करेंगे कि यह अपेक्षित है। इसे प्री-स्टार्ट रिव्यू (PSR) कहा जाता है और हर क्षेत्राधिकार में नहीं किया जाता है। PSR पास होने के बाद, आपको एक ऑपरेटर को मशीन चलाने की अनुमति होगी।

हाल के वर्षों में सुरक्षा प्रणालियों में कुछ क्रांतियां हुई हैं। कुछ समय के लिए किसी ने नेटवर्क पर सुरक्षा डेटा संचारित करने पर भरोसा नहीं किया, इसलिए आमतौर पर डिवाइसनेट और ईथरैट जैसे "वितरित I / O सिस्टम" को सिस्टम के सुरक्षा भाग में अनुमति नहीं दी गई। हालाँकि, हाल के प्रोटोकॉल अब सुरक्षा उपकरणों को इन औद्योगिक नेटवर्क पर चलाने की अनुमति देते हैं। प्रोटोकॉल टाइम-स्टैम्पेड संदेशों का उपयोग करते हैं, और कनेक्शन के दोनों सिरों पर दोहरी निरर्थक प्रसंस्करण करते हैं।

सुरक्षा रिले धीरे-धीरे डोडो पक्षी के रास्ते जा रहे हैं, जो कि अधिक जटिल सेफ्टी पीएलसी द्वारा प्रतिस्थापित किया गया है, जो एक फ़ंक्शन ब्लॉक आरेख भाषा में सुरक्षा तर्क बनाने का एक तरीका है। फिर से, ये सेफ्टी पीएलसी सब कुछ बेमानी है। जब प्रोग्राम को मंजूरी दे दी जाती है, तो मशीन को सेवा में डालने से पहले, पी। एंग। कार्यक्रम पर मुहर लगाएगा और प्रोग्राम / पीएलसी एक पासवर्ड के साथ लॉक हो जाएगा। यह प्रोग्राम का एक हैश भी लेता है और वह हैश डॉक्यूमेंटेशन में रिकॉर्ड किया जाता है (जो कि P.Eng है। वास्तव में स्टैम्पिंग है)।

अब एक बार जब आप अपनी सुरक्षा प्रणाली तैयार कर लेते हैं, तो मशीन को नियंत्रित करने के लिए आप जो तर्क लिखते हैं, वह बहुत ही सीट-पर-आपकी पैंट हो सकता है। प्रोग्रामर अक्सर दुर्घटनाग्रस्त मशीनों के कारण हजारों डॉलर का नुकसान करते हैं, लेकिन कम से कम किसी के घायल होने की बात नहीं है।


20

यादृच्छिक कार्यात्मक परीक्षण के बजाय औपचारिक सत्यापन की दिशा में एक गंभीर कदम है।

सरकारी एजेंसियां ​​जैसे नासा और कुछ रक्षा संगठन इन तकनीकों पर अधिक से अधिक खर्च कर रहे हैं।

वे अभी भी औसत प्रोग्रामर के लिए एक पीआईटीए हैं, लेकिन वे अक्सर महत्वपूर्ण प्रणालियों के परीक्षण में अधिक प्रभावी होते हैं।

मल्टीथ्रेड कोड को मान्य करने जैसी चीजों के लिए शिक्षाविदों से अधिक तकनीकों को आज़माने की प्रवृत्ति भी है।


6
नासा मिशन नियंत्रण के लिए लिखित ग्राउंड सपोर्ट सॉफ़्टवेयर होने और पुराने और नए उड़ान कोड के स्निपेट्स को देखने के बाद ऐसा कोई ज़ोर नहीं है। ठीक है, सरासर मात्रा में वृद्धि के कारण, शायद नासा क्यूसी पर पहले से कहीं अधिक खर्च कर रहा है, लेकिन प्रत्येक आवेदन पर ध्यान केंद्रित किया गया था जब अंतरिक्ष कार्यक्रम युवा था तब की तुलना में बहुत कम है। सुरक्षा महत्वपूर्ण चीजों पर अभी भी कुछ ध्यान दिया गया है, लेकिन मिशन क्रिटिकल को कम से कम व्यापक परीक्षण सूट की आवश्यकता है, और यहां तक ​​कि सुरक्षा महत्वपूर्ण सत्यापन समय के साथ गिरावट आई है।
बेन Voigt

7
कृपया ध्यान दें कि मैं इस बात से असहमत नहीं हूं कि औपचारिक सत्यापन बहुत प्रभावी हो सकता है और उच्चतम स्तर की विश्वसनीयता का उत्पादन करने के लिए आवश्यक है। यह सिर्फ इतना है कि प्रबंधकों ने सीखा है कि यह कितना खर्च करता है और, अधिक से अधिक जटिल सॉफ्टवेयर के साथ सामना किया, कारण यह है कि वे प्रति आवश्यकता और कोड की प्रति पंक्ति अब और खर्च नहीं कर सकते। सही दृष्टिकोण प्रणाली को विभाजित करना और महत्वपूर्ण भागों को छोटा रखना होगा, लेकिन मैंने इसे प्रभावी ढंग से नहीं देखा, जिसके परिणामस्वरूप प्रबंधन ने पूरी औपचारिक सत्यापन प्रक्रिया को निषेधात्मक रूप से महंगा घोषित किया।
बेन Voigt

2
@ बीन वायट: अगर मैं एक अंतरिक्ष यात्री होता, तो मैं आपकी रिपोर्ट से बहुत चिंतित होता।
परिक्रमा

1
@Orbling: अंतरिक्ष यात्रियों को शायद समस्या के आसपास कुछ वजन फेंकना चाहिए, लेकिन वे शुरू करने के लिए अत्यधिक जोखिम लेने वालों का एक समूह हैं। वहाँ एक बिंदु है जिस पर आपने उन जोखिमों को कम किया है जिन्हें आप परिमाण के एक आदेश से नियंत्रित कर सकते हैं जो आप नहीं कर सकते हैं, और यह पैसा खर्च करने के लिए बहुत प्रभावी नहीं है, और यह बहस का विषय है कि क्या मैंने उपयोग किए गए तरीकों को देखा है बिंदु। कुछ उच्च पदस्थ प्रबंधकों ने निश्चित रूप से विश्वास किया कि उन्होंने किया था।
बेन वोइगट

1
और यह सोचकर दुख होता है कि बहुत से लोगों ने दीजकस्ट्रा की बात नहीं सुनी जो 1960 के दशक से औपचारिक सत्यापन के बारे में चल रहे थे। जैसा कि नीत्शे ने कहा, "कुछ पुरुष मरणोपरांत पैदा होते हैं।"
veryfoolish

12

यह इस बात पर निर्भर करता है कि सॉफ्टवेयर क्या है। उदाहरण के लिए, विमानों में आमतौर पर महत्वपूर्ण प्रणालियों के लिए दोहरे-अनावश्यक प्रसंस्करण होते हैं; चरम मामले में उपयोग किए जाने वाले 2 अलग-अलग हार्डवेयर डिज़ाइन हो सकते हैं, और एस / डब्ल्यू के दो स्वतंत्र रूप से विकसित टुकड़े, प्रत्येक पर चलाने के लिए एक। वे दोनों एक दूसरे की गणना और जांच करते हैं। यह मूर्ख नहीं है और बहुत महंगा है।

जब विमान प्रणालियों के परीक्षण जैसी चीजों की बात आती है, तो परीक्षणों की एक श्रृंखला होती है - उड़ान से संबंधित प्रणालियों के परीक्षण में महीनों लगते हैं, और यदि आप पुन: परीक्षण की पूरी श्रृंखला में कोई बदलाव करते हैं, तो उन्हें चलाने की आवश्यकता होती है। यह आमतौर पर एक सिम्युलेटर में किया जाता है, जो वास्तव में एक नकली इंजन या इसी तरह के कहने के साथ वास्तविक विमान भागों (जैसे कॉकपिट) से भरा हो सकता है। जैसा कि आप कल्पना कर सकते हैं, यह भी छिपाने के लिए महंगा है। परिवर्तनों का मूल्यांकन एक औपचारिक परीक्षण कार्यक्रम के खिलाफ किया जाता है, और फिर परीक्षण उड़ानों में एक वास्तविक विमान में चलाया जाता है। जिस तरह से "परेशान कार्यात्मक" परीक्षण चलाए जाते हैं, यह वह जगह है जहां बदली हुई वस्तु को अपना सामान्य सामान करने की अनुमति दी जाती है और यह देखने के लिए सब कुछ जांचा / परखा जाता है कि कोई हानिकारक प्रभाव तो नहीं था। इसमें भी बहुत पैसा खर्च होता है और इसमें कई हफ्ते लग सकते हैं।

मैं एक उदाहरण से जानता हूं कि उड़ान प्रणाली में एक बहुत ही सरल परिवर्तन की आवश्यकता थी - इतना सरल कि आप कितने छोटे से दंग रह जाएंगे। हालाँकि इस का पुन: परीक्षण> 3 महीने का होगा और $ 1M की तरह कुछ खर्च होगा।

जब आप मेडिकल में आते हैं, तो न केवल परीक्षण बल्कि विकास प्रक्रियाओं और प्रलेखन से संबंधित कूदने के लिए नियामक बाधाओं की एक पूरी श्रृंखला है।

ये सभी क्षेत्र उन स्थानों से एक बड़ा कदम हैं जो एक वेब साइट के लिए PHP कोड का एक छोटा सा हिस्सा है। यह धीमा, श्रमसाध्य, कठिन, उबाऊ, थकाऊ, सावधानीपूर्वक और बहुत महंगा है। अपना सामान्य विकास / परीक्षण लागत लें और लगभग 100 गुणा करें और आप निशान के करीब पहुंच रहे हैं।


"2 अलग-अलग हार्डवेयर डिज़ाइन का उपयोग किया गया, और एस / डब्ल्यू के दो स्वतंत्र रूप से विकसित टुकड़े, प्रत्येक पर चलने के लिए" का एक उदाहरण दिलचस्प होगा। असहमत नहीं, सिर्फ जिज्ञासु।
ब्रायन कार्लटन

1
@ ब्रायन: 2 अलग-अलग HW, 2 स्वतंत्र रूप से विकसित SW के लिए एक परिचित उदाहरण एंटी-लॉकिंग ब्रेक सिस्टम कंट्रोलर में उदाहरण के लिए पाया जा सकता है। उदाहरण के लिए देखें infineon.com/cms/jp/product/applications/automotive/safety/… जो एक ही IC पर दो अलग-अलग CPU आर्किटेक्चर (8-बिट और 16-बिट) का उपयोग करता है।
शेडलर

4
तीन और भी बेहतर है। दो के साथ, आप केवल यह जानते हैं कि उनमें से एक गलत है। तीन के साथ, आप एक वोट ले सकते हैं। AFAIK, Airbus A380 में दो निर्माताओं के तीन उड़ान कंप्यूटर हैं।
Jörg W Mittag

वर्षों पहले मैं कुछ सैन्य हेड-अप प्रदर्शित करता था जो इस तरह से डिजाइन किए गए थे। मेरा अनुमान है कि लागत के कारण इनमें से कई तकनीकों का उतना उपयोग नहीं किया जाता है जितना कि एक बार किया गया था।
जल्‍दी से जल्‍दी से जल्‍दी


3

चूँकि आपको पहले ही पर्याप्त और जानकारीपूर्ण उत्तर मिल गए हैं, यहाँ मेरा लेना है।

यह सरल है - पहला परीक्षण हमेशा प्रोग्रामर पर ही किया जाता है। यह बग काउंट को कम रखने के लिए जाता है, और यह सुनिश्चित करता है कि पेरोल पर केवल गुणवत्ता वाले प्रोग्रामर रखे जाएं।


3

जीवन-महत्वपूर्ण सॉफ़्टवेयर को "यह काम करने लगता है" के अलावा किसी भी मानक पर परीक्षण नहीं किया जाता है , क्योंकि यह सभी जगह किया जाता है।

गैर-प्रोग्रामर को बेहतर सॉफ़्टवेयर का उत्पादन करने की अनुमति देने के लिए सभी निवेश या तो परियोजनाओं के लिए या उससे पहले काम करने के लिए लग रहे थे

पीएस पहले पर कोई टिप्पणी नहीं है -1, लेकिन मुझे -1मेरे बयान को गिनने वाले प्रत्येक संदर्भ के लिए खुशी होगी ।

क्या मैं प्रत्येक संदर्भ के लिए +1 ले सकता हूं जो मुझे लगता है कि महत्वपूर्ण सॉफ़्टवेयर को अच्छी तरह से डिज़ाइन या परीक्षण नहीं किया गया है? WIRED के एक लेख में सिमसन गार्फ़िंकेल ने दस मामलों का दस्तावेज़ दिया


यह, दुर्भाग्य से, बहुत सटीक है।
बेन वोइगट

यकीन है, मैं तुम्हें उस पर ले गया कि -1 के लिए प्रस्ताव।
ब्रायन कार्लटन

@ ब्रायन कार्लटन आपने एक संदर्भ प्रदान नहीं किया ...
अपाला

DO-178 के बारे में, GPS के लिए MOPS ... कम से कम मैं काम कर रहा था परीक्षण में एक साल लग सकता है। ध्यान दें कि परीक्षण यह सुनिश्चित नहीं करता है कि कोड बग-मुक्त है और हर संभव मामले में विनिर्देश के अनुरूप है।
जिनीवी

2

सभी मामलों के लिए एक जवाब नहीं है। यह व्यक्तिगत निर्माता पर निर्भर है कि वे अपने सॉफ़्टवेयर का डिज़ाइन और परीक्षण कैसे करें। लेकिन संपूर्ण सॉफ्टवेयर विकास प्रक्रिया को औपचारिक विनिर्देशों का पालन करना चाहिए।

उदाहरण के लिए, चिकित्सा उपकरणों के लिए सॉफ्टवेयर बनाते समय आपको चिकित्सा उपकरणों के लिए सॉफ्टवेयर के लिए आईईसी 62304 मानक का पालन करना चाहिए । (दुर्भाग्य से मैं केवल विकिपीडिया से लिंक कर सकता हूं क्योंकि यह मुफ़्त नहीं है)। दुनिया के प्रत्येक देश को बहुत अधिक आवश्यकता है कि इस मानक का पालन किया गया है।

ये आवश्यकताएं कितनी कठोर हैं, यह नुकसान के जोखिम पर निर्भर करता है। उदाहरण के लिए, लाइफ सपोर्ट डिवाइस में नुकसान का सबसे बड़ा जोखिम होता है (निश्चित रूप से यह सिस्टम विफल हो जाता है), जबकि रोग निदान के साथ काम करने वाले सिस्टम में कम जोखिम होता है (यदि सिस्टम विफल हो जाता है तो एए टर्मिनल रोग का सही निदान नहीं किया गया था)।

लेकिन यह मूल रूप से क्या कहता है कि सॉफ्टवेयर के लिए आवश्यकताओं से एक पारगम्यता होनी चाहिए। आपको सॉफ्टवेयर यूनिट सत्यापन करना होगा। यह निर्दिष्ट नहीं करता है कि सत्यापन क्या है। इकाई परीक्षण हो सकते हैं, कोड समीक्षा हो सकती है। उच्च जोखिम वाले उपकरणों के लिए आपको सॉफ़्टवेयर इकाइयों (जहां तक ​​मैं समझता हूं और याद रखता हूं) के बीच इंटरफेस की मैन्युअल रूप से समीक्षा करनी चाहिए। और निश्चित रूप से अन्य नियमों के बहुत सारे। ओह, और आपको अपने काम का दस्तावेजीकरण करने के लिए बहुत सारे दस्तावेज लिखने होंगे।

मानक फुर्तीली विकास को प्रतिबंधित नहीं करता है, हालांकि इसे पढ़ते समय ऐसा लगता है जैसे यह मन में झरना विकास के साथ लिखा गया था।

मैं सॉफ्टवेयर विकास के अन्य क्षेत्रों जैसे विमानन, ट्रेन, कार आदि के बारे में नहीं जानता, लेकिन मैं मानता हूं कि अन्य समान औपचारिक दिशानिर्देश मौजूद हैं।


1

कई तकनीकों का उपयोग किया जाता है, जिनमें शामिल हैं:

  • औपचारिक डिजाइन और / या सत्यापन
  • स्मृति के गतिशील आवंटन जैसे फैंसी प्रोग्रामिंग से बचने के लिए सख्त कोडिंग मानक
  • बहुत मांग गुणवत्ता इंजीनियरों
  • कोड समीक्षा, गलती के पेड़, FMECA, जैसे कई स्थैतिक विश्लेषण तकनीक ...

लेकिन नंबर एक तकनीक है:

  • परिक्षण

अंतरिक्ष यान के सॉफ्टवेयर को पहले स्थान पर डिजाइन और कोड की तुलना में परीक्षण करने के लिए अधिक प्रयास की आवश्यकता होती है।

विमान कई वर्षों के उड़ान परीक्षणों से गुजरता है जहां विमान को चरम स्थितियों में लाया जाता है। यह न केवल भौतिक संरचना बल्कि सॉफ्टवेयर का भी परीक्षण करता है।


1

EETimes 3/1/2009 12:00 पूर्वाह्न ईएसटी पर जैक गन्सल द्वारा "परफेक्ट सॉफ्टवेयर" एक लेख है। वहां से कुछ बिंदु:

  • "सैद्धांतिक रूप से, सॉफ़्टवेयर एकमात्र घटक है जो परिपूर्ण हो सकता है, और यह हमेशा हमारा प्रारंभिक बिंदु होना चाहिए।" - ऐसा जेसी पूवर ने कहा है। अपने वेब पेज के बाद आपको पता चलेगा कि सामान्य सॉफ़्टवेयर की तुलना में कोई भी अधिक कीमत पर कैसे सही सॉफ्टवेयर बनाया जा सकता है।
  • अत्यधिक विश्वसनीय OS के औद्योगिक प्रदाता हैं। लेख में मिरिकम और ग्रीन हिल्स का उल्लेख किया गया है। माइक्रीम के वेब पेज के बाद, प्रमाणपत्रों के लिए मानकों की सूची है। उन प्रक्रियाओं और नियमों का पालन करना चाहिए जो उद्योग का पालन करते हैं। यह औपचारिक मान्यता पर आधारित है, लेकिन सिद्धांत से बहुत दूर है।

दिलचस्प बात यह है कि वाणिज्यिक सॉफ्टवेयर के बारे में, कैपर्स जोन्स द्वारा एकत्र किए गए आंकड़ों से पता चलता है कि "सामान्य रूप से सॉफ्टवेयर में 87% का दोष हटाने की दक्षता (शिपिंग से पहले निकाले गए कीड़े का प्रतिशत) है। फर्मवेयर का स्कोर 94% बेहतर है।" मेरे लिए, इनमें से कोई भी सही नहीं है। पहले उल्लेख किए गए लेख में उल्लेख किया गया है कि नासा की अंतरिक्ष शटल टीम ने 99% बग हटाने की दर हासिल की है, लेकिन कोड की 400k लाइनों के लिए लागत प्रति वर्ष 35 मिलियन है।

11/1-2009 को एक ही लेखक द्वारा एक अधिक दिलचस्प लेख "भरोसेमंद प्रणालियों के लिए सॉफ़्टवेयर" अधिक प्रासंगिक प्रतीत होता है। इसे इस तरह संक्षेप में प्रस्तुत किया जा सकता है:

  • विकास प्रक्रिया के रूप में, उद्योग ने DO-178B या IEC61508 का अनुसरण किया है। यह सबसे बड़ी कवरेज के साथ परीक्षण पर जोर देता है। लेकिन इस की प्रभावशीलता के बारे में बहुत कम प्रमाण मिल सकते हैं।
  • एक प्रमाणन प्राधिकरण, सर्टिफिकेट ऑन सर्टिफिकेशन डिपेंडेबल सॉफ्टवेयर सिस्टम, ने "सॉफ्टवेयर फॉर डिपेंडेबल सिस्टम - पर्याप्त साक्ष्य" नामक एक पुस्तक प्रकाशित की है। यह एक अच्छा संदर्भ है।
  • पुस्तक, मूल रूप से तीन चीजों के लिए पूछती है: [1] निर्भरता परीक्षणों के लिए स्पष्ट नियम बनाएं। [२] नियमों के खिलाफ परीक्षण, लेकिन यह भी सुनिश्चित करें कि परीक्षण सामान्य ग्राहकों या नियामकों द्वारा समझे जाने योग्य हैं, डेवलपर्स द्वारा खर्च किए गए समय से कम परिमाण के साथ। [३] सुनिश्चित करें कि यह सॉफ्टवेयर इंजीनियरिंग के विशेषज्ञ हैं और समस्या डोमेन विकास और परीक्षण कर रहे हैं।
  • सॉफ़्टवेयर का आपूर्तिकर्ता किसी भी सॉफ़्टवेयर विफलता के लिए वारंटी या अन्य उपायों के लिए प्रतिबद्ध होना चाहिए।
  • सुरक्षित भाषा का उपयोग करें, विशेष रूप से सी। स्पार्क का सुझाव नहीं दिया गया है।
  • अनुबंध दृष्टिकोण के लिए डिजाइन स्पार्क की ताकत में से एक है। डिजाइन-फॉर-कॉन्ट्रैक्ट प्रत्येक फ़ंक्शन / मेथड कॉल में परीक्षणों को एम्बेड करने के लिए एक महत्वपूर्ण तकनीक है, और इसे हमेशा रनटाइम पर निष्पादित करें। पुराने दिनों में एक साधारण मुखर () से अधिक, अनुबंध संरचनात्मक इरादे के खिलाफ परीक्षण भी कर सकता है और यह सुनिश्चित कर सकता है कि रखरखाव के चक्र में बाद के समय में कोई उल्लंघन नहीं हो सकता है जब मूल डेवलपर्स ज्यादातर अन्य परियोजनाओं पर चले गए हैं। ऐसे सबूत हैं कि अनुबंध के लिए डिजाइन ने बहुत विश्वसनीय सॉफ्टवेयर उत्पाद तैयार किए हैं। प्रमाणीकरण प्रक्रिया को सरल बनाने के लिए SPARK और इसके औजारों का उपयोग प्रमाणन परीक्षण मामलों को उत्पन्न करने में सहायता के लिए किया जा सकता है।

मेरी स्मृति के अनुसार एचपी ने लगभग एक दशक पहले डिजाइन-फॉर-कॉन्ट्रैक्ट का अभ्यास किया था। एक छोटी सी टीम के साथ, कोड की 500k लाइनों, केवल 2 बगों की डिलीवरी के बाद रिपोर्ट की गई। बहुत प्रभावशाली।

मेरे विचार में, भरोसेमंद या सही सॉफ्टवेयर केवल तभी प्राप्त किया जा सकता है जब लागत निषेधात्मक रूप से अधिक न हो। फ्रेमवर्क या ऑटोमेशन एक होना चाहिए।


0

उनके पास आमतौर पर एक हार्डवेयर इंटरलॉक होता है जो एक असफल-सुरक्षित के रूप में उपयोग किया जाता है।

हत्यारे रोबोट के लिए मानक मानक बुराई टेक्स्ट बॉक्स डिजाइन हमेशा एक किल-स्विच के साथ आते हैं: पी


0

प्रत्येक उद्योग में नियामक एजेंसियों का अपना सेट होता है जिनकी सुरक्षा संबंधी हार्डवेयर और सॉफ्टवेयर के लिए परीक्षण और प्रलेखन आवश्यकताएं होती हैं। अंडरराइटर्स लेबोरेटरी (UL) के इस PDF पर विचार करें जो UL 1998 मानक का परिचय देता है: http://www.ul.com/global/documents/offerings/indenders/hightech/software/UL_softwareconformityassessment.pdf

उस दस्तावेज़ में उल, सीएसए और आईईसी से कई अन्य संबंधित लोगों के संदर्भ हैं।

आमतौर पर, सुरक्षा संबंधी सॉफ़्टवेयर में अनावश्यक हार्डवेयर सर्किट होंगे या सुरक्षित संचालन और सुरक्षित विफलता मोड सुनिश्चित करने के लिए अन्य अनावश्यक नियंत्रण सुविधाएँ होनी चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.