3.10 एम्बेडेड और रियल-टाइम सिस्टम

अवलोकन और प्रेरणा

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

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

एक बड़े संगठन के लिए, यह पहली नज़र में दिखने से कहीं अधिक मायने रखता है। उद्यम कनेक्टेड कारें, चिकित्सा उपकरण, औद्योगिक कंट्रोलर, और अरबों इंटरनेट ऑफ़ थिंग्स (IoT) डिवाइस बनाते हैं। सरकारें रक्षा प्लेटफ़ॉर्म, एविओनिक्स, पावर-ग्रिड कंट्रोलर, और चिकित्सा नियामक चलाती हैं। इन डोमेन में एक सॉफ़्टवेयर दोष लोगों को चोट पहुँचा सकता है, एक उत्पादन लाइन को रोक सकता है, या राष्ट्रीय सुरक्षा से समझौता कर सकता है। यहाँ के नियम सख्त हैं, परीक्षण कठिन है, और मानक कानूनी रूप से बाध्यकारी हैं। यह अध्याय आपको वास्तविक बाधाओं के तहत सही, समयबद्ध, सुरक्षित, और संरक्षित सॉफ़्टवेयर बनाने में मदद करता है। यह सॉफ़्टवेयर निर्माण (अध्याय 2.9), वितरित सिस्टम (अध्याय 3.3), स्केलेबिलिटी और प्रदर्शन (अध्याय 3.5), इन्फ्रास्ट्रक्चर और क्लाउड सुरक्षा (अध्याय 4.3), और सॉफ़्टवेयर रखरखाव (अध्याय 3.7) से जुड़ता है।

मुख्य सिद्धांत

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

अनुशंसाएँ

हर समय-संबंधी आवश्यकता को कठोर, दृढ़, या नरम के रूप में वर्गीकृत करें

सभी समय-सीमाएँ समान नहीं होतीं। एक कठोर रियल-टाइम समय-सीमा को कभी नहीं चूकना चाहिए, क्योंकि चूकने से सिस्टम विफलता या नुकसान होता है: इंजन नियंत्रण या फ़्लाइट सरफ़ेस के बारे में सोचें। एक दृढ़ (firm) समय-सीमा दुर्लभ चूक को सहन करती है, लेकिन एक देर से मिला परिणाम बेकार है और उसे छोड़ दिया जाता है। एक नरम रियल-टाइम समय-सीमा शालीनता से मूल्य कम करती है: एक वीडियो फ़्रेम जो थोड़ी देर से आता है गुणवत्ता को कम करता है लेकिन कोई आपदा नहीं लाता। हर समय-संवेदनशील टास्क को उसके वर्ग के साथ लेबल करें, क्योंकि प्रयास, परीक्षण की कठोरता, और लागत बहुत अलग होती है। दो गुण समय व्यवहार का वर्णन करते हैं। Latency किसी घटना और प्रतिक्रिया के बीच की देरी है। Jitter उस latency में एक घटना से दूसरी घटना तक होने वाला बदलाव है। कठोर रियल-टाइम सिस्टम jitter को सीमित करने के बारे में उतना ही ध्यान रखते हैं जितना latency को कम करने के बारे में, क्योंकि अनुमेयता (predictability) ही वह चीज़ है जो आपको यह सिद्ध करने देती है कि समय-सीमा हमेशा पूरी होती है।

अपनी निष्पादन नींव को जानबूझकर चुनें: RTOS या बेयर मेटल

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

मेमोरी, CPU, और पावर को प्रथम-श्रेणी संसाधनों के रूप में बजट करें

