🛰️ 💅🏼 🗞️ आईओटी जहां आपने इंतजार नहीं किया। विकास और परीक्षण (भाग 2) 💅🏾 ☀️ 🚽

लेख के पहले भाग की निरंतरता “IoT जहाँ आप प्रतीक्षा नहीं करते थे। विकास और परीक्षण (भाग 1) “ आने में लंबा नहीं था । इस बार मैं आपको बताऊंगा कि परियोजना की वास्तुकला क्या थी और हमने अपने समाधान का परीक्षण शुरू करते समय किस तरह की रेक बनाई थी।

अस्वीकरण: एक भी कचरा बिन मुश्किल नहीं मारा ~~गया था~~ ।

प्रोजेक्ट आर्किटेक्चर

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

IoT प्रोजेक्ट में काफ्का बहुत ठंडा रहा। RabbitMQ जैसी अन्य प्रणालियों की तुलना में, काफ्का के कई फायदे हैं:

धाराओं के साथ कार्य करें : सेंसर से कच्चे डेटा को एक धारा प्राप्त करने के लिए संसाधित किया जा सकता है। और धाराओं के साथ, आप लचीले ढंग से कॉन्फ़िगर कर सकते हैं कि आप उनमें क्या फ़िल्टर करना चाहते हैं, और स्ट्रीमिंग करना आसान है (नए डेटा स्ट्रीम बनाएं)
: Kafka , , , . - , - , . , Kafka , . , , , .

Backend

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

सबसे पहले, हम डॉकटर में आवश्यक कंटेनर बढ़ाते हैं, एप्लिकेशन लॉन्च करते हैं और वास्तविक उदाहरण पर हम पहले से ही परीक्षण डेटा चला रहे हैं।

वास्तव में हम यह कैसे करते हैं, इस बारे में मैंने विस्तार से बात करते हुए हाइजेनबग 2019 पाइटर पर रिपोर्ट में कहा है "माइक्रोसर्वस वॉरस: ज्यूनीट एपिसोड 5 - टेस्टकंटेनर्स स्ट्राइक्स बैक":

आइए एक छोटा उदाहरण देखें कि यह कैसा दिखता है। निचले स्तर की सेवा उपकरणों से डेटा लेती है और इसे काफ्का में फेंक देती है। और व्यावसायिक भाग से हीट मैप सेवा कफका से डेटा लेती है और एक हीट मैप का निर्माण करती है।

आइए हीट मैप सेवा के साथ डेटा प्राप्त करने का परीक्षण करें (काफ्का के माध्यम से)

@KafkaTestContainer
@SpringBootTest
class KafkaIntegrationTest {

    @Autowired
    private KafkaTemplate kafkaTemplate;

    @Test
    void sendTest() {
        kafkaTemplate.send(TOPIC_NAME, MEASSAGE_BODY)

        //     
        //       
        //  
    }
}

हम एक नियमित एकीकरण स्प्रिंगबूट परीक्षण लिख रहे हैं, हालांकि, यह परीक्षण पर्यावरण विन्यास की एनोटेशन-आधारित शैली में भिन्न है। एनोटेशन है @KafkaTestContainerकाफ्का को बढ़ाने के लिए की जरूरत है। इसका उपयोग करने के लिए, आपको पुस्तकालय कनेक्ट करने की आवश्यकता है:

वसंत-परीक्षण-कफ़्का

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

यह सब एक सामान्य काफ्का उदाहरण पर होता है, कोई एम्बेडेड विकल्प नहीं, लेकिन केवल संस्करण जो उत्पादन में घूमता है।

हीट मैप सेवा भंडारण के रूप में MongoDB का उपयोग करती है, और MongoDB के लिए परीक्षण समान दिखता है:

@MongoDbDataTest
class SensorDataRecordServiceTest {

    @Autowired
    private SensorDataRecordRepository repository;

    @Test
    @MongoDataSet(value ="sensor_data.json")
    void findSingle() {
        var log = repository.findAllByDeviceId("001");
        assertThat(log).hasSize(1);
        ...
    }
}

एनोटेशन @MongoDbDataTestने काकोका के समान डॉकटर में मोंगोबडी को लॉन्च किया। एप्लिकेशन लॉन्च होने के बाद, हम MongoDB के साथ काम करने के लिए रिपॉजिटरी का उपयोग कर सकते हैं।

अपने परीक्षणों में इस कार्यक्षमता का उपयोग करने के लिए, आपको बस लाइब्रेरी से जुड़ने की आवश्यकता है:

स्प्रिंग-टेस्ट-मोंगो

वैसे, वहाँ कई अन्य उपयोगिताएँ हैं, उदाहरण के लिए, आप परीक्षण को निष्पादित करने से पहले डेटाबेस को डेटाबेस में लोड कर सकते हैं, @MongoDataSetजैसा कि ऊपर दिए गए उदाहरण में है, या एनोटेशन का उपयोग करते हुए, @ExpectedMongoDataSetसत्यापित करें कि डेटाबेस में परीक्षण के मामले को पूरा करने के बाद, सटीक डेटा सेट जो हम उम्मीद करते हैं, दिखाई दिया है।

मैं आपको Heisenbug 2020 Piter पर परीक्षण डेटा के साथ काम करने के बारे में अधिक बताऊंगा , जो 15-18 जून को ऑनलाइन आयोजित किया जाएगा।

IoT- विशिष्ट चीजों का परीक्षण

यदि व्यवसाय का हिस्सा एक विशिष्ट बैकेंड है, तो उपकरणों से डेटा के साथ काम करना हार्डवेयर से संबंधित बहुत सारी रेक और बारीकियों को समाहित करता है।

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

हमने सोचा था कि इनपुट एक द्विआधारी प्रारूप होगा, और डिवाइस ने हमें कुछ एक्सएमएल फ़ाइल फेंकना शुरू कर दिया। और इतने कठिन रूप में, IoT प्रोजेक्ट के लिए पहला नियम पैदा हुआ:

प्रलेखन पर कभी विश्वास मत करो!

सिद्धांत रूप में, डिवाइस से प्राप्त डेटा कम या ज्यादा स्पष्ट था: Time- यह समय टिकट है, DevEUI- डिवाइस की पहचानकर्ता, LrrLATऔर LrrLON- निर्देशांक।

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

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

अब हमने उस नक्शे पर देखा, जहाँ कार्डबोर्ड बॉक्स खड़े थे, और हम जानते थे कि डेवलपर कहाँ यात्रा कर रहा था (स्पॉइलर: वर्क-होम, और शुक्रवार की शाम को किसी ने बार को रद्द नहीं किया था)।

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

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

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

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

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

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

कुछ बिंदु पर, एक नया फर्मवेयर हमारे पास आया (क्या आपको याद है कि हम इसके लिए इंतजार कर रहे थे?)। हमने इसे सेंसर पर रोल किया, और सेंसर के साथ संचार प्रोटोकॉल फिर से टूट गया। अलविदा XML, और लंबे समय तक फिर से द्विआधारी प्रारूप रहते हैं। मैं इस समय आशा करना चाहूंगा कि अब यह प्रलेखन से मेल खाती है, लेकिन ... नहीं!

इसलिए, दूसरा नियम: पहला नियम पढ़ें। वह है - प्रलेखन पर कभी भरोसा न करना।

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

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

इसने विकास के संदर्भ में बहुत मदद की, क्योंकि अगर निचले स्तर पर टूट गया, तो हमने चुपचाप व्यापारिक सेवाओं को देखा, क्योंकि अनुबंध उनमें कठोरता से तय किया गया है। इसलिए, IoT परियोजनाओं को विकसित करने के लिए यह दूसरा नियम सेवाओं को अलग करने और अनुबंधों का उपयोग करने के लिए है।

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

तीसरे भाग में मैं एक सिमुलेशन मॉडल के बारे में बात करूंगा, जो बने रहेंगे!

आईओटी जहां आपने इंतजार नहीं किया। विकास और परीक्षण (भाग 2)

प्रोजेक्ट आर्किटेक्चर

Backend

IoT- विशिष्ट चीजों का परीक्षण

More articles: