एम्बेडेड C कोड विश्वसनीयता को बेहतर बनाने के लिए कौन से टूल या मानकों का उपयोग किया जा सकता है?

9

मैं आमतौर पर सी में पीआईसी प्रोग्राम करता हूं, आमतौर पर स्विच्ड-मोड कन्वर्टर्स के लिए। मैंने MISRA C जैसे विभिन्न स्थैतिक विश्लेषण उपकरणों और मानकों के बारे में सुना है जिनका उपयोग कोड की विश्वसनीयता को बेहतर बनाने में मदद करने के लिए किया जा सकता है। मैं और जानना चाहूंगा। मेरे संदर्भ के लिए कौन से मानक या उपकरण उपयुक्त हो सकते हैं?

— स्टीफन कोलिंग्स
स्रोत

1

आप C भाषा पर कैसे सेट हैं?

— ब्रायन ड्रममंड

1

अगर मुझे इसके लिए बहुत अच्छा मामला बनाना था तो मुझे किसी और चीज़ पर स्विच करने के लिए राजी किया जा सकता है। लेकिन यह एक बहुत अच्छा मामला होगा।

— स्टीफन कॉलिंग्स

सी से स्विच करने के लिए "एक बहुत अच्छा मामला" जल्दी से नहीं बनाया जा सकता है, और पीआईसी के लिए, संभवत: अभी तक नहीं। AVR, ARM या MSP430 के लिए, Ada एक गंभीर नज़र के लायक होगा (नकारात्मकता आकर्षित होने के बावजूद, जैसा कि आप देख सकते हैं!) और उच्च संबंध के लिए, SPARK एक नज़र के लायक है।

— ब्रायन ड्रमंड

आपको ये रोचक जानकारी पृष्ठभूमि जानकारी के रूप में मिल सकती है: SPARK बनाम MISRA-C spark-2014.org/entries/detail/… और इस पर चल रहे केस स्टडी: spark-2014.org/uploads/Nosegearpaper_1.pdf

— ब्रायन ड्रमंड 2

बेहतर समय हो सकता है कि PIC से दूर कुछ आधुनिक करने के लिए मामला बनाने के लिए निवेश किया जाए ... खासकर यदि आप उस तरह के मिशन-महत्वपूर्ण सिस्टम को डिजाइन कर रहे हैं जो मूल रूप से MISRA और SPARK के लिए थे।

— लुंडिन

11

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

यहाँ मेरे कुछ दिशानिर्देश हैं:

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

— एडम लॉरेंस
स्रोत

+1 सभी ध्वनि सलाह। मैं किसी भी पेशेवर फर्मवेयर डेवलपर से अपेक्षा करूंगा कि इसे पढ़ते समय सिर्फ मुस्कुराएं और सिर हिलाएं।

— लुंडिन

2

सहकर्मी समीक्षाओं का एक महत्वपूर्ण पहलू यह है कि समीक्षा कोड के बारे में है, न कि प्रोग्रामर के बारे में। यदि आप "पहले मैं ऐसा करता हूं, तो मैं वह करता हूं" जैसे शब्दों के साथ अपने कोड का विश्लेषण करता है, तो आप शायद मुश्किल में हैं। "पहले कोड ऐसा करता है, फिर वह ऐसा करता है" इसके बारे में सोचने का सही तरीका है। और समीक्षकों पर भी यही बात लागू होती है: "आपने ऐसा क्यों किया?", लेकिन "कोड ऐसा क्यों करता है?"।

— पीट बेकर

आप जोड़ने पर भी विचार कर सकते हैं: 1. साइक्लोमैटिक कॉम्प्लेक्सिटी चेकिंग का उपयोग करना 2. संस्करण नियंत्रण सॉफ्टवेयर

— अल्फ़ा गोकू

4

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

मैं सी का परित्याग नहीं करूंगा। जबकि अडा जैसी भाषाएं कुछ छोटी-मोटी गारंटी दे सकती हैं, लेकिन यह सोचना आसान है कि भाषा जितना वादा करती है, उससे कहीं अधिक यह वादा करती है।

— Theran
स्रोत

Valgrid पीसी के लिए 8-बिट MCU की तुलना में थोड़ा अधिक प्रासंगिक हो सकता है, हालाँकि :)

— लुंडिन

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

— जॉन यू

3

MISRA-C वास्तव में सामान्य कोड की गुणवत्ता में सुधार और बग को कम करने के लिए बहुत उपयोगी है। बस सुनिश्चित करें कि आप हर नियम को पढ़ते और समझते हैं, उनमें से ज्यादातर अच्छे हैं, लेकिन उनमें से कुछ का कोई मतलब नहीं है।

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

MISRA-C दस्तावेज़ के दो संस्करण हैं जो लागू हो सकते हैं। या तो MISRA-C: 2004, जो अभी भी मौजूदा एम्बेडेड उद्योग de वास्तविक मानक है। या नया MISRA-C: 2012 जो C99 मानक का समर्थन करता है। यदि आपने पहले कभी MISRA-C का उपयोग नहीं किया है, तो मैं आपको बाद वाले को लागू करने की सलाह दूंगा।

हालांकि ज्ञात हो कि टूल विक्रेता आमतौर पर MISRA-C: 2004 का उल्लेख करते हैं जब वे कहते हैं कि उनके पास MISRA जाँच है (कभी-कभी वे अप्रचलित MISRA-C: 1998 संस्करण का भी उल्लेख करते हैं)। जहाँ तक मुझे पता है, MISRA-C: 2012 का टूल सपोर्ट अभी भी सीमित है। मुझे लगता है कि केवल कुछ स्थिर विश्लेषणकर्ताओं ने इसे अब तक लागू किया है: क्लोकवर्क, एलडीआरए, पीआरक्यूए और पॉलीस्पेस। अधिक हो सकता है, लेकिन आपको निश्चित रूप से यह जांचने की आवश्यकता है कि यह किस संस्करण का समर्थन करता है।

निर्णय लेने से पहले, आप निश्चित रूप से MISRA दस्तावेज़ को पढ़कर शुरू कर सकते हैं और देखें कि यह क्या होता है। यह से £ 10 के लिए खरीदा जा सकता है misra.org आईएसओ मानक के लिए कीमतों की तुलना में काफी सस्ती।

— लुंडिन
स्रोत

1

मैथवर्क्स (MATLAB लोग) में एक स्थिर कोड विश्लेषण उपकरण होता है जिसे Polyspace कहा जाता है ।

साथ ही स्टेटिक कोड विश्लेषण, लिंट और जैसे, मैं इंटरफेस की सावधानीपूर्वक परिभाषा और डिजाइन (एक औपचारिक समीक्षा प्रक्रिया के साथ) और कोड कवरेज विश्लेषण का सुझाव दूंगा।

आप MISRA, लेकिन UL1998, और IEC 61508 मानकों सहित सुरक्षा-महत्वपूर्ण कोड डिज़ाइन के दिशानिर्देशों को भी देखना चाह सकते हैं।

— स्पेरो पेफेनी
स्रोत

जब तक आपको नहीं करना है, मैं IEC 61508 के पास जाने की सलाह नहीं देता। यह सॉफ्टवेयर का उल्लेख करता है, लेकिन इसके दावों के लिए आधुनिक, वैज्ञानिक स्रोतों का अभाव है। यह मानक 30 साल बहुत देर से आया - 70 के दशक में जारी किया गया था, इसके अधिकांश तथाकथित "स्रोत" की तरह, यह उपयोगी हो सकता था।

— लुंडिन

1

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

इसलिए, आवश्यकताओं के साथ शुरू करें और उन लोगों को लिखें और उनका निरीक्षण करें। यदि आपके पास कोई आवश्यकता दस्तावेज़ नहीं है, तो कोड की एक यादृच्छिक रेखा पर इंगित करें और अपने आप से पूछें कि "उस पंक्ति की आवश्यकता क्यों है?" कोड की किसी भी पंक्ति की आवश्यकता अंततः एक आवश्यकता के लिए होनी चाहिए, भले ही यह उतना ही सरल / स्पष्ट हो कि "बिजली की आपूर्ति 5VDC आउटपुट करेगी यदि इनपुट 12-36VDC के बीच है।" इस बारे में सोचने का एक तरीका यह है कि यदि कोड की उस लाइन को किसी आवश्यकता के बारे में पता नहीं लगाया जा सकता है, तो आपको कैसे पता चलेगा कि यह सही कोड है, या यह बिल्कुल आवश्यक है?

इसके बाद, अपना डिज़ाइन सत्यापित करें। यह ठीक है यदि यह पूरी तरह से कोड में है (उदाहरण के लिए, टिप्पणियों में), लेकिन इससे यह जानना कठिन हो जाता है कि क्या कोड वास्तव में क्या मतलब है। उदाहरण के लिए, कोड में एक पंक्ति हो सकती है जो पढ़ती है output = 3 * setpoint / (4 - (current * 5)); क्या current == 4/5एक वैध इनपुट है जो दुर्घटना का कारण बन सकता है? इस मामले में शून्य से विभाजन को रोकने के लिए क्या किया जाना चाहिए? क्या आप पूरी तरह से ऑपरेशन से बचते हैं या इसके बजाय आउटपुट को नीचा दिखाते हैं? इस तरह के किनारे के मामलों को संभालने के तरीके के बारे में आपके डिज़ाइन दस्तावेज़ में एक सामान्य नोट होने से उच्च स्तर पर डिज़ाइन को सत्यापित करना बहुत आसान हो जाता है। इसलिए, अब कोड निरीक्षण आसान है क्योंकि यह जांच का विषय है कि क्या कोड उस डिज़ाइन को सही ढंग से लागू करता है।

इसके साथ ही, कोड निरीक्षण में उन सामान्य त्रुटियों की जांच होनी चाहिए जो आपकी IDE नहीं पकड़ती हैं (आप IDE का उपयोग कर रहे हैं, दाईं ओर?) जैसे कि '=' जब आपका मतलब '==' था, तो लापता ब्रेसिज़ जो 'अगर' का अर्थ बदल दें 'कथन, अर्धविराम जहाँ उन्हें नहीं होना चाहिए, आदि।

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

— लिंडन
स्रोत

मेरी समझ यह है कि एक चिकित्सा उपकरण में कोड भाग को लगभग एक अलग उपकरण के रूप में जांचा जाता है। क्या यह सही है?

— स्कॉट सीडमैन

@ScottSeidman अधिक संभावना है, यह आवश्यकता के आधार पर परीक्षण किया जाता है, जैसा कि इस उत्तर में वर्णित है। प्रत्येक आवश्यकता के लिए, आपके पास एक कोड मॉड्यूल होना चाहिए, और प्रत्येक ऐसे कोड मॉड्यूल के लिए आपके पास एक परीक्षण होना चाहिए। इसलिए अनिवार्य रूप से, प्रत्येक आवश्यकता का एक समान परीक्षण होता है और कोड आवश्यकता को पूरा करने का माध्यम होता है। किसी भी मिशन-क्रिटिकल सिस्टम में इस तरह की आवश्यकताएं ट्रेस करना आम बात है, "टीडीडी" बज़फ़ोर्ड पॉप अप होने से पहले।

— लुंडिन

मैं एफडीए मार्गदर्शन का विशेष रूप से उल्लेख कर रहा था, जैसे कि fda.gov/downloads/RegulatoryInformation/Guidances/ucm126955.pdf सॉफ़्टवेयर को वास्तव में आपको अधिक से अधिक यह सोचना होगा कि क्या चिकित्सा उपकरण का उसका भाग, योजना चरण और डिज़ाइन नियंत्रण से शुरू हो रहा है।

— स्कॉट सीडमैन

स्कॉट, मैंने उस तरह से कभी नहीं सोचा था, लेकिन आप सही हैं। हमारे सॉफ्टवेयर क्वालिटी एश्योरेंस लोग सॉफ्टवेयर को सिस्टम के सत्यापन और सत्यापन के लिए जिम्मेदार एक अलग समूह में बदलने से पहले बाकी सिस्टम (जितना संभव हो सके) से अलग से सत्यापित करते हैं।

— लिंडन