हर दुर्लभ संसाधन को एक कठोर ऊपरी सीमा वाले बजट के रूप में मानें। मेमोरी के लिए, हीप पर डायनामिक आवंटन की तुलना में स्टैटिक आवंटन को प्राथमिकता दें, क्योंकि डायनामिक मेमोरी खंडित (fragment) हो सकती है और सबसे बुरे क्षण में अप्रत्याशित रूप से विफल हो सकती है। कई सुरक्षा मानक ठीक इसी कारण से स्टार्टअप के बाद हीप उपयोग को प्रतिबंधित या प्रतिबंधित करते हैं। CPU के लिए, worst-case execution time (WCET) मापें, यानी किसी टास्क को लगने वाला सबसे लंबा समय, और उस संख्या के विरुद्ध शेड्यूल करें, औसत के विरुद्ध नहीं। पावर के लिए, याद रखें कि कई डिवाइस बैटरी पर चलते हैं या ऊर्जा एकत्र करते हैं, इसलिए ड्यूटी साइकल, स्लीप स्टेट, और वेक-अप घटनाओं को ऐसे ऊर्जा बजट को पूरा करने के लिए डिज़ाइन करें जिसे महीनों या वर्षों तक चलना चाहिए। इन बजटों को लिख लें और किसी अन्य आवश्यकता की तरह इनकी समीक्षा करें।

इंटरप्ट और समवर्तीता (concurrency) को कठोर अनुशासन से संभालें

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

डिवाइस ड्राइवर लिखें जो हार्डवेयर विवरण को अलग करते हैं

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

उस फ़ंक्शनल-सेफ़्टी मानक को अपनाएँ जो आपके डोमेन को नियंत्रित करता है

यदि आपका डिवाइस लोगों या संपत्ति को नुकसान पहुँचा सकता है, तो एक functional-safety मानक संभवतः लागू होता है, और यह अक्सर कानून होता है। IEC 61508 इलेक्ट्रॉनिक सिस्टम की सुरक्षा के लिए सामान्य मानक है और कई अन्य का जनक है। ISO 26262 सड़क-वाहन सुरक्षा को नियंत्रित करता है। DO-178C नागरिक विमानन में हवाई सॉफ़्टवेयर को नियंत्रित करता है। IEC 62304 चिकित्सा-उपकरण सॉफ़्टवेयर को नियंत्रित करता है। कोडिंग के लिए, MISRA C व्यापक रूप से उपयोग किए जाने वाले नियमों का एक सेट है जो जोखिम भरी C भाषा सुविधाओं को प्रतिबंधित करता है ताकि कोड सुरक्षित और अधिक विश्लेषण-योग्य बने। ये मानक आवश्यकता से कोड से परीक्षण तक ट्रेसेबिलिटी, परिभाषित प्रक्रियाएँ, और सबूत की माँग करते हैं जिसे आप किसी ऑडिटर या नियामक को सौंप सकें। सही मानक को जल्दी अपनाएँ, क्योंकि बाद में पेपर ट्रेल को रेट्रोफ़िट करना पीड़ादायक और कभी-कभी असंभव होता है।

सिमुलेशन और हार्डवेयर-इन-द-लूप के साथ परीक्षण करें

आप एम्बेडेड सॉफ़्टवेयर का परीक्षण उस तरह नहीं कर सकते जैसे आप वेब ऐप का करते हैं। एक स्तरित रणनीति बनाएँ। हार्डवेयर-एब्स्ट्रैक्शन इंटरफ़ेस के विरुद्ध एक सामान्य कंप्यूटर पर यूनिट टेस्ट चलाएँ। जब वास्तविक हार्डवेयर दुर्लभ हो या अभ्यास करने के लिए खतरनाक हो तो डिवाइस और उसके वातावरण को मॉडल करने के लिए सिमुलेशन का उपयोग करें। फिर hardware-in-the-loop (HIL) परीक्षण का उपयोग करें, जहाँ वास्तविक कंट्रोलर उस भौतिक सिस्टम के सिम्युलेटेड संस्करण के विरुद्ध चलता है जिसे वह नियंत्रित करता है, ताकि आप एक अटके हुए सेंसर या अचानक भार जैसी दोष स्थितियों का सुरक्षित रूप से परीक्षण कर सकें। इन परीक्षणों को अपनी पाइपलाइन में स्वचालित करें ताकि किसी डिवाइस तक पहुँचने से पहले हर परिवर्तन यथार्थवादी स्थितियों में जाँचा जाए।

पहले दिन से ओवर-द-एयर अपडेट और डिवाइस सुरक्षा को डिज़ाइन करें

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

व्यापार-नापने: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान / लागत
RTOS	मल्टीटास्किंग, प्राथमिकता शेड्यूलिंग, समय सेवाएँ	ओवरहेड, बड़ा फ़ुटप्रिंट, सीखने की अवस्था
बेयर मेटल	सबसे छोटा, सबसे अनुमेय, पूर्ण नियंत्रण	कई टास्क तक स्केल करना कठिन, अधिक मैनुअल काम
स्टैटिक आवंटन	अनुमेय, कोई विखंडन नहीं, सुरक्षा-अनुकूल	कम लचीला, हर चीज़ का पहले से आकार तय करना ज़रूरी
औपचारिक सुरक्षा प्रमाणन	कानूनी बाज़ार पहुँच, कठोर सबूत, उच्च विश्वास	बड़ी समय और धन लागत, धीमी पुनरावृत्ति
OTA अपडेट	फ़ील्ड में मौजूद डिवाइस को ठीक और बेहतर बनाना, जीवनकाल बढ़ाना	अपडेट इन्फ्रास्ट्रक्चर, सुरक्षा बोझ, रोलबैक जोखिम

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

1. क्या आप अपने समय-महत्वपूर्ण पथों पर jitter मापते हैं, या केवल औसत latency? कठोर रियल-टाइम सटीकता प्रतिक्रिया समय (jitter) में बदलाव को सीमित करने पर टिकी होती है, न कि केवल सामान्य latency को कम करने पर, क्योंकि अनुमेयता ही वह चीज़ है जो आपको यह सिद्ध करने देती है कि समय-सीमा हमेशा पूरी होती है। एक कम औसत वाला लेकिन कभी-कभार बड़े स्पाइक वाला कंट्रोल लूप फिर भी अपनी समय-सीमा चूक सकता है और नुकसान पहुँचा सकता है, और औसत इसे छिपा देगा। हर समय-महत्वपूर्ण टास्क के लिए फैलाव (spread) के मापन लाएँ, सबसे बुरा मामला शामिल करते हुए, और हर एक को कठोर, दृढ़, या नरम के रूप में लेबल करें ताकि परीक्षण की कठोरता चूक के परिणाम से मेल खाए। सामान्य-प्रयोजन सिस्टम में सुविधाजनक हर चीज़ (डायनामिक मेमोरी, गार्बेज कलेक्शन, बेस्ट-एफ़र्ट शेड्यूलिंग) अनुमेयता पर हमला करती है, इसलिए यह कठोर पथ से बाहर रहती है। यदि आप केवल औसत रिपोर्ट करते हैं, तो आप ईमानदारी से यह दावा नहीं कर सकते कि एक कठोर समय-सीमा पूरी हो रही है।

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

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

4. प्रत्येक उत्पाद को कौन सा फ़ंक्शनल-सेफ़्टी मानक नियंत्रित करता है, और वर्तमान सबूत उससे कितनी दूर है जिसे कोई ऑडिटर स्वीकार करेगा? मानक (IEC 61508, सड़क वाहनों के लिए ISO 26262, हवाई सॉफ़्टवेयर के लिए DO-178C, चिकित्सा उपकरणों के लिए IEC 62304) अक्सर कानून होता है, और यह आवश्यकता से कोड से परीक्षण तक ऐसी ट्रेसेबिलिटी की माँग करता है जिसे आप अंत में नकली नहीं बना सकते। एक बड़ी टीम के लिए जोखिम यह है कि समूह पेपर ट्रेल को असमान रूप से अपनाते हैं, ताकि एक उत्पाद लाइन ऑडिट के लिए तैयार हो जबकि दूसरी प्रमाणन के बीच में यह खोजे कि उसकी आवश्यकताओं को कभी ट्रेस नहीं किया गया। प्रतिस्पर्धी खिंचाव गति है: पूर्ण ट्रेसेबिलिटी और MISRA C प्रवर्तन दिन-प्रतिदिन की पुनरावृत्ति को धीमा करते हैं, और समय-सीमा के दबाव में एक टीम सबूत को “बाद में” तक टालने के लिए प्रलोभित होती है। वर्तमान ट्रेसेबिलिटी मैट्रिक्स, अभी भी खुले स्टैटिक-विश्लेषण निष्कर्ष, और लक्ष्य आश्वासन स्तर के विरुद्ध एक ईमानदार अंतर विश्लेषण लाएँ। उद्यम और सरकारी संदर्भों में, प्रमाणन लीड टाइम और ऑडिटर की अपेक्षाएँ जोड़ें, क्योंकि डिज़ाइन के बाद सबूत को रेट्रोफ़िट करना धीमा, महंगा, और कभी-कभी असंभव है, और एक फिसला हुआ प्रमाणन बाज़ार पहुँच को पूरी तरह अवरुद्ध कर सकता है।

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

6. क्या आपके मेमोरी, CPU, और पावर बजट कठोर ऊपरी सीमाओं के साथ लिखे गए हैं, और क्या आपकी परीक्षण रणनीति सिमुलेशन और वास्तविक हार्डवेयर दोनों का अभ्यास करती है? रियल-टाइम गारंटी सबसे बुरे मामले के निष्पादन समय और एक तय संसाधन फ़ुटप्रिंट पर टिकी होती है, औसत व्यवहार पर नहीं, इसलिए एक अबजटित हीप आवंटन या एक अपरीक्षित सबसे बुरा-मामला भार वह जगह है जहाँ निर्धारणवाद चुपचाप क्षीण होता है। एक बड़ी टीम के लिए खतरा बहाव (drift) है: टास्क जमा होते हैं, मेमोरी रेंगती रहती है, और सप्ताहों के अपटाइम के बाद जब एक डिवाइस फ़ील्ड में विफल होता है तब तक कोई बजट का मालिक नहीं होता। व्यापार-नापना कवरेज बनाम लागत है, क्योंकि एक हार्डवेयर-इन-द-लूप रिग जो अटके हुए सेंसर जैसे दोष इंजेक्ट करता है, बनाना महंगा है, जबकि शुद्ध सिमुलेशन उन समय बगों को छिपाता है जो केवल वास्तविक चिप पर दिखाई देते हैं। दस्तावेज़ीकृत बजट, उनके विरुद्ध मापे गए सबसे बुरे मामले के निष्पादन समय, और यह सबूत लाएँ कि आपकी पाइपलाइन रिलीज़ से पहले एब्स्ट्रैक्शन परत, सिमुलेशन, और हार्डवेयर-इन-द-लूप पर यूनिट टेस्ट चलाती है। विनियमित और सरकारी सेटिंग में, इसे मानक द्वारा आवश्यक संरचनात्मक परीक्षण कवरेज से जोड़ें, क्योंकि एक ऑडिटर इस बात का सबूत चाहेगा कि दोष स्थितियों का अभ्यास किया गया था, इस आश्वासन का नहीं कि औसत मामला ठीक दिखा।

सेक्टर लेंस

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

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

उद्यम। समस्या कई उत्पाद लाइनों और टीमों में स्थिरता है: एक साझा निष्पादन-नींव नीति, सामान्य संसाधन-बजट टेम्पलेट, प्रवर्तित MISRA C और स्टैटिक विश्लेषण, और एक प्रमाणित ओवर-द-एयर अपडेट और सिक्योर-बूट प्लेटफ़ॉर्म ताकि हर समूह इसे फिर से न बनाए। फ़ंक्शनल-सेफ़्टी और हार्डवेयर-इन-द-लूप बोझ का स्पष्ट रूप से बजट बनाएँ, हार्डवेयर-एब्स्ट्रैक्शन इंटरफ़ेस को मानकीकृत करें ताकि स्टॉक से बाहर होने वाली चिप किसी उत्पाद को न फँसाए, और फ़्लीट के समय सबूत, सुरक्षा कलाकृतियों, और सुरक्षा स्थिति को प्रति-टीम लोककथा के बजाय शासित संपत्ति के रूप में प्रबंधित करें। पूरे फ़्लीट में एक ही कमज़ोर डिफ़ॉल्ट क्रेडेंशियल एक उद्यम-स्तरीय देयता है, इसलिए क्रेडेंशियल और कुंजी प्रबंधन को केंद्रीकृत करें।

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही हर चुनाव को आकार देते हैं। आपूर्तिकर्ताओं को खतरे से मेल खाते आश्वासन स्तर पर शासी मानक (DO-178C, IEC 62304, IEC 61508) के अनुसार हवाई, चिकित्सा, या रक्षा सॉफ़्टवेयर विकसित करने और ऑडिटर समीक्षा करेंगे ऐसी ट्रेसेबिलिटी और संरचनात्मक-कवरेज सबूत सौंपने के लिए कहें। सिक्योर बूट, एक हार्डवेयर रूट ऑफ़ ट्रस्ट, और एक नियंत्रित, हस्ताक्षरित फ़ील्ड-अपडेट प्रक्रिया की माँग करें, क्योंकि किसी फ़्लाइट या ग्रिड सिस्टम में एक असत्यापित अपडेट अस्वीकार्य है। उन अनुबंधों को प्राथमिकता दें जो सोर्स, सुरक्षा कलाकृतियों, और दूसरे आपूर्तिकर्ता के साथ पुनः-प्रमाणित करने की क्षमता के अधिकार देते हैं, ताकि कोई विक्रेता का व्यवसाय बंद होना किसी ऐसे सिस्टम को न फँसाए जिस पर जनता दशकों तक निर्भर करती है।

उदाहरण

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

उद्यम। एक कनेक्टेड-वाहन निर्माता एक इलेक्ट्रॉनिक ब्रेकिंग कंट्रोलर बनाता है। कठोर रियल-टाइम कंट्रोल लूप रेट-मोनोटोनिक शेड्यूलिंग और स्टैटिक मेमोरी वाले एक RTOS पर चलता है, और हर टास्क एक मापा गया सबसे बुरा-मामला निष्पादन समय ले जाता है। टीम आवश्यकता से कोड से परीक्षण तक पूर्ण ट्रेसेबिलिटी के साथ ISO 26262 के लिए विकसित करती है, और हर कमिट पर स्टैटिक विश्लेषण के साथ MISRA C को लागू करती है। एक हार्डवेयर-इन-द-लूप रिग किसी भी फ़र्मवेयर के शिप होने से पहले इंजेक्ट किए गए सेंसर दोषों सहित हज़ारों सड़क परिदृश्यों को दोहराता है। हस्ताक्षरित OTA अपडेट कंपनी को महंगे रिकॉल के बिना पूरे फ़्लीट में एक दोष ठीक करने देते हैं, यदि कोई कार नए इमेज को बूट करने में विफल रहती है तो स्वचालित रोलबैक के साथ।

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

व्यापार मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

• औसत मामले के लिए अनुकूलन करना। समय-सीमा को “आमतौर पर” पूरा करना एक कठोर रियल-टाइम आवश्यकता को विफल करना है।
• कंट्रोल पथ में डायनामिक आवंटन। हीप विखंडन एक ऐसी विफलता का कारण बनता है जो केवल सप्ताहों के अपटाइम के बाद दिखाई देती है।
• मोटे इंटरप्ट हैंडलर। किसी इंटरप्ट के अंदर भारी प्रोसेसिंग डालना आपके समय बजट को उड़ा देता है और रेस कंडीशन बनाता है।
• ऑडिट तक मानक को नज़रअंदाज़ करना। देर से ट्रेसेबिलिटी और सबूत को रेट्रोफ़िट करना धीमा, महंगा, और कभी-कभी असंभव है।
• बिना अपडेट पथ के शिप करना। एक डिवाइस जिसे आप पैच नहीं कर सकते, एक स्थायी सुरक्षा और संरक्षा देयता बन जाता है।
• डिफ़ॉल्ट पासवर्ड और खुले इंटरफ़ेस। एक कमज़ोर क्रेडेंशियल एक IoT फ़्लीट को बॉटनेट में बदल देता है।
• केवल सिम्युलेटर पर या केवल हार्डवेयर पर परीक्षण करना। प्रत्येक ऐसे बग छिपाता है जिन्हें दूसरा पकड़ लेता; आपको दोनों की आवश्यकता है।
• हार्डवेयर को किसी और की समस्या मानना। समय, बाइट ऑर्डर, और सेंसर विचित्रताएँ यहाँ सॉफ़्टवेयर की चिंताएँ हैं।

परिपक्वता मॉडल

• स्तर 1: आरंभ करें। समय की उम्मीद की जाती है, विश्लेषण नहीं किया जाता। मेमोरी मनमाने ढंग से डायनामिक रूप से आवंटित की जाती है। किसी फ़ंक्शनल-सेफ़्टी मानक का पालन नहीं किया जाता। परीक्षण मैनुअल और केवल ऑन-डिवाइस है। डिवाइस को शिप होने के बाद अपडेट नहीं किया जा सकता, इसलिए एक फ़ील्ड दोष का मतलब रिकॉल या स्थायी देयता है।
• स्तर 2: विकसित करें। कुछ टास्क में मापा गया समय है और एक बुनियादी RTOS या संरचित लूप जगह पर है, लेकिन अभ्यास टीम-दर-टीम भिन्न होता है। कोडिंग दिशानिर्देश मौजूद हैं लेकिन लागू नहीं किए जाते। परीक्षण में कुछ सिमुलेशन शामिल है। कुछ उत्पादों पर एक मैनुअल, जोखिम भरा अपडेट पथ मौजूद है और अन्य पर नहीं। अच्छी आदतें मौजूद हैं लेकिन असंगत, और कुछ भी यह गारंटी नहीं देता कि अगली उत्पाद लाइन उन्हें विरासत में पाएगी।
• स्तर 3: मानकीकृत करें। समय आवश्यकताओं को कठोर, दृढ़, या नरम के रूप में वर्गीकृत किया जाता है, और सबसे बुरे मामले के निष्पादन समय और एक शेड्यूल-योग्यता विधि से विश्लेषित किया जाता है, संगठन भर में दस्तावेज़ीकृत और लागू किया जाता है। मेमोरी, CPU, और पावर के लिए संसाधन बजट कठोर ऊपरी सीमाओं के साथ लिखे जाते हैं। शासी फ़ंक्शनल-सेफ़्टी मानक का पालन आवश्यकता से कोड से परीक्षण तक ट्रेसेबिलिटी के साथ किया जाता है, और MISRA C या समकक्ष को हर कमिट पर स्टैटिक विश्लेषण द्वारा लागू किया जाता है। हार्डवेयर-इन-द-लूप परीक्षण पाइपलाइन में चलता है। रोलबैक और सिक्योर बूट के साथ हस्ताक्षरित, परमाणु ओवर-द-एयर अपडेट हर जगह आवश्यक आधाररेखा हैं।
• स्तर 4: प्रबंधित करें। संगठन अपनी एम्बेडेड संपत्ति को बेसलाइन के विरुद्ध मापता और नियंत्रित करता है। यह सबसे बुरे मामले के निष्पादन समय के मार्जिन, jitter वितरण, समय-सीमा-चूक दरें, मेमोरी और पावर हेडरूम, अभी भी खुले स्टैटिक-विश्लेषण निष्कर्ष, प्रमाणन-सबूत कवरेज, और ओवर-द-एयर अपडेट सफलता और रोलबैक दरें ट्रैक करता है, और इनकी तुलना सहमत लक्ष्यों से करता है। किसी संसाधन या समय बजट के विरुद्ध बहाव किसी डिवाइस के फ़ील्ड में विफल होने से पहले कार्रवाई को ट्रिगर करता है, और आगे बढ़ें या न बढ़ें रिलीज़ निर्णय क्षण में निर्णय के बजाय इस डेटा पर टिके होते हैं। प्रबंधक देख सकते हैं कि कौन सी उत्पाद लाइनें ऑडिट के लिए तैयार हैं और कौन सी एक चूकी हुई समय-सीमा या उड़ा हुआ बजट की ओर बढ़ रही हैं।
• स्तर 5: ऑर्केस्ट्रेट करें। निर्धारणवाद, सुरक्षा सबूत, और संरक्षा को लगातार सत्यापित और स्वचालित किया जाता है। फ़ॉल्ट इंजेक्शन और हार्डवेयर-इन-द-लूप हर परिवर्तन पर चलते हैं, और प्रमाणन कलाकृतियाँ प्रक्रिया के उपोत्पाद के रूप में उत्पन्न होती हैं। फ़्लीट की निगरानी की जाती है, पैच किया जाता है, और एक लंबे सेवा जीवन में बड़े पैमाने पर सुरक्षित रूप से अपडेट किया जाता है। संगठन अपनी निष्पादन नींव, संसाधन बजट, और मानक अपनाने को अनुकूलित करता है जैसे चिप स्टॉक से बाहर होते हैं, खतरे विकसित होते हैं, और नियम बदलते हैं, हर संकट पर अलग से प्रतिक्रिया करने के बजाय सबूत पर पूरे डिवाइस पोर्टफ़ोलियो को फिर से संतुलित करता है।

चर्चा के लिए विचार

1. आपके डिवाइस के कौन से टास्क वास्तव में कठोर रियल-टाइम हैं, और क्या आप सिद्ध कर सकते हैं कि हर एक हमेशा अपनी समय-सीमा पूरी करता है?
2. क्या आप अपने महत्वपूर्ण कंट्रोल लूप का सबसे बुरा-मामला निष्पादन समय जानते हैं, या केवल उसका औसत?
3. कौन सा फ़ंक्शनल-सेफ़्टी मानक आपके उत्पाद को नियंत्रित करता है, और आपका वर्तमान सबूत उससे कितनी दूर है जिसकी यह माँग करता है?
4. यदि कल किसी फ़ील्ड डिवाइस में एक गंभीर दोष पाया जाए, तो आप इसे कैसे ठीक करेंगे, और कितनी तेज़ी से?
5. आपके कंट्रोल पथ में डायनामिक मेमोरी आवंटन अभी भी कहाँ मौजूद है, और यदि यह घंटा 1000 पर विफल हो जाए तो क्या होता है?
6. आपका IoT फ़्लीट एक ऐसे हमलावर को कैसे झेलेगा जिसे एक साझा डिफ़ॉल्ट क्रेडेंशियल मिल गया हो?

मुख्य निष्कर्ष

• एम्बेडेड सॉफ़्टवेयर सीमित हार्डवेयर पर चलता है, और रियल-टाइम सटीकता समय पर निर्भर करती है, केवल सही उत्तर पर नहीं।
• हर समय-सीमा को कठोर, दृढ़, या नरम के रूप में वर्गीकृत करें, और सबसे बुरे मामले के समय, बाउंडेड jitter, और कच्ची गति पर निर्धारणवाद के लिए डिज़ाइन करें।
• जानबूझकर एक RTOS या बेयर मेटल चुनें, और मेमोरी, CPU, और पावर को तय, प्रथम-श्रेणी संसाधनों के रूप में बजट करें।
• इंटरप्ट हैंडलर को छोटा रखें, साझा डेटा की रक्षा करें, और हार्डवेयर को स्वच्छ, परीक्षण-योग्य ड्राइवर इंटरफ़ेस के पीछे अलग करें।
• अपने डोमेन द्वारा आवश्यक फ़ंक्शनल-सेफ़्टी मानक (IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C) को जल्दी अपनाएँ, पूर्ण ट्रेसेबिलिटी के साथ।
• सिमुलेशन और हार्डवेयर-इन-द-लूप के साथ परीक्षण करें, और पहले दिन से सुरक्षित, हस्ताक्षरित, रोलबैक-सक्षम OTA अपडेट और डिवाइस सुरक्षा बनाएँ।

संदर्भ और आगे पढ़ने के लिए

• IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
• ISO 26262, Road Vehicles: Functional Safety
• RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
• IEC 62304, Medical Device Software: Software Life Cycle Processes
• MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
• Michael Barr and Anthony Massa, Programming Embedded Systems
• Elecia White, Making Embedded Systems
• Jane W. S. Liu, Real-Time Systems
• Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
• Colin Walls, Embedded Software: The Works
• Philip Koopman, Better Embedded System Software
• OWASP इंटरनेट ऑफ़ थिंग्स (IoT) सुरक्षा मार्गदर्शन