आप बड़ी एम्बेडेड परियोजनाओं की संरचना कैसे करते हैं? [बन्द है]

Question

पृष्ठभूमि :

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

अब तक मैंने केवल मामूली सॉफ्टवेयर परियोजनाएं (कोड की उप 500 लाइनें) बनाई हैं, लेकिन मैं कार्यक्षमता या कार्यक्षमता की कमी को खोए बिना बड़ी परियोजनाओं को करने की कल्पना नहीं कर सकता।

कैसे आप सबसे अच्छा संरचना / क्या उपकरण आप बड़े एम्बेडेड सॉफ्टवेयर सिस्टम की संरचना के लिए उपयोग करते हैं?

मैं वर्तमान में क्या कर रहा हूँ :

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

क्या जवाब देने के लिए मैं देख रहा हूँ :

सच में कुछ भी। मैं जो समझदार हूं उसे सुलझा लूंगा। यह एक पुस्तक, एक लेख, व्यक्तिगत अनुभव, सिफारिशें आदि हो सकती है।

मुझे यह जानने में बहुत दिलचस्पी है कि सीनियर्स इससे कैसे निपटते हैं।

---

संपादित करें

सबसे पहले, अपने अनुभव के वर्षों को साझा करने के लिए धन्यवाद! सभी जवाब बहुत सराहना की है। इस से मेरा लेना है;

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

Comments

यह सवाल यहाँ नहीं है ... मई softwareengineering.stackexchange.com

— स्वानंद

हो सकता है कि इस सवाल का इस स्थान से संबंधित है। मैं दशकों पहले कई चिप डिजाइन टीम को सम्मानित करता हूं, और हमने प्रत्येक चिप को विभिन्न कार्यों में विघटित करके प्रगति को ट्रैक किया है, और फिर हफ्तों की जरूरत का अनुमान लगा रहा है (newbies की एक टीम, प्रेरित, लेकिन newbies: समझ प्रत्येक 60+ कार्यों के डिजाइन / परीक्षण / समीक्षा। यहां तक ​​कि हम मूल प्रबंधन-लगाए गए अनुसूची को पूरा नहीं करते थे, प्रबंधन रोगी था क्योंकि वे आसानी से 60+ कार्यों के माध्यम से प्रगति को ट्रैक कर सकते थे जिन्हें हम जानते थे कि हमें डिजाइन करने और फिर एकीकृत करने की आवश्यकता है।

— analogsystemsrf

@ सवानंद मैं असहमत। ऑन-टॉपिक FAQ कहता है "[सवालों के बारे में ...] नंगे-धातु या आरटीओएस अनुप्रयोगों के लिए फर्मवेयर का लेखन" - मैं कहूंगा कि यह निश्चित रूप से नियोजन चरण भी शामिल है। प्रश्न विशेष रूप से "बड़े एम्बेडेड सिस्टम" बताता है।

— आराहो

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

— पाइप

ओपी ने एक अच्छा सारांश बनाया है। मैं सिर्फ उन पर जोर देना चाहूंगा कि GitHub एक Git रिपॉजिटरी को चलाने का एकमात्र तरीका नहीं है। आप विशेष रूप से चल रहे Git सर्वर के साथ या बिना स्थानीय स्तर पर ऐसा कर सकते हैं। Git केवल सोर्स कंट्रोल सिस्टम (SCS) / वर्जन कंट्रोल सिस्टम (VCS) का ही रूप नहीं है, बल्कि यह अब बहुत लोकप्रिय है। जब मैंने बहुत सी और सी ++ प्रशिक्षण के साथ ईई के रूप में शुरू किया तो मेरे पास ऐसी चीजों के लिए शून्य जोखिम था।

— TafT

Answer 1

वहाँ कई विस्तार के ग्रेड एक परियोजना की जरूरत की संरचना को प्रभावित करने पहलू हैं। मेरे लिए मुख्य कारकों में से एक यह है कि क्या मैं केवल एक कोडिंग हूं (जैसा कि आप लिखते हैं कि आप केवल ईई हैं) या यदि कोई अन्य इसमें शामिल हैं तो आपके लिए मामला क्या है। फिर सवाल है कि वास्तव में "बड़े" का क्या मतलब है। आमतौर पर मैं डिजाइन प्रक्रिया को निम्नलिखित चरणों में विभाजित करता हूं:

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

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

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

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

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

Comments

विशेष रूप से आवश्यकताओं! एक उत्पाद या फ़ंक्शन बनाने जैसा कुछ भी नहीं जो गलत काम करता है।

— ConcernedHobbit

Answer 2

हंपावपा ने शानदार जवाब लिखा ! मैं बस उनके कुछ बिंदुओं को पूरक करना चाहता हूं, लेकिन चूंकि यह टिप्पणी करने के लिए बहुत लंबा है, इसलिए मैं एक अलग उत्तर लिखूंगा।

मैं एक बार ओपी की स्थिति में था - केवल ईई नहीं, बल्कि एकमात्र ईई जिसने किसी छोटी कंपनी में कोई एमसीयू विकास किया था।

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

मैंने एक विस्तृत डेटा प्रवाह आरेख ^{1 को} बनाए रखने में बहुत समय बिताया , जो ठीक-ठीक दिखाता था कि विभिन्न मॉड्यूल ने जानकारी कैसे साझा की है। कुछ सुविधाओं वास्तविक समय प्रदर्शन के मामले में बहुत अलग-अलग शर्तें जाएगा; सुनिश्चित करें कि आप जानते हैं कि कैसे जानकारी साझा कि प्रभावित करते हैं। आरेख की सीमाएँ इसके पार खींची गई थीं जो गैर-अवरोधक कोड को विभिन्न व्यवधान-संचालित डोमेन से अलग करती थीं।

---

¹ एक प्रवाह संचित्र, जो पर केंद्रित है से बहुत अलग नियंत्रण प्रवाह।

Answer 3

किसी भी बड़े परियोजना के लिए, मैं यह योजना के रूप में एक से अधिक संलग्न डेवलपर थे अगर मैं पूरी बात खुद ही करता हूं करने का इरादा भी।

कारणों सरल हैं:

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

2 आवश्यकताएँ। मान लिया जाये कि एक से अधिक लोगों को शामिल अर्थ यह है कि शीर्ष स्तर की आवश्यकताओं (जो मैं अक्सर के रूप में वे अनावश्यक जटिलता और लागत ला सकते हैं को चुनौती) कर रहे हैं चाहिए विभिन्न छोटे की आवश्यकता है और प्राप्त कार्यों में बांटा जा (जो एक बड़े संगठन में एक अन्य टीम को खिलाया जा सकता है ) के बजाय केवल एक ही बूँद को देख रहा है।

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

4 इंटरफेस। विभाजन प्रक्रिया आंतरिक इंटरफेस को परिभाषित करने में मदद करेगी; बाहरी इंटरफेस आम तौर पर समग्र आवश्यकताओं का हिस्सा होते हैं (हालांकि हमेशा नहीं)। रहे हैं कई करने के लिए एक प्रणाली के विभिन्न भागों के लिए तरीके सहयोग एक जटिल संचार प्रोटोकॉल या बस अच्छा / बुरा संकेत हो सकता है।

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

6 मानक। मैं कोडिंग और ड्राइंग मानकों का उपयोग करता हूं जैसे कि यह एक बड़ी टीम थी। मैं बर्र समूह के कोडिंग मानकों का उपयोग करता हूं क्योंकि वे बहुत खराब नहीं हैं, लेकिन कोड में बग के कई वर्गों को रोकते हैं। पीसीबी आउटपुट डॉक्यूमेंटेशन के लिए मैं IPC-D-326 (जिसे IPC-D-325 कॉल करता हूं) का पालन करता हूं क्योंकि यह पीसीबी फैब्रिकेटर और असेंबलरों के लिए मेरे इरादे को संप्रेषित करने का एक सिद्ध तरीका है। यह अजीब लग सकता है लेकिन कई मानकों का पालन करने के लिए अनुशासन होने का मतलब है कि गुणवत्ता सुसंगत है।

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

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

इन सभी चीजों को करने से थोड़ा आगे का समय जुड़ जाता है लेकिन अंततः जटिल एम्बेडेड सिस्टम के लिए एक तेज़ मार्ग है।

Answer 4

अन्य उत्तर कई बेहतरीन टिप्स देते हैं। यहाँ दो हैं जिन्हें मैंने अपने एम्बेडेड विकास कैरियर में सबसे महत्वपूर्ण पाया है:

1. कोड के जितना संभव हो उतना अलग, अच्छी तरह से परिभाषित मॉड्यूल बनाएं।
2. पीसी पर मॉड्यूल को स्वचालित रूप से परीक्षण योग्य बनाएं।

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

Answer 5

मौजूदा उत्तरों में जोड़ने के लिए ...

मैं हमेशा नीचे से शुरू करता हूं। आपके हार्डवेयर डिज़ाइन से, आप जानते हैं कि आपका I / O क्या है। ड्राइवर मॉड्यूल का निर्माण शुरू करें जो कि I / O को एनकैप्सुलेट करता है, ताकि आपके उच्च स्तर के कोड को निम्न स्तर के सामान के बारे में बहुत अधिक जानना न पड़े।

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

Answer 6

मैं चार प्रश्नों में सोचता हूं। पहले दो एक सिस्टम प्रोजेक्ट की शुरुआत के हैं, दो अगले छोर की ओर।

1. क्या वे वास्तव में व्यवस्था चाहते हैं? प्रणाली ग्राहकों समस्या का समाधान होगा, एक समय और लागत पैमाने वे स्वीकार करेंगे पर? एक आम समस्या प्रणाली है कि ग्राहक का उपयोग नहीं होगा बनाने जा रहा है।

2. क्या हम वास्तव में उस प्रणाली का निर्माण कर सकते हैं? यह आवश्यक प्रदर्शन, सटीक, बिजली के उपयोग, ... देने के लिए संभवतः हो जाएगा?

---

जल्दी प्रोटोटाइप बनाना एक अच्छा तरीका है इन दोनों पहले सवालों के जवाब देने के लिए है। जोखिम को कम करने की शुरुआत चरणों में अत्यंत महत्वपूर्ण है।

---

अगले दो प्रश्न अधिक परियोजना के बाद के चरणों में लक्षित कर रहे हैं:

3. क्या हम वास्तव में समाप्त हो गए हैं? सब कुछ डिजाइन, कोडित, परीक्षण, वितरित

4. क्या वे वास्तव में सिस्टम का उपयोग करते हैं?