स्थिती निरीक्षण म्हणजे एक प्रारूप, खरेदी नव्हे

स्थिती निरीक्षण हा शब्द कंपन-विश्लेषण विक्रेते आणि IoT प्लॅटफॉर्मनी इतका काळ आपलासा केला आहे की तो आता हार्डवेअरचा एक प्रकार वाटतो. देखभाल टीमसाठी, तो त्याहून सोपा आणि अधिक टिकाऊ असतो: मालमत्तेचे प्रमुख पॅरामीटर काळानुसार काय करत आहेत हे नोंदवण्याची, चांगले व वाईट कसे दिसते हे ठरवण्याची, आणि रीडिंग एखादी रेषा ओलांडते तेव्हा कृती करण्याची एक संरचित पद्धत.

ती व्याख्या महत्त्वाची आहे कारण ती तुम्ही कुठून सुरुवात करता हे बदलते. जर स्थिती निरीक्षण म्हणजे हार्डवेअर असेल, तर प्रकल्प खरेदी व नियंत्रण-समाकलकाने सुरू होतो. जर स्थिती निरीक्षण म्हणजे एक प्रारूप असेल, तर प्रकल्प तुम्ही आजच उत्तर देऊ शकता अशा प्रश्नाने सुरू होतो: कोणत्या मालमत्तांवरील कोणते पॅरामीटर सरकले तर आम्हाला सर्वाधिक इजा करणारे बिघाड घडतील? तुमचे तंत्रज्ञ फेरीवर आधीच घेत असलेल्या रीडिंगसह त्यांचे निरीक्षण तुम्ही याच आठवड्यात सुरू करू शकता.

हार्डवेअर ही वाया गेलेली महत्त्वाकांक्षा नाही. ते दुसरे पाऊल आहे. एकदा प्रारूप जागी आले आणि लोकांचा त्यावर विश्वास बसला, की रीडिंग आपोआप पाठवण्यासाठी गेटवे जोडणे हा एक छोटा बदल असतो, नवी प्रणाली नव्हे.

पॅरामीटर आणि मर्यादांपासून सुरुवात करा

निरीक्षित पॅरामीटर हे स्थिती निरीक्षणाचे मूलभूत एकक असते. प्रत्येक एका मालमत्तेशी बांधलेला असतो आणि चार गोष्टी बाळगतो: तो ज्या एककात मोजला जातो ते, इशारा मर्यादा, गंभीर मर्यादा, आणि प्रत्येक मर्यादा ओलांडल्यावर व्हावी ती कृती. एवढाच संपूर्ण करार आहे, आणि उपयुक्त होण्यासाठी तो पुरेसा आहे.

बिघाड घडून गेल्यानंतर केवळ त्याला दुजोरा देणाऱ्या पॅरामीटरऐवजी, जिथे कल बिघाडाच्या आधी येतो असे पॅरामीटर निवडा:

  • बेअरिंग किंवा मोटर तापमान, जिथे संथ चढ अनेकदा यांत्रिक बिघाडाच्या काही दिवस आधी येतो.
  • हायड्रॉलिक किंवा लाइन दाब, जिथे सरकाव गळती, झिजलेला पंप किंवा तुंबलेला फिल्टर सूचित करतो.
  • भट्टी किंवा प्रक्रिया तापमान, जिथे भरकटणे मालमत्ता व उत्पादन या दोन्हींना धोका निर्माण करते.
  • वंगण पातळी किंवा प्रवाह, जिथे शांत घसरण जाम झालेल्या घटकात संपते.

मर्यादा ठरवणे हे संभाषण आहे, विज्ञान-प्रकल्प नव्हे. उत्पादकाच्या श्रेणीपासून आणि शेवटच्या बिघाडापूर्वी रीडिंग कशी दिसत होती याच्या तुमच्या स्वतःच्या वाईट आठवणींपासून सुरुवात करा. मर्यादा कायमस्वरूपी नसतात; मुद्दा असा की एक बचाव करता येण्याजोगी पहिली रेषा जागी आणणे, म्हणजे प्रणालीकडे तुलना करण्यासाठी काहीतरी असेल.

काम जिथे आधीच होते तिथेच रीडिंग टिपा

स्थिती निरीक्षण कार्यक्रम रखडण्याचे कारण क्वचितच विश्लेषण असते. ते असते डेटा टिपणे. जर रीडिंग नोंदवणे म्हणजे कार्यालयात परत जाऊन स्प्रेडशीट उघडणे असेल, तर पहिल्याच व्यस्त आठवड्यात रीडिंग थांबतात. प्रारूप तेव्हाच टिकते जेव्हा टिपणे तंत्रज्ञ आधीच करत असलेल्या कामाच्या आतच बसते.

दोन टिपण-मार्ग एकाच केवळ-जोडणी रीडिंग नोंदवहीत भर घालतात. फेरीवरील तंत्रज्ञ मालमत्तेजवळ फोनवर रीडिंग नोंदवतो, जसे तो चेकलिस्ट पूर्ण करतो त्याच पद्धतीने. किंवा PLC, SCADA किंवा IoT गेटवे टोकन-प्रमाणित इन्जेस्ट API मार्गे रीडिंग आपोआप पाठवतो. दोन्ही एकाच अपरिवर्तनीय कालमालिकेत उतरत असल्याने, तुम्ही आधी मॅन्युअल रीडिंग डिजिटल करू शकता आणि केवळ ज्या मालमत्तांवर सलग डेटा समाकलनाचे समर्थन करतो त्यांचेच स्वयंचलन करू शकता. गेटवे आल्यावर काहीही पुन्हा बांधावे लागत नाही.

केवळ-जोडणी नोंदवही ही नीटनेटकेपणापेक्षा अधिकसाठी महत्त्वाची असते. जेव्हा एखादे रीडिंग नादुरुस्ती-तपासणीत किंवा ऑडिटमध्ये पुरावा बनते, तेव्हा ते त्याच वेळी नोंदले गेले आणि नंतर संपादित केले नाही हे स्पष्ट असावे लागते.

नोंदताक्षणी वर्गीकरण करा, मग कृती करा

नोंदवही आणि निरीक्षण प्रणाली यांतील फरक म्हणजे रीडिंग नोंदल्याच्या क्षणी काय होते. प्रत्येक रीडिंग त्याच्या मर्यादांच्या तुलनेत तत्काळ सामान्य, इशारा किंवा गंभीर असे वर्गीकृत व्हावे, आणि त्या वर्गीकरणाने कोणी अहवाल पाहण्याची वाट न पाहता एक कृती घडवावी.

इशारा त्या मालमत्तेच्या व्याप्तीतील वापरकर्त्यांना सूचित करतो, म्हणजे एखादा माणूस काम नियोजित करायचे का ते ठरवू शकतो. गंभीर रीडिंगला खरी घटना मानले जाते: ती आपोआप एक नादुरुस्ती उघडू शकते, म्हणजे प्रतिसाद पुढच्या फेरीला नव्हे तर आताच सुरू होतो. टीमला बुडवण्याचे टाळण्यासाठी, एकाच पॅरामीटरवरील पुनरावृत्त गंभीर रीडिंग प्रत्येक रीडिंगला नवी उघडण्याऐवजी एकाच उघड्या नादुरुस्तीत एकत्र व्हावीत.

विश्वास मिळवणारा हाच तो फेरा आहे. यंत्र अडचणीत आहे हे कोणाच्या लक्षात येण्यापूर्वीच जेव्हा पहिल्यांदा एखादे गंभीर रीडिंग योग्य नादुरुस्ती उघडते, तेव्हा स्थिती निरीक्षण हे अनुपालनाचे कंटाळवाणे काम न राहता सकाळच्या बैठकीत सर्वप्रथम पाहिली जाणारी गोष्ट बनते.

रीडिंगचे भविष्यवेधी संकेतात रूपांतर करा

रीडिंगचा इतिहास गोळा करण्यासारखा तेव्हाच असतो जेव्हा तो तुम्ही पुढे काय करता ते बदलतो. मालमत्ता-दृश्याने कल एका दृष्टिक्षेपात स्पष्ट करावा: एक आरोग्य-फलक, प्रत्येक पॅरामीटरसाठी स्पार्कलाइन व अलीकडील आकडेवारीसह एक कार्ड, आणि इशारा व गंभीर रेषांच्या तुलनेत रीडिंग रेखाटणारा, मर्यादा-उल्लंघने चिन्हांकित केलेला अधिक सविस्तर उंबरठा-पट्टा आलेख.

दोन साधित संकेत बहुतांश भविष्यवेधी काम करतात. मर्यादेपर्यंतच्या सरकावाचा अंदाज सध्याचा कल कायम राहिल्यास पॅरामीटर आपली मर्यादा केव्हा गाठेल याचा अंदाज लावतो, ज्यामुळे अस्पष्ट काळजीचे नियोजनयोग्य तारखेत रूपांतर होते. शिळ्या-सेन्सरचा शोध अहवाल देणे थांबवलेले पॅरामीटर चिन्हांकित करतो, कारण सर्वांचा विश्वास असलेला जो निरीक्षक गुपचूप शांत झाला तो अजिबात निरीक्षक नसण्यापेक्षा अधिक धोकादायक असतो.

फ्लीट स्तरावर, तोच डेटा आत्ता लक्ष हवे असलेल्या मालमत्तांना क्रमांक देतो आणि शिळे झालेले सेन्सर समोर आणतो, त्यामुळे विश्वासार्हता प्रमुख मालमत्ता एकेक करून उघडण्याऐवजी एकाच स्क्रीनवरून संपूर्ण प्लांटची प्राथमिकता ठरवू शकतो.

याची परिणती कशात होते

अशा प्रकारे केलेले स्थिती निरीक्षण स्वतःच मूल्यवान असते: कमी अनपेक्षित बिघाड, स्वतःच उघडणाऱ्या नादुरुस्ती, आणि तुम्ही लक्ष ठेवत होता हे दाखवणारी देखभाल नोंद. ते तुम्हाला एक स्वच्छ, विश्वासार्ह रीडिंग इतिहासही देते — प्रारूप-आधारित अंदाज उंबरठ्यावर आहे असे आश्वासन नव्हे, तर तुम्ही नंतर जोडू इच्छिता अशा कोणत्याही अधिक जड स्थिती-आधारित विश्लेषणाची पूर्वअट.

म्हणून क्रम हाच मुद्दा आहे. महत्त्वाच्या पॅरामीटरवर मर्यादा घाला, काम जिथे होते तिथेच रीडिंग टिपा, नोंदताक्षणी कृती करा, आणि स्वयंचलन व अंदाज कुठे फायदेशीर ठरतील हे डेटालाच सांगू द्या. शेवटी तुमच्याकडे एकही PLC न काढता उभारलेला, तुमचा विश्वास असलेला स्थिती-निरीक्षण कणा उरतो.