उत्पादन उपकरणों की निगरानी: रूस में यह कैसा चल रहा है?

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

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

वास्तव में, इसका मतलब है कि आपको साइट पर नियमित रूप से एक इंजीनियर भेजने की आवश्यकता है। जैसा कि हमारे अभ्यास से पता चलता है, 30 से 80% यात्राएँ अनावश्यक होती हैं। पहला मामला - दूर से पता लगाना संभव होगा कि क्या हुआ। या ऑपरेटर से कुछ बटन दबाने के लिए कहें और सब कुछ काम करेगा। दूसरा मामला "ग्रे" योजनाओं का है। यह तब होता है जब एक इंजीनियर बाहर जाता है, प्रतिस्थापन या जटिल काम का कार्यक्रम तय करता है, और फिर कारखाने के किसी व्यक्ति के साथ मुआवजे को आधा-आधा बांट देता है। या फिर वह बस अपनी मालकिन के साथ अपनी छुट्टियों का आनंद लेता है (वास्तविक मामला) और इसलिए अक्सर बाहर जाना पसंद करता है। पौधे को कोई आपत्ति नहीं है.

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

हम दूरस्थ निगरानी के बिना क्यों नहीं कर सकते?

यह बहुत महंगा है. एक इंजीनियर के लिए व्यावसायिक यात्रा - कम से कम 50 हजार रूबल (हवाई जहाज, होटल, आवास, दैनिक भत्ता)। साथ ही, ब्रेकअप करना हमेशा संभव नहीं होता है और अलग-अलग शहरों में एक ही व्यक्ति की आवश्यकता हो सकती है।

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

खैर, डिवाइस अभी भी लॉग लिखते हैं, है ना? समस्या क्या है?

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

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

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

सामान्य तौर पर, कुछ बिंदु पर भुना हुआ मुर्गा अभी भी काटता है, और संशोधन का समय आता है।

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

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

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

बाजार का स्थान

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

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

परिणामस्वरूप, हम निर्माता के डिवाइस से सभी डेटा एकत्र कर सकते हैं, इसे सर्वर पर स्टोरेज में संग्रहीत कर सकते हैं और वहां अलर्ट के साथ एक मॉनिटरिंग पैनल इकट्ठा कर सकते हैं।

यह इस तरह दिखता है (यहां ग्राहक ने उद्यम का एक विज़ुअलाइज़ेशन भी बनाया है, यह इंटरफ़ेस में कई घंटे हैं):

और उपकरण से ग्राफ़ हैं:

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

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

सारांश

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

आइए कुछ उदाहरण दें कि यह व्यवहार में क्या देता है।

1. यह मुख्य रूप से खुदरा श्रृंखलाओं में उपयोग किए जाने वाले औद्योगिक प्रशीतन उपकरण का एक वैश्विक निर्माता है। कंपनी की 10% आय उसके उत्पादों की सर्विसिंग के लिए सेवाएं प्रदान करने से आती है। सेवाओं की लागत को कम करना और आम तौर पर आपूर्ति को सामान्य रूप से बढ़ाने का अवसर देना आवश्यक है, क्योंकि यदि हम अधिक बेचते हैं, तो मौजूदा सेवा प्रणाली सामना नहीं करेगी। हम सीधे एकल सेवा केंद्र के प्लेटफ़ॉर्म से जुड़े, इस विशेष ग्राहक की ज़रूरतों के लिए कुछ मॉड्यूल संशोधित किए, और इस तथ्य के कारण यात्रा व्यय में 35% की कमी प्राप्त की कि सेवा जानकारी तक पहुंच से कारणों की पहचान करना संभव हो जाता है सेवा इंजीनियर के दौरे की आवश्यकता के बिना विफलता का। लंबी अवधि में डेटा का विश्लेषण - तकनीकी स्थिति की भविष्यवाणी करें और, यदि आवश्यक हो, तो स्थिति-आधारित रखरखाव शीघ्रता से करें। एक बोनस के रूप में, अनुरोधों पर प्रतिक्रिया की गति बढ़ गई है: कम फ़ील्ड यात्राएं होती हैं, और इंजीनियर तेजी से काम पूरा करने में सक्षम होते हैं।
2. मैकेनिकल इंजीनियरिंग कंपनी, रूसी संघ और सीआईएस के कई शहरों में उपयोग किए जाने वाले इलेक्ट्रिक वाहनों की निर्माता। हर किसी की तरह, वे लागत कम करना चाहते हैं और साथ ही तकनीकी कर्मचारियों को समय पर सूचित करने के लिए शहर के ट्रॉलीबस और ट्राम बेड़े की तकनीकी स्थिति की भविष्यवाणी करना चाहते हैं। हमने रोलिंग स्टॉक से एकल स्थिति केंद्र तक तकनीकी डेटा एकत्र करने और प्रसारित करने के लिए एल्गोरिदम को जोड़ा और बनाया (एल्गोरिदम सीधे ड्राइव नियंत्रण प्रणाली में बनाए जाते हैं और CAN बस डेटा के साथ काम करते हैं)। तकनीकी स्थिति डेटा तक दूरस्थ पहुंच, जिसमें "ऑसिलोस्कोप" मोड में बदलते मापदंडों (गति, वोल्टेज, पुनर्प्राप्त ऊर्जा का स्थानांतरण, आदि) तक वास्तविक समय की पहुंच शामिल है, ने दूरस्थ फर्मवेयर अपडेट तक पहुंच प्रदान की। इसका परिणाम यात्रा लागत में 50% की कमी है: सेवा जानकारी तक सीधी पहुंच सेवा इंजीनियर की आवश्यकता के बिना विफलता के कारणों की पहचान करना संभव बनाती है, और लंबे समय के अंतराल पर डेटा का विश्लेषण आपको भविष्यवाणी करने की अनुमति देता है तकनीकी स्थिति और, यदि आवश्यक हो, आपातकालीन स्थितियों के वस्तुनिष्ठ विश्लेषण सहित, जल्दी से "स्थिति-आधारित" रखरखाव करें। ग्राहक की आवश्यकताओं के अनुसार और समय पर विस्तारित जीवन चक्र अनुबंधों का कार्यान्वयन। ऑपरेटर की तकनीकी विशिष्टताओं की आवश्यकताओं का अनुपालन, साथ ही उसे उपभोक्ता सेवा की विशेषताओं (एयर कंडीशनिंग की गुणवत्ता, त्वरण/ब्रेकिंग, आदि) की निगरानी के संदर्भ में नए अवसर प्रदान करना।
3. तीसरा उदाहरण नगर पालिका का है। हमें बिजली बचाने और नागरिकों की सुरक्षा में सुधार करने की जरूरत है। हमने कनेक्टेड स्ट्रीट लाइटिंग पर डेटा की निगरानी, ​​प्रबंधन और संग्रह करने, संपूर्ण सार्वजनिक प्रकाश व्यवस्था के बुनियादी ढांचे को दूरस्थ रूप से प्रबंधित करने और इसे एक ही नियंत्रण कक्ष से सर्विस करने, निम्नलिखित कार्यों के समाधान प्रदान करने के लिए एक ही मंच से जोड़ा है। विशेषताएं: दूर से, व्यक्तिगत रूप से या समूहों में रोशनी कम करना या चालू/बंद करना, अधिक कुशल रखरखाव योजना के लिए प्रकाश बिंदुओं में विफलताओं की शहर सेवाओं को स्वचालित रूप से सूचित करना, वास्तविक समय ऊर्जा खपत डेटा प्रदान करना, सड़क प्रकाश व्यवस्था की निगरानी और सुधार के लिए शक्तिशाली विश्लेषणात्मक उपकरण प्रदान करना बिग डेटा पर आधारित प्रणाली, यातायात, एयर कंडीशन, अन्य स्मार्ट सिटी उपप्रणालियों के साथ एकीकरण पर डेटा प्रदान करती है। परिणाम - स्ट्रीट लाइटिंग के लिए ऊर्जा की खपत को 80% तक कम करना, बुद्धिमान प्रकाश नियंत्रण एल्गोरिदम के उपयोग के माध्यम से निवासियों के लिए सुरक्षा बढ़ाना (एक व्यक्ति सड़क पर चल रहा है - उसके लिए प्रकाश चालू करें, क्रॉसिंग पर एक व्यक्ति - उज्ज्वल चालू करें) प्रकाश व्यवस्था ताकि उसे दूर से देखा जा सके), शहर के लिए अतिरिक्त सेवाएं प्रदान करना (इलेक्ट्रिक वाहनों को चार्ज करना, विज्ञापन सामग्री प्रदान करना, वीडियो निगरानी इत्यादि)।

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

अगली पोस्ट में मैं एक कार्यान्वयन के उदाहरण का उपयोग करके दिखाऊंगा कि आपूर्तिकर्ता की ओर से यह कैसा दिखता है।

स्रोत: www.habr.com