वितरित विकास को कैसे व्यवस्थित किया जाए, अगर यह संभव नहीं है

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

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



मैं एक कंपनी के लिए काम करता हूं जिसे मामूली तौर पर MIR कहा जाता है। भुगतान प्रणाली के साथ भ्रमित न हों, हमारा इससे कोई संबंध नहीं है।

हमारे मामले में विश्व विकास उपकरण की कार्यशाला के लिए खड़ा है।

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

उनके लिए, हम विकास उपकरण विकसित करते हैं: आईडीई, कंपाइलर, रीयल-टाइम ऑपरेटिंग सिस्टम, डिबगर, सिमुलेटर, प्रोफाइलर और अन्य एसडीके घटक।

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



ग्राहकों के लिए, हम बाहरी डेवलपर हैं। इसके अलावा, हम सेंट पीटर्सबर्ग, वेलिकी नोवगोरोड और क्रास्नोयार्स्क में स्थित हैं, और हमारे ग्राहक मास्को, ज़ेलेनोग्राड, तुला, वोरोनिश, जर्मनी और कोरिया में हैं।

उसी समय, हम उपकरणों के लिए सॉफ्टवेयर विकसित करते हैं। और किसी विशिष्ट डिवाइस को प्रोग्राम करने के लिए, प्रोग्रामर के पास यह डिवाइस होना आवश्यक है।

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



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

डेवलपर समस्याएँ

और यहीं से समस्याएं शुरू होती हैं। पहले एक का सामना हम उपकरणों की उपलब्धता से करते हैं।

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

उदाहरण के लिए, जैसा कि जेएससी पीकेके मिलैंडर के नए प्रोसेसर 1967 क्यूसी 2 के साथ मामला है। यह अभी भी ओसीडी के पूरा होने की स्थिति में है, लेकिन इसके लिए विकास उपकरण अभी किए जाने की आवश्यकता है।



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

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

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

अब कल्पना करें कि आप एक गैस विश्लेषक विकसित कर रहे हैं, जो कई विशाल और भारी सिलेंडर के साथ आता है ...



या एक हेलीकाप्टर के लिए एक स्प्रे प्रणाली।





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

लेकिन समस्याएँ तब भी आती हैं, जब प्रोग्रामर उसी बिल्डिंग में हों।

यदि कोई औपचारिक स्थानांतरण प्रक्रिया नहीं है तो उपकरण "खो" सकता है और यह परियोजना के भीतर प्रोग्रामर के बीच चला जाता है। या उपकरण डेवलपर के लिए लंबे समय तक "जा सकते हैं", अगर औपचारिक प्रक्रियाएं हैं, लेकिन नौकरशाही है। मैं यह नहीं कह सकता कि हमने वास्तव में ग्राहक के उपकरण खो दिए हैं, लेकिन ऐसे हालात थे जब यह स्पष्ट नहीं था कि इस समय वास्तव में डिबगिंग बोर्ड किसके पास है, और यह कब तक व्यस्त रहेगा। स्थिति अनिश्चित है, पांच मिनट में हल हो गई है, लेकिन कई परियोजनाएं हैं। अतिरिक्त समय क्यों दें?

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

और यहां तक ​​कि अगर आप एक शानदार नेता हैं और एक उत्कृष्ट प्रक्रिया और लॉजिस्टिक्स का निर्माण करते हैं, तो आप बिना हिलाए एक दूरस्थ प्रोग्रामिंग समाधान को हल करके दक्षता में खो देंगे।

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

पारंपरिक समाधान

निष्कर्ष स्पष्ट है - दूर से लोहे के साथ काम करना बहुत लाभदायक हो सकता है। आपको सभी हार्डवेयर को एक स्थान पर रखना होगा और टीम को रिमोट एक्सेस देना होगा।

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

और इस योजना में सब कुछ बहुत अच्छा होगा, लेकिन उत्पाद से जुड़े कंप्यूटर पर मानक रिमोट एक्सेस का उपयोग करना काम नहीं करता है।

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

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

और फिर एक सहयोगी जिसे प्रोग्रामर ने "सोचा था" को 5-10 मिनट के लिए इसे वापस करना होगा, यह उस समय की गिनती नहीं कर रहा है जो वह चला रहा था और उन्होंने उसे फोन पर समझाया जो खींचने के लिए स्विच करते हैं। इसलिए कई परियोजनाओं पर एक बार में मानव-घंटे और दर्जनों मानव-घंटे बेकार चलाएं जो वर्तमान से संबंधित नहीं हैं।

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

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

सिवाय इसके कि जब उपकरणों की तुलना में अधिक डेवलपर्स हैं, तो एक्सेस प्रक्रिया का कोई केंद्रीकृत और स्पष्ट संगठन नहीं है । और टीम के साथ काम करते समय, आपको किसी तरह से अलग से सहमत होना होगा कि उपकरण के साथ कौन और कब काम करता है।

Redd - रिमोट प्रोग्रामिंग कॉम्प्लेक्स

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

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



हमने "नैनो इनोवेशन" को आगे नहीं बढ़ाया। वास्तव में, Redd केवल एक डिवाइस में संयुक्त रूप से समझने योग्य और सरल तकनीकें हैं, जो कुल मिलाकर उन समस्याओं का समाधान देती हैं जो मैंने ऊपर वर्णित की हैं।

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



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



तकनीकी रूप से, Redd में दो निर्भर घटक होते हैं: एक "दूरस्थ टर्मिनल" और सर्वर सॉफ्टवेयर।



रिमोट टर्मिनल इंटेल प्रोसेसर पर आधारित एक पीसी संगत कंप्यूटर है, जो एक इंटरफ़ेस विस्तार बोर्ड से सुसज्जित है, जिसे हम स्वयं विकसित कर रहे हैं। पहले संस्करण (मार्च में) ईथरनेट और यूएसबी होस्ट (JTAG) उपलब्ध होंगे। दूसरे (जून में) - UART, ईथरनेट, GPIO, SPI (+ SPI फ्लैश), SDIO (एक एसडी कार्ड एमुलेटर के लिए एक एडेप्टर के साथ), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, पावर स्विचिंग और लॉजिकल के लिए पावर स्विच सक्रियण की कुंजी, उदाहरण के लिए, बटन।



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

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



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

सिस्टम बाहरी दुनिया के साथ कैसे संवाद करता है? विभिन्न बसों से वाया सेंसर जुड़े हैं। वैसे, बसों पर एक्ट्यूएटर्स के सिग्नल भी जारी किए जाते हैं। वर्तमान टायर रेंज काफी विस्तृत है। यह CAN, UART (CMOS, RS232, RS485 संस्करण में), ईथरनेट, MODBUS (एक ही UART या ईथरनेट के माध्यम से), विभिन्न स्तरों के साथ डिजिटल लाइनें और इतने पर, इतने पर हो सकता है।

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

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

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



इस प्रकार, Redd किसी डिवाइस (या उपकरणों के समूह) के लिए आंतरिक या बाहरी डेवलपर्स के रिमोट एक्सेस को व्यवस्थित करने की अनुमति देता है, भौतिक आंदोलन के बिना, समय के साथ कई उपकरणों को कनेक्ट करना संभव है।



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

अब क्या

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

इस लेख का मुख्य उद्देश्य (विज्ञापन को छोड़कर) प्रतिक्रिया एकत्र करना है।

यदि आप इस बात से सहमत नहीं हैं कि लेख में वर्णित समस्याएं हैं, या आप उन समस्याओं को नाम दे सकते हैं जिन्हें मैं भूल गया था।

हो सकता है कि आपको एक ऐसा समाधान पता हो जो हमें नहीं मिला हो, या आप इन समस्याओं को अपने तरीके से हल करें।

या वे उत्पाद विकास में एक तरह के शब्द (या शायद न केवल) के साथ हमारा समर्थन करने के लिए तैयार हैं।
मुझे टिप्पणी करने में खुशी होगी।