PulseMQ क्या है
एक प्लेटफ़ॉर्म जो आपके कंट्रोल्स और आपके ERP के बीच की पूरी ज़मीन संभालता है: यह मशीनों पर नज़र रखता है, जो बना उसे रिकॉर्ड करता है, किसी चीज़ पर ध्यान देने की ज़रूरत हो तो लोगों को बताता है, और वह काग़ज़ी रिकॉर्ड रखता है जो इसे साबित करता है।
पढ़ता है, टकराता कभी नहीं
प्रोसेस की कमान आपके PLC और HMI के हाथ में ही रहती है। वे जो publish करते हैं, PulseMQ उसे subscribe करता है, और वापस सिर्फ़ वहीं लिखता है जहाँ आपने साफ़ तौर पर उसे जोड़ा हो — recipe download, job command, acknowledgement।
काम चलाता है
Recipe, batch, job, work order, मटीरियल लॉट, मेंटेनेंस और क्वालिटी रिकॉर्ड यहीं रहते हैं — उस मशीन से जुड़े जिसने उन्हें बनाया, और उस shift से जिसमें वे चले।
ऊपर तक रिपोर्ट करता है
Shift और batch रिपोर्ट, OEE हिस्ट्री, जीनियोलॉजी, ERP postings और exports उन लोगों और सिस्टम तक पहुँचते हैं जो कभी फ़्लोर पर नहीं आते।
यह किसके लिए है
| व्यक्ति | उनकी स्क्रीन | उन्हें इससे क्या मिलता है |
|---|---|---|
| Operator | Operator Station | चालू batch या job, स्कैन करने वाले मटीरियल, phase की प्रगति, और वे commands जो उनकी मशीन स्वीकार करती है। |
| टेक्नीशियन | Tasks (टैबलेट) | उनकी अपनी PM queue, procedure, फ़ोटो, ज़रूरी lockout डॉक्यूमेंट, और signature की जगह। |
| सुपरवाइज़र | Multi-Machine Overview | हर मशीन की स्थिति एक नज़र में, लाइव OEE, alarm, और अब तक के shift के आँकड़े। |
| इंजीनियर | Machine Configuration | Tag, signal mapping, OEE baseline, alarm, states और ISA-88 / ISA-106 वायरिंग। |
| क्वालिटी | Quality Management | Hold, टेस्ट रिज़ल्ट, सीरियल, grade spec और material test report। |
| प्लांट मैनेजर | Historical Analytics | Trend, नुकसान, bottleneck, और मशीनों, shifts व operators के बीच तुलना। |
| एडमिनिस्ट्रेटर | System Administration | यूज़र, रोल, लोकेशन, alarm और नोटिफ़िकेशन पॉलिसी, शेड्यूल की गई रिपोर्ट। |
PulseMQ को क्या अलग बनाता है
इस प्लेटफ़ॉर्म का ज़्यादातर हिस्सा वह बुनियादी काम है जो हर MES में होना चाहिए — बस ठीक से किया गया। ये दस वे बातें हैं जो ग्राहक कहते हैं कि उन्हें कहीं और नहीं मिलीं — और इनमें से हर एक इसलिए है क्योंकि किसी प्लांट को दूसरे तरीक़े से नुकसान उठाना पड़ा था।
MES आपका PLC tag structure लिखता है
Point-and-click mapping हर MES प्रोजेक्ट का वह हिस्सा है जो समय और बजट से आगे निकल जाता है। PulseMQ इसे उलट देता है: मशीन कॉन्फ़िगर करें, फिर वह tag structure डाउनलोड करें जिसकी मशीन को ज़रूरत है — Rockwell L5X के रूप में जिसे आप सीधे Studio 5000 में import करते हैं, Ignition UDT के रूप में, या एक सादी CSV tag list के रूप में। ISA-88 recipe structures भी इसी तरह export होते हैं। आपका controls engineer नामों की spreadsheet के बजाय एक generated contract के हिसाब से काम करता है, और दोनों तरफ़ पहली बार में ही मेल खा जाता है।
सेक्शन 17 · IoT bridge को भी यही मिलता है
मटीरियल स्टेशन से बँधता है, स्क्रीन से नहीं
पहले मशीन पर लगा position label स्कैन करें, फिर मटीरियल। प्लेटफ़ॉर्म दोनों को जोड़ देता है, ताकि लॉट उसी port के सामने दर्ज हो जिसमें वह असल में लोड किया गया — न कि उस slot के सामने जो उस वक़्त स्क्रीन पर highlight था। जो गलती genealogy को बिगाड़ देती है, उसे डिज़ाइन से ही ख़त्म कर दिया गया है।
सेक्शन 09
हर command की रसीद वापस आती है
किसी ने start दबा दिया, सिर्फ़ इससे job "शुरू" नहीं हो जाता। PulseMQ एक sequence number भेजता है, controller उसे वापस echo करता है, और तभी job कन्फ़र्म होता है — start time के रूप में मशीन के अपने timestamp के साथ। Timeout के भीतर acknowledgement न आए तो job फ़्लैग होता है और retry बटन दिखता है। कोई command चुपचाप फ़ेल नहीं हो सकता।
सेक्शन 08
Counter reset को कभी प्रोडक्शन नहीं गिना जाता
Output boundaries सिर्फ़ बढ़ोतरी (increment) पर ट्रिगर होती हैं। जब power cycle से roll counter 50 से 6 पर आ जाता है, तो ज़्यादातर सिस्टम 6 रोल दर्ज कर देते हैं। PulseMQ कुछ भी दर्ज नहीं करता, क्योंकि असल में यही हुआ था।
सेक्शन 08
Offline और idle अलग-अलग जवाब हैं
जिस मशीन ने बात करना बंद कर दिया है, वह धीमी चल रही मशीन नहीं है। PulseMQ यह फ़र्क़ हर जगह दिखाता है, ताकि बंद पड़ा gateway कभी चुपचाप एक अच्छी shift जैसा न दिखे।
सेक्शन 03 और 06
टैबलेट नेटवर्क के बारे में सच बताता है
PM form का हर जवाब उसी on-device queue से होकर जाता है, चाहे आप online हों या नहीं, और जब तक server उसे कन्फ़र्म न करे तब तक Queued दिखता है। कोई आशावादी "saved" नहीं, जो टेक्नीशियन के basement से बाहर आने पर झूठ निकले।
सेक्शन 10
इतिहास बाद में दोबारा नहीं लिखा जा सकता
Dispatch की गई recipe dispatch के समय ही फ़्रीज़ हो जाती है; पूरा हुआ form उसी template revision से बँध जाता है जिस पर काम किया गया; signature append-only होता है — उसे सिर्फ़ supersede किया जा सकता है, कभी edit नहीं। आज के master को edit करने से वह नहीं बदल सकता जो कल का रिकॉर्ड कहता है कि किया गया था।
सेक्शन 08, 10 और 19
सही मशीन के लिए सही डॉक्यूमेंट, हर बार
PM template एक तरह का डॉक्यूमेंट माँगता है — जैसे lockout procedure — और मशीन अपना मौजूदा revision देती है। अगर वह मौजूद नहीं है, तो dispatch रोक दिया जाता है और बताया जाता है कि क्या कमी है — बजाय इसके कि टेक्नीशियन किसी दूसरी मशीन की procedure लेकर जाए। भरोसेमंद दिखने वाला ग़लत जवाब, कोई जवाब न होने से भी बुरा माना जाता है।
सेक्शन 10
मशीन की अपनी स्क्रीन, बिना भारी bandwidth के
Controller की पूरी on-device application को frame करने के बजाय, PulseMQ उसका declarative manifest एक बार लाता है और सिर्फ़ लाइव वैल्यू stream करता है — हर update में लगभग दो सौ गुना कम डेटा, और इसी वजह से लाइव process mimic प्लांट के mobile uplink पर भी इस्तेमाल लायक़ रहता है। सच का स्रोत डिवाइस ही रहता है; dashboard सिर्फ़ उसे दिखाता है।
सेक्शन 14
चालू स्विच, पूरा होने का दिखावा नहीं कर सकता
हर feature card दो बातें दिखाता है: वह चालू है या नहीं, और उसके पीछे का configuration सच में पूरा है या नहीं। Config writes हमेशा merge होते हैं, कभी replace नहीं — इसके साथ मिलकर, आधा-अधूरा setup ख़ुद सामने आ जाता है, बजाय भरोसे से भरे पर ख़ाली dashboards दिखाने के।
सेक्शन 02 और 17
फ़ीचर सेट
PulseMQ एक बार में एक मशीन पर चालू होता है। नीचे दी गई हर क्षमता उस मशीन के Features टैब पर एक card है: उसे चालू करें, और उसका अपना configuration टैब दिखने लगता है। जो आप इस्तेमाल नहीं करते, वह किसी के रास्ते में नहीं आता।
OEE मॉनिटरिंग
प्रोडक्शन metrics, shift targets और analytics के साथ Overall Equipment Effectiveness ट्रैक करें। इसमें availability, performance और quality की गणना शामिल है।
OEE और Metrics टैब पर कॉन्फ़िगर होता है · सेक्शन 05
मेंटेनेंस ट्रैकिंग
काउंटर-आधारित या समय-आधारित शेड्यूल के साथ मेंटेनेंस tasks ट्रैक करें। सर्विस हिस्ट्री देखें, counters reset करें और alerts कॉन्फ़िगर करें।
Maintenance टैब पर कॉन्फ़िगर होता है · सेक्शन 10
एन्हांस्ड मेंटेनेंस
सभी मशीनों का मेंटेनेंस एक ही जगह से शेड्यूल करें। Overview पेज से सभी मशीनों के अनुमान (predictions) देखें, tasks की प्राथमिकता तय करें और assignments संभालें। Schedule, Parts Inventory, Task Templates और PM Forms को एक ही स्क्रीन पर लाता है — अलग Parts टैब इसी में शामिल हो जाता है।
Overview पेज से संभाला जाता है · सेक्शन 10
अलार्म नोटिफ़िकेशन
Alarm detection, severity levels और यूज़र्स तक notification routing कॉन्फ़िगर करें। मशीन की समस्याओं के लिए real-time alerts सेट करें।
Alarms टैब पर कॉन्फ़िगर होता है · सेक्शन 07
सस्टेनेबिलिटी ट्रैकिंग
ऊर्जा दक्षता, पानी का उपयोग, कचरे में कमी और carbon footprint ट्रैक करें। इससे Environmental टैब चालू होता है, जहाँ आप मशीन द्वारा publish किए गए meters को map करते हैं, और environmental widgets भी, जो उन्हें लाइव दिखाते हैं। अपने आप ESG rollups और scoring अभी विकास में हैं — सेक्शन 13 यह सीमा साफ़ बताता है।
Environmental टैब पर कॉन्फ़िगर होता है · सेक्शन 13
रिपोर्ट और एनालिटिक्स
OEE metrics, मेंटेनेंस सारांश और trend analysis के साथ मशीन परफ़ॉर्मेंस की शेड्यूल्ड रिपोर्ट बनाएँ। ईमेल डिलीवरी और प्राप्तकर्ता कॉन्फ़िगर करें।
Reports टैब पर कॉन्फ़िगर होता है · सेक्शन 11
ISA-88 Equipment Modules
ISA-88 / IEC 61512 hierarchy के साथ equipment modules कॉन्फ़िगर करें। PackML states (18-state मॉडल) ट्रैक करें, batch tracking और hierarchical OEE गणना चालू करें।
Equipment Modules, Batch Tracking और Queue टैब · सेक्शन 08
ISA-88 Hybrid Mode
वही toggle, जो continuous मशीन पर इस नाम से दिखता है: continuous line में batch tracking जोड़ता है, और Equipment Modules, Batches और Queue टैब चालू करता है। Hybrid mode चालू रहने तक ISA-106 फ़ीचर उपलब्ध नहीं होते।
सिर्फ़ continuous मशीनें · सेक्शन 08
मटीरियल ट्रैकिंग और जीनियोलॉजी
कच्चे माल के इनपुट (bill of materials), असल बनाम टारगेट मात्रा, हर batch की खपत, और parent-child genealogy रिकॉर्ड ट्रैक करें। Recall, quality जाँच और regulatory compliance (FDA, ISO, IATF) के लिए ज़रूरी। इसमें MES-नियंत्रित label printing शामिल है।
ISA-88 चालू होने पर दिखता है · सेक्शन 09
Job ट्रैकिंग
Start और stop, output गिनती और प्रगति की निगरानी के साथ production jobs ट्रैक करें। ISA-88 batch या ISA-106 continuous process की जटिलता के बिना ISA-95 मानक job infrastructure का उपयोग करता है। सरल job workflows वाली discrete parts मशीनों के लिए आदर्श।
ISA-88 के बिना Parts मशीनें · सेक्शन 08
ISA-106 Continuous Process
State tracking, मटीरियल genealogy, job boundaries, production context, ISA-95 PLC interface (UDT mapping और handshake) और work order मैनेजमेंट।
ISA-106 टैब पर कॉन्फ़िगर होता है · सेक्शन 08
ERP इंटीग्रेशन
ERP सिस्टम के साथ दोतरफ़ा डेटा एक्सचेंज: production orders import करें, completions export करें, material masters sync करें, receipts post करें और non-conformances बनाएँ। Auto-sync के साथ Epicor Kinetic REST API v2 सपोर्ट करता है। Grade specs, holds, test results, tube serials और MTR बनाने के लिए Quality टैब चालू करता है।
ISA-106 टैब → Work Order → ERP Integration · सेक्शन 12
AI असिस्टेंट
सरल अंग्रेज़ी में सवाल पूछें और commands दें — मशीन का status देखें, work orders dispatch करें, schedules देखें, downtime की जाँच करें। AWS Bedrock पर Claude से चलता है, हर मशीन के लिए budget controls के साथ। उपयोग ट्रैक होता है और हर महीने की सीमा तय होती है।
मशीन पेज से खुलता है · सेक्शन 15
डायग्नॉस्टिक्स / HMI एम्बेड
एक Diagnostics / HMI टैब जोड़ता है जो इस मशीन के on-device controller से लाइव AlarmIQ diagnostics और playback — और चाहें तो Bridge HMI भी — frame करता है। सच का स्रोत डिवाइस ही रहता है; dashboard सिर्फ़ उसे दिखाता है।
Gateway enrolment ज़रूरी है · सेक्शन 14
किसी मशीन में कौन-से फ़ीचर हो सकते हैं
मशीन का production mode एक ही बार, उसे बनाते समय, सेट होता है, और वही तय करता है कि कौन-सा execution model उपलब्ध होगा। बाक़ी फ़ीचर हर मशीन के लिए उपलब्ध हैं।
| प्रोडक्शन mode | उपलब्ध execution फ़ीचर | नियम |
|---|---|---|
| Parts | ISA-88 Equipment Modules, या Job Tracking | ISA-88 बंद होने पर Job Tracking उपलब्ध होता है — discrete मशीनों के लिए सरल रास्ता। |
| Continuous | ISA-106 Continuous Process, या ISA-88 Hybrid Mode | दोनों में से एक ही। Hybrid mode continuous line में batch tracking लाता है, और उसके चालू रहने तक ISA-106 फ़ीचर बंद रहते हैं। |
| Hybrid | लाइव availability के साथ ISA-88 Equipment Modules | Availability PLC से आती है; performance और quality batch पूरा होने पर तय होती हैं। |
| कोई भी mode | OEE मॉनिटरिंग · मेंटेनेंस ट्रैकिंग · एन्हांस्ड मेंटेनेंस · अलार्म नोटिफ़िकेशन · सस्टेनेबिलिटी ट्रैकिंग · रिपोर्ट और एनालिटिक्स · ERP इंटीग्रेशन · AI असिस्टेंट · डायग्नॉस्टिक्स / HMI एम्बेड | हर एक अलग से चालू होता है, किसी भी combination में। |
भाग एक — हर मशीन के साथ शामिल
मशीन कनेक्ट करते ही, कोई भी फ़ीचर चालू किए बिना, आपको यह सब मिलता है। बाकी पूरे कैटलॉग को इसी आधार पर परखा जाता है।
लाइव फ़्लोर मॉनिटरिंग
वे स्क्रीन जिन्हें लोग पूरे दिन खुला रखते हैं। बिल्डिंग की हर मशीन का state, rate, output और alarm — मशीन में बदलाव होते ही अपडेट, refresh बटन दबाने पर नहीं।
आप क्या देख रहे हैं
पूरा प्लांट एक पेज पर
हर मशीन एक कार्ड के रूप में या एक घनी टेबल में — आपकी पसंद, जो हर यूज़र के लिए याद रखी जाती है। लोकेशन के हिसाब से फ़िल्टर करें, refresh की अवधि तय करें, या ज़रूरत पड़ने पर refresh करें।
State, rate, output, alarm
मौजूदा स्टेटस उसी लेबल के साथ जो आपका प्लांट असल में इस्तेमाल करता है, लाइव OEE, चालू job या batch, मौजूदा process values, और उस मशीन पर खड़ा कोई भी alarm।
एक मशीन, पूरे विवरण के साथ
कॉन्फ़िगर किया जा सकने वाला widget dashboard, साथ में OEE, alarm, मेंटेनेंस काउंटर और job हिस्ट्री के टैब — वह व्यू जो इंजीनियर तब खोलता है जब कुछ गड़बड़ दिखे।
तापमान, स्पीड, प्रेशर
किसी भी मशीन की कोई भी कॉन्फ़िगर की गई process value, आपके चुने हुए समय-अंतराल पर एक साथ चार्ट में — zoom, pan और ऐसे legend के साथ जो सोर्स सिग्नल का नाम बताता है।
मशीन कहाँ है
एरिया और cell के हिसाब से मशीनों का प्लांट-फ़्लोर व्यू, ताकि नया सुपरवाइज़र भी वह मशीन ढूँढ सके जिसके बारे में alarm बता रहा है।
बताया जाता है, ख़ुद खोजना नहीं पड़ता
स्क्रीन पर सूचना तब, जब कोई डिवाइस pair हो, कोई मटीरियल स्कैन हो, कोई batch पूरा हो या कोई command फ़ेल हो — वहीं दिखाई जाती है जहाँ व्यक्ति पहले से देख रहा है।
इसे अपने हिसाब से ढालें
- कॉन्फ़िगर करने योग्य widget
- हर मशीन का dashboard widgets से बनता है — OEE सारांश, process value कार्ड, चालू job, availability टाइमलाइन, alarm सूची, मेंटेनेंस काउंटर — जिन्हें हर मशीन के लिए अलग से सजाकर सेव किया जाता है।
- स्टेटस आपके तरीक़े से
- मशीन का state एक boolean tag से आ सकता है (उलटे लॉजिक के साथ, अगर PLC की वायरिंग वैसी है) या एक multi-state word से — हर वैल्यू को अपना लेबल, रंग और running या stopped का अर्थ दिया जाता है।
- लाइट और डार्क
- कंट्रोल रूम और नाइट शिफ़्ट के लिए डार्क थीम, ऑफ़िस के लिए लाइट थीम — हर यूज़र अपनी चुनता है।
- ऐप की तरह इंस्टॉल होता है
- Dashboard टैबलेट या panel PC की होम स्क्रीन पर इंस्टॉल होता है और ब्राउज़र के बटन-बार के बिना फ़ुल-स्क्रीन खुलता है।
Downtime और availability
हर stop सीधे मशीन से पकड़ा जाता है और सेकंड तक मापा जाता है। उसके बाद का सवाल — क्यों — वहीं प्लेटफ़ॉर्म इंसान से पूछता है।
Stop को पकड़ना
- Stop की अपने आप पहचान
- State में बदलाव होते ही दर्ज होते हैं और एक टाइमलाइन के रूप में रखे जाते हैं। किसी stop को रिकॉर्ड करने के लिए किसी को उसे नोटिस करने की ज़रूरत नहीं।
- State की शब्दावली
- मशीन की हर state वैल्यू को ऐसा नाम दिया जाता है जिसे आपका प्लांट पहचानता है, साथ में रंग, कैटेगरी और यह कि वह running गिनी जाए या नहीं — ताकि "Ready" और "Starved" को एक साथ "not running" में न डाला जाए।
Stop की वजह बताना
- Planned बनाम unplanned
- Downtime कैटेगरी के हिसाब से बाँटा जाता है, ताकि changeover और शेड्यूल्ड मेंटेनेंस availability को उस तरह न घटाएँ जैसे कोई breakdown घटाता है।
- Downtime विश्लेषण
- किसी तारीख़-अवधि, मशीनों के समूह या shift में stops को अवधि और बारंबारता के हिसाब से क्रम में — वह Pareto जो बताता है कि किस सुधार पर पैसा लगाना है।
- कारण की कोडिंग
- ऑपरेटर के सामने एक prompt, जिससे वह stop को आपकी अपनी reason-code सूची के अनुसार वर्गीकृत करे — ताकि रिकॉर्ड में सिर्फ़ अवधि नहीं, कारण भी हो। रोलआउट जारी है — सेक्शन 22 देखें।
- Offline बनाम stopped
- जो मशीन बात करना बंद कर चुकी है, उसे offline दिखाया जाता है — उस मशीन से अलग जो मौजूद है और idle है। यह फ़र्क़ मायने रखता है और प्लेटफ़ॉर्म इसे कभी धुंधला नहीं करता।
भाग दो — वे फ़ीचर जो आप चुनते हैं
दस प्रविष्टियाँ, जो मशीन के Features टैब के तेरह स्विच को कवर करती हैं। हर एक बताती है कि वह क्या करती है, आपको क्या देना होगा, और वह कहाँ फ़िट होती है — ताकि आप अपनी योजना के अनुकूल फ़ीचर लें और बाकी छोड़ दें।
OEE मॉनिटरिंग
प्रोडक्शन परफ़ॉर्मेंस की मॉनिटरिंग: Overall Equipment Effectiveness, साथ में प्रोडक्शन मेट्रिक्स, shift टारगेट और analytics — मशीन के सिग्नलों से लगातार कैलकुलेट किया गया, shift के अंत में clipboard से दोबारा जोड़-तोड़ करके नहीं।
तीन फ़ैक्टर
Availability
Planned समय के मुक़ाबले running समय, मशीन के अपने state सिग्नल और उसके downtime रिकॉर्ड से बना — उन stops समेत जिन्हें किसी ने लिखा ही नहीं।
Performance
अभी जो चल रहा है उसके ideal rate के मुक़ाबले असल rate — discrete parts के लिए cycle time, continuous प्रोडक्ट के लिए line speed।
Quality
कुल output के मुक़ाबले अच्छा output — reject और defect काउंटर से, या batch processes में रन के बाद के disposition से।
तीन प्रोडक्शन मोड, मापने के तीन तरीक़े
| मोड | आम मशीनें | तीनों फ़ैक्टर कैसे निकाले जाते हैं |
|---|---|---|
| Parts | प्रेस, असेंबली cell, CNC | PLC से counts और cycle time। तीनों फ़ैक्टर लाइव कैलकुलेट होते हैं। |
| Continuous | एक्सट्रूडर, वाइंडर, कोटर | PLC से लंबाई, वज़न और line speed। तीनों फ़ैक्टर लाइव कैलकुलेट होते हैं। |
| Hybrid | Discrete output वाले batch उपकरण | Availability PLC से लाइव; performance और quality तब तय होती हैं जब batch पूरा हो जाए और उसका disposition हो जाए। |
टारगेट तय करना
- टारगेट और baseline
- Ideal cycle time, ideal line speed, हर shift का टारगेट output, मानक shift अवधि और हर फ़ैक्टर का टारगेट प्रतिशत — हर एक या तो फ़िक्स्ड वैल्यू के रूप में सेट होता है, या PLC tag से लाइव पढ़ा जाता है जब प्रोडक्ट के साथ टारगेट बदलता है।
स्क्रीन पर
- OEE Dashboard
- हर मशीन के लिए एक अलग स्क्रीन: मुख्य आँकड़ा, तीनों फ़ैक्टर, टारगेट बनाम असल, और उसके पीछे का ट्रेंड।
- KPI पट्टी
- ज़रूरी आँकड़ों का एक छोटा बैनर, लाइन के ऊपर लगे वॉल डिस्प्ले के आकार का।
- फ़ैक्टर spider chart
- Availability, performance और quality एक ही radar पर टारगेट के मुक़ाबले — यह देखने का सबसे तेज़ तरीक़ा कि कौन-सा हिस्सा कम पड़ रहा है।
- Availability टाइमलाइन
- पूरी shift में state बदलावों की एक चलती पट्टी, ताकि चालीस मिनट का गैप ऐसी चीज़ हो जिस पर आप उँगली रख सकें, अंदाज़ा न लगाना पड़े।
- Hierarchical OEE
- ISA-88 equipment modules चालू होने पर OEE मशीन पर रुकने के बजाय equipment hierarchy में ऊपर तक जुड़ता है।
समय के साथ
- Shift डेटा का संग्रह
- हर shift की सीमा पर उस shift का OEE और उसके घटक आँकड़े, downtime, running समय और counts अपने आप हिस्ट्री में लिखे जाते हैं — आपके shift कैलेंडर और टाइम ज़ोन के अनुसार।
- Loss waterfall
- Planned समय, loss की हर कैटेगरी से घटते-घटते, उस अच्छे प्रोडक्ट तक जो असल में बाहर आया — वह चार्ट जिससे सुधार की बातचीत शुरू होती है।
- OEE heatmap
- एक अक्ष पर मशीनें, दूसरे पर दिन या shift — ताकि हर सोमवार रात दोहराने वाला पैटर्न किसी औसत के अंदर छिपा न रहे।
कंट्रोलर से एक state सिग्नल और एक count, लंबाई या वज़न का सिग्नल, साथ में उस मशीन पर चलने वाले प्रोडक्ट का ideal rate। कोई नया हार्डवेयर नहीं।
मापने की परत। इस गाइड का हर दूसरा आँकड़ा — downtime, job की प्रगति, shift रिपोर्ट — इन्हीं तीन फ़ैक्टर के मुक़ाबले बताया जाता है, इसलिए ज़्यादातर प्लांट सबसे पहले इसे ही चालू करते हैं।
Alarm नोटिफ़िकेशन
Alarm की पहचान, severity स्तर और यूज़र्स तक नोटिफ़िकेशन की routing। समस्या को तब पकड़ें जब वह अभी छोटी हो, और उसे उस एक व्यक्ति के सामने रखें जो उसके बारे में कुछ कर सकता है — ऐसे मेलबॉक्स में नहीं जिसे सब अनदेखा करते हैं।
पूरा चक्र, शुरू से अंत तक
Alarm कॉन्फ़िगरेशन
किसी भी सिग्नल पर alarm बनाएँ: threshold, range, equality, या कई tags को जोड़ने वाली कोई condition। उसे severity, संदेश और routing नियम दें। पूरा सेट CSV के रूप में import और export करें।
हर अपडेट पर जाँच
डेटा आते ही conditions जाँची जाती हैं, bitfields में पैक किए गए alarm words समेत — ताकि alarm उसी संदेश पर उठे जिसने उसे पैदा किया।
लोगों तक पहुँचाया जाता है
Alarms को व्यक्तियों, roles या लोकेशन को सौंपें — ऐसे शेड्यूल पर जो जानता है कि shift पर कौन है, और कोई जवाब न दे तो escalation के साथ।
Acknowledge और रिकॉर्ड
Dashboard से acknowledge या dismiss करें; हर raise, वैल्यू और clear अपनी trigger और resolve वैल्यू के साथ हिस्ट्री में रखा जाता है।
अभी क्या खड़ा है
- Active alarm व्यू
- हर मशीन के खड़े alarms, severity के हिसाब से रंग-कोड किए हुए, उस वैल्यू के साथ जिसने उन्हें ट्रिगर किया और यह कि वे कितनी देर से खड़े हैं।
- Alarm हिस्ट्री
- हर alarm event का खोजने योग्य रिकॉर्ड, अवधि, मशीन और समाधान के साथ — reliability analysis का स्रोत।
पैटर्न ढूँढना
- Alarm analytics (विश्लेषण)
- Alarm और मशीन के हिसाब से बारंबारता, समय के साथ घटनाएँ, और एक bubble व्यू जो तौलता है कि alarm कितनी बार बजता है और कितनी देर खड़ा रहता है। Nuisance alarms असली alarms से अपने आप अलग दिखने लगते हैं।
- Stale alarm की सफ़ाई
- जब कोई मशीन alarm के बीच offline हो जाती है, तो खुले alarms को हमेशा के लिए खड़ा छोड़ने के बजाय दोबारा जाँचा जाता है।
सही व्यक्ति तक पहुँचना
- नोटिफ़िकेशन शेड्यूल
- Shift को ध्यान में रखने वाली routing: रात का alarm रात वाले संपर्क तक जाता है।
- भरोसा करने से पहले टेस्ट करें
- कॉन्फ़िगरेशन स्क्रीन से जानबूझकर एक alarm चलाएँ और पूरा रास्ता साबित करें — condition, routing, delivery — उस पर निर्भर होने से पहले।
- सहायक उपकरणों के alarms
- Edge पर मॉनिटर किए जाने वाले सहायक उपकरणों — आरी, पंप, dust collection — के alarms मशीन alarms की उसी सूची में दिखते हैं।
देखने लायक tags और हर व्यक्ति का एक ईमेल पता। मौजूदा PLC alarm words, पैक किए गए bitfields समेत, जैसे हैं वैसे ही इस्तेमाल हो सकते हैं।
ध्यान की परत। यह OEE वाली ही readings पर चलता है, इसलिए एक alarm और उससे हुआ downtime एक ही event हैं — दो अलग रिकॉर्ड नहीं जिन्हें मिलाना पड़े।
प्रोडक्शन execution
सभी प्लांट एक ही तरीक़े से चीज़ें नहीं बनाते, इसलिए PulseMQ में तीन execution फ़ीचर हैं और हर मशीन वह इस्तेमाल करती है जो उससे मेल खाता है — और तीनों के ऊपर ISA-95 work orders रहते हैं।
ISA-88 Equipment Modules
Equipment hierarchy और PackML states। उन processes के लिए जो recipe के अनुसार तय मात्रा बनाती हैं: recipe MES की होती है और MES उसे उपकरण तक डाउनलोड करता है। Continuous मशीन पर यही toggle ISA-88 Hybrid Mode के रूप में मिलता है।
- इक्विपमेंट hierarchy
- ISA-88 / IEC 61512 hierarchy के अनुसार कॉन्फ़िगर किए गए equipment modules, हर एक के अपने सिग्नल और मटीरियल ट्रैकिंग के साथ, और tree में ऊपर तक कैलकुलेट होने वाला hierarchical OEE।
- PackML state ट्रैकिंग
- उपकरण से वापस पढ़ा गया पूरा 18-state PackML मॉडल, हर मशीन और हर phase के लिए।
- Master recipes
- Version वाली recipes — phases, parameters, मटीरियल की ज़रूरतें, अपेक्षित outputs और जुड़ी मेंटेनेंस ज़रूरतों के साथ। नाम, कोड या प्रोडक्ट से खोजी जा सकती हैं।
- Recipe का lifecycle
- Draft, review, approved, active, obsolete — एक status हिस्ट्री के साथ जो दर्ज करती है कि किसने और कब उसे आगे बढ़ाया।
- Approval के हस्ताक्षर
- Recipe approval और मटीरियल disposition के लिए electronic signature ज़रूरी किया जा सकता है: एक घोषित अर्थ, साइन करते समय साइन करने वाले का पासवर्ड दोबारा सत्यापित, रिकॉर्ड पर एक अटूट hash chain, और बनाने वाले व्यक्ति व approve करने वाले व्यक्ति के बीच अलगाव।
- Import और export
- Recipes साइटों और सिस्टमों के बीच JSON के रूप में जाती हैं। नई recipe की शुरुआत के लिए किसी मौजूदा recipe की कॉपी बनाएँ।
- मशीन तक dispatch
- Recipe, मशीन और parameters चुनें; dispatch के समय control recipe फ़्रीज़ हो जाती है, इसलिए master में बाद का बदलाव हिस्ट्री को दोबारा नहीं लिख सकता। Batch से पहले की मेंटेनेंस जाँची जाती है, और supervisor override दर्ज होता है।
- Batch queue
- हर मशीन के queued, ready, running, held, completed और aborted batches — शेड्यूलिंग, प्राथमिकता और अपने अलग queue टैब के साथ।
- मटीरियल interlock
- ज़रूरी मटीरियल सत्यापित होने तक उपकरण रुका रह सकता है। ऑपरेटर स्कैन करता है, प्लेटफ़ॉर्म recipe से मिलान करके पुष्टि करता है, और उसके बाद ही cleared flag वापस लिखा जाता है।
- Quality checks और events
- Batch के दौरान के quality नतीजे और events batch record के साथ दर्ज होते हैं।
- Disposition
- पूरा होने पर accept, reject या rework — जहाँ आपकी process को ज़रूरत हो, वहाँ signature के साथ।
- इक्विपमेंट arbitration
- जब दो batches एक ही साझा equipment module चाहते हैं, तो टकराने के बजाय requests साफ़ तौर पर queue, grant और release की जाती हैं।
- Archive और restore
- पूरे हुए batches आपके शेड्यूल पर लंबी अवधि के स्टोरेज में जाते हैं और audit के लिए बिना बदलाव वापस लाए जा सकते हैं।
- Batch विश्लेषण
- Batches में phase की अवधि, मटीरियल की खपत और yield — किन्हीं भी दो या अधिक की साथ-साथ तुलना, और एक bottleneck सारांश जो बताता है कि कौन-सा phase आपको सबसे महँगा पड़ रहा है।
ISA-106 Continuous Process
Continuous process का पूरा समर्थन: state ट्रैकिंग, मटीरियल genealogy, job boundaries, प्रोडक्शन context, ISA-95 PLC interface और work order मैनेजमेंट। Recipe PLC की होती है; PulseMQ देखता है, दर्ज करता है और मिलान करता है।
- Jobs
- Job एक continuous run है जिसका एक टारगेट और कई outputs होते हैं। इसे हाथ से बनाएँ, work order से dispatch करें, या लाइन को बनाने दें — autonomous मोड में लाइन के प्रोडक्शन शुरू करते ही job अपने आप खुल जाता है।
- प्रोडक्शन context
- Recipe, प्रोडक्ट, lot, order और roll identifiers PLC या HMI से पढ़े जाते हैं, बदलने पर log होते हैं और job से जोड़े जाते हैं — ताकि लाइन असल में जिस पर सेट थी, वही दर्ज हो।
- Procedural states (प्रक्रिया की अवस्थाएँ)
- Idle, startup, threading, ramp, normal, transition, wash, shutdown और fault — आपके अपने state word से मैप किए गए, और मशीन के मुख्य स्टेटस के रूप में इस्तेमाल होने लायक।
- Job की सीमाएँ (boundaries)
- Roll change, cut या index को काउंटर के बढ़ने (increment) से पहचाना जाता है — और सिर्फ़ increment से, ताकि काउंटर को reset करने वाले power cycle को कभी प्रोडक्शन न समझा जाए। हर output अपनी लंबाई, वज़न, defect count और उस समय लाइन की state के साथ दर्ज होता है।
- Output का वर्गीकरण
- Transition के दौरान बना प्रोडक्ट हर output के हिसाब से accept, sort या reject किया जा सकता है, और यह फ़ैसला मटीरियल के साथ inventory तक जाता है।
- प्रोडक्शन logging
- टारगेट के मुक़ाबले असल लंबाई या वज़न, औसत स्पीड और अनुमानित समाप्ति — पूरे run में लगातार अपडेट, और टारगेट पूरा होने पर auto-complete।
- ISA-95 PLC interface
- MES और कंट्रोलर के बीच UDT मैपिंग और handshake — वह संरचित आदान-प्रदान जो नीचे बताया गया है।
- Quality और serialisation
- बनी हुई यूनिटों के लिए serial number बनाना, facility code और default grade के साथ, जो Quality टैब में जाता है।
- Job लेबल
- Label डेटा प्रिंटर तक भेजा जाता है — हर output पर, job के अंत में, किसी मात्रा-सीमा पर, PLC सिग्नल पर, या माँगने पर।
Boundaries सिर्फ़ increment पर ट्रिगर होती हैं। जब power cycle से roll काउंटर 50 से 6 पर आ जाता है, तो एक भोला सिस्टम छह rolls दर्ज कर देता है। PulseMQ कुछ दर्ज नहीं करता — घटना (decrement) reset है, प्रोडक्शन नहीं। यही अनुशासन OEE में जाने वाले हर गिने जाने वाले सिग्नल पर लागू होता है।
Job Tracking
सरल job workflow वाली discrete parts मशीनों के लिए ISA-95 production order ट्रैकिंग — ISA-88 batch या ISA-106 continuous की जटिलता के बिना, मानक job ढाँचा।
- शुरू और बंद
- Job खोलें, चलाएँ, बंद करें। न recipe डाउनलोड, न phase मॉडल।
- Output की गिनती
- Good और reject counts मशीन से पढ़े जाते हैं और job के सामने जोड़े जाते हैं।
- प्रगति की मॉनिटरिंग
- टारगेट के मुक़ाबले मात्रा, बीता हुआ और अनुमानित समय — मशीन कार्ड और job सूची पर।
Work orders और products · ISA-95
- Work order का lifecycle
- Created, scheduled, released, in progress, paused, completed, closed — मात्रा, due date, प्राथमिकता और ग्राहक या ERP order reference शुरू से अंत तक साथ रहते हैं।
- शेड्यूल बोर्ड
- आने वाले काम का कैलेंडर और टाइमलाइन व्यू, मशीनों के बीच drag-and-drop शेड्यूलिंग के साथ।
- जुड़ा हुआ execution
- Work order उन jobs या batches से जुड़ता है जो उसे पूरा करते हैं; प्रगति अपने आप ऊपर जुड़ती है और मात्रा पूरी होने पर order ख़ुद पूरा हो सकता है।
- Operating mode (चलाने का तरीक़ा)
- Autonomous, scheduled, observation, work-order या manual — लाइन पर कितना भरोसा है कि वह ख़ुद काम शुरू करे, यह हर मशीन के लिए तय होता है।
- Product Catalog
- टाइप और स्टेटस वाले products, inputs, outputs और by-products को कवर करने वाला bill of materials, और routing steps। भेजने से पहले dispatch को मटीरियल की उपलब्धता के मुक़ाबले जाँचा जा सकता है।
मशीन handshake
Start time मशीन का होता है, बटन का नहीं। PulseMQ हर command के साथ एक sequence number भेजता है और job को started मानने से पहले इंतज़ार करता है कि कंट्रोलर उसे वापस echo करे। Timeout चूक गया तो job retry के साथ फ़्लैग हो जाता है — ताकि "हमने dispatch किया और कुछ नहीं हुआ" चुपचाप होने वाली बात न रहे।
- रसीद वाले commands
- PLC को भेजे गए हर command में एक sequence number होता है जिसे कंट्रोलर वापस echo करता है। Job की पुष्टि तभी होती है जब मशीन बताए कि उसे मिल गया, और दर्ज start time मशीन का होता है — उस पल का नहीं जब किसी ने क्लिक किया।
- Timeout और retry
- अगर आपके timeout के भीतर कोई acknowledgement नहीं आता, तो job फ़्लैग हो जाता है और retry बटन दिखता है। चुपचाप फ़ेल होना संभावित नतीजों में शामिल नहीं है।
- Job control UDT
- कंट्रोलर में एक संरचित आदान-प्रदान: command, identifiers, टारगेट, units, rates, ऑपरेटर, tool और मटीरियल नीचे जाते हैं; state, counts, प्रगति, cycle time, स्पीड, faults और खपत वापस आते हैं।
- सहायक commands
- मशीन-विशेष बटन — purge, index, reset, tare — हर मशीन के लिए कॉन्फ़िगर किए जाते हैं और दबाने पर PLC तक publish होते हैं; इन्हें दबाने की अनुमति role से नियंत्रित होती है।
Operator Station
मशीन पर
चल रहा batch या job, phase टाइमलाइन, लोड करने वाले मटीरियल उनके स्टेटस के साथ, लाइव स्कैनिंग, और वे commands जो वह मशीन स्वीकार करती है — लाइन के पास लगे panel के आकार में।
स्टोर रूम में
मटीरियल receive करने और lots बंद करने के लिए scanner से चलने वाला स्टेशन — barcode input, GS1-128 parsing और लगातार चलती audit सूची के साथ। कीबोर्ड की ज़रूरत नहीं।
मशीन बनाते समय चुना गया एक प्रोडक्शन मोड, और — अगर आप चाहते हैं कि PulseMQ सिर्फ़ काम देखे नहीं बल्कि dispatch भी करे — कंट्रोलर में एक handshake block। इसके लिए UDT आपके लिए बना दिया जाता है।
काम की परत। यह चलती मशीन को एक दर्ज job, batch या work order में बदलती है, और इसी से मटीरियल, quality और रिपोर्टिंग को किसी ग्राहक के ऑर्डर से जोड़ा जा सकता है।
मटीरियल ट्रैकिंग और genealogy
कच्चे मटीरियल के इनपुट, असली बनाम target मात्रा, हर batch की खपत और parent-child genealogy रिकॉर्ड ट्रैक करें — recall, quality जाँच और regulatory compliance के लिए ज़रूरी। goods-in पर आए pallet से लेकर ट्रक पर चढ़े roll तक, सब कुछ बाद में मिलान करके नहीं, बल्कि मशीन पर ही verify होता है।
दो स्कैन, और लॉट एक भौतिक port से बँध जाता है। पहले position label, फिर मटीरियल। Genealogy अक्सर इसलिए टूटती है कि मटीरियल उस slot पर दर्ज हो गया जो स्क्रीन पर highlight था, न कि उस पर जिसमें वह असल में गया — इसलिए प्लेटफ़ॉर्म यह सही करने की ज़िम्मेदारी ऑपरेटर पर कभी नहीं डालता।
आप जो ख़रीदते हैं, उसे परिभाषित करना
- मटीरियल कैटलॉग
- मटीरियल की परिभाषाएँ — माप की इकाई, GS1 identifiers, और हर मटीरियल कैसे ट्रैक होता है — वज़न, आयतन, लंबाई, गिनती या समय से।
- मटीरियल की सूची (BOM)
- किसी recipe या प्रोडक्ट के लिए अपेक्षित इनपुट, target मात्रा के साथ, जिनकी तुलना असल खपत से होती है।
स्टॉक की प्राप्ति और भंडारण
- माल की प्राप्ति (receiving)
- माल आते ही लॉट बनाएँ — मात्रा, supplier, expiry और barcode के साथ। अगर supplier का label काम का न हो तो अपना label प्रिंट करें।
- लॉट और sublot
- एक लॉट को carriers पर sublots में बाँटा जा सकता है; हर sublot अलग से stage, deliver और consume होता है, अपनी reservations और खपत की मात्रा के साथ।
- लॉट स्टेटस
- Quarantine, released, consumed, expired। जो मटीरियल release नहीं हुआ, वह ग़लती से consume नहीं हो सकता।
मशीन पर
- दो-चरण स्कैनिंग
- ऑपरेटर पहले मशीन पर लगा position label स्कैन करता है, फिर मटीरियल का barcode। प्लेटफ़ॉर्म दोनों को जोड़ता है, ताकि मटीरियल उसी station से बँधे जिसमें वह असल में लोड हुआ — न कि उस slot से जो संयोग से स्क्रीन पर highlight था।
- Barcode पार्सिंग
- GS1-128 और आम vendor formats को मटीरियल, लॉट, sublot, supplier, मात्रा, इकाई और expiry में parse किया जाता है। अलग-अलग suppliers के अलग field नाम आते ही एक जैसे (normalise) कर दिए जाते हैं।
- PLC के साथ verification
- Controller पूछता है, PulseMQ जवाब देता है: क्या यह सही मटीरियल है, सही मात्रा में, released और expiry के भीतर? Pass होने पर बँधा हुआ लॉट मशीन को वापस लिखा जाता है; fail होने पर एक status code लौटता है और लाइन रुकी रहती है।
- Load और close-out
- पहला स्कैन लोड और verify करता है; दूसरा लॉट को close-out करता है और असल खपत की गणना करता है। Rejection साफ़-साफ़ होते हैं और उनके साथ कारण दर्ज होता है।
रन के दौरान
- खपत ट्रैकिंग
- पूरे रन में खपत एक PLC tag के हिसाब से चलती है — running total के रूप में या अलग-अलग कटौतियों के रूप में — और जिस मटीरियल पर instrument नहीं लगा, उसके लिए manual entry उपलब्ध है।
- रन के बीच changeover
- जहाँ आप अनुमति दें, वहाँ batch या job के बीच में लॉट बदला जा सकता है; चाहें तो मशीन से इस बदलाव की पुष्टि (acknowledge) अनिवार्य कर सकते हैं।
रन के बाद
- Genealogy रिकॉर्ड
- इनपुट लॉट उन outputs से जुड़ते हैं जो उनसे बने, और outputs ख़ुद अपने-आप में लॉट बन जाते हैं। किसी तैयार roll से आप उसमें गया हर इनपुट बता सकते हैं; किसी संदिग्ध इनपुट से आप वह सब कुछ बता सकते हैं जिसे उसने छुआ।
- मांग का overview
- आने वाले scheduled batches और jobs को क्या चाहिए होगा, और उसके मुक़ाबले हाथ में क्या है।
- मटीरियल हिस्ट्री
- batch के हिसाब से देखें — एक batch ने जो कुछ consume किया — या मटीरियल के हिसाब से — एक लॉट जहाँ-जहाँ गया।
- MES-नियंत्रित label printing
- Output labels batch के अंत में, हर output पर, किसी threshold पर, PLC signal पर या manually ट्रिगर होते हैं — आपके template और field layout के साथ।
मशीन पर एक barcode scanner, प्रिंट किए हुए position labels, और उस मशीन पर ISA-88 चालू होना। Suppliers के अपने GS1 labels जैसे हैं वैसे ही पढ़े जाते हैं।
ट्रेसेबिलिटी की परत। यह production execution के ऊपर बैठती है: लॉट उस job या batch से बँधा होता है जिसने उसे consume किया — इसी वजह से recall एक लंबी जाँच नहीं, बस एक query बन जाता है।
Maintenance Tracking और Enhanced Maintenance
दो फ़ीचर, जानबूझकर अलग: Maintenance Tracking एक मशीन के counters और schedules पर नज़र रखता है, और Enhanced Maintenance एक ही जगह से हर मशीन की योजना बनाता है। डिजिटल PM forms फ़्लोर पर काम पूरा करवाते हैं।
Maintenance Tracking
मशीन पर ही counter-आधारित या समय-आधारित schedules — service history, counter reset और alerts के साथ।
- मेंटेनेंस काउंटर
- Cycles, घंटे, लंबाई या कोई भी गिनी जाने वाली मात्रा एक setpoint के मुक़ाबले ट्रैक होती है, बची हुई मात्रा के साथ progress bar के रूप में दिखती है, और जिसके पास permission है वह इसे dashboard से reset कर सकता है।
- समय-आधारित schedules
- उस काम के लिए दिनों या हफ़्तों के interval, जो counter से नहीं बल्कि calendar से तय होता है।
- Due और overdue
- जो counters अपने setpoint के क़रीब हैं या उसे पार कर चुके हैं, वे मशीन पर maintenance condition उठाते हैं और किसी भी दूसरे alarm की तरह notification भेज सकते हैं।
- Task टेम्पलेट
- हर मशीन और हर counter के लिए: procedure का टेक्स्ट, ज़रूरी parts, ज़रूरी tools, अनुमानित downtime, और काम किसे जाना चाहिए।
- Batch से पहले की जाँच
- जिस मशीन का maintenance due है, उस पर batch dispatch करने से पहले चेतावनी मिलती है; override संभव है और वह batch के साथ दर्ज होता है।
- सर्विस हिस्ट्री
- हर reset, हर पूरा हुआ task, हर override — मशीन के साथ सुरक्षित।
Enhanced Maintenance
केंद्रीकृत scheduling: Overview पेज पर एक ही जगह से हर मशीन का maintenance प्लान करें। इसे चालू करने पर maintenance एक जगह समेकित हो जाता है — अलग Parts tab इसके बगल में रहने के बजाय इसी स्क्रीन में समा जाता है, ताकि योजना बनाने की दो नहीं, एक ही जगह हो।
| Sub-tab | वहाँ आप क्या करते हैं |
|---|---|
| Schedule | पूरे प्लांट में जो कुछ due होने वाला है — मशीन और status (overdue, scheduled या predicted) के हिसाब से फ़िल्टर, और due date, मशीन या priority के हिसाब से sorted। |
| Parts Inventory | मशीनों और tasks के साथ जुड़े spare parts, ताकि technician के store तक जाने से पहले ही job बता दे कि part शेल्फ़ पर है या नहीं। |
| Task Templates | हर बार-बार होने वाले काम के लिए procedure, parts, tools, अनुमानित downtime और assignee। |
| PM Forms | डिजिटल form की पूरी लाइन — authoring, dispatch और review। यह व्यक्ति के हिसाब से चलता है, इसलिए ऊपर का मशीन फ़िल्टर जानबूझकर नहीं मानता: technician की queue उसकी अपनी है, चाहे वह इसे कहीं से भी खोले। |
- सभी मशीनों पर predictions
- अभी चल रहे counters से अनुमान कि पूरे प्लांट में क्या due होने वाला है, ताकि काम urgent बनने से पहले ही उसे group किया जा सके।
- प्राथमिकता तय करना
- queue को मशीन-दर-मशीन नहीं, बल्कि सभी मशीनों में एक साथ rank करें।
- काम सौंपना (assignment)
- उसी स्क्रीन से, production schedule को देखते हुए, लोगों या टीमों को काम सौंपें।
डिजिटल PM forms
काग़ज़ी preventive-maintenance packet की जगह शुरू से अंत तक डिजिटल: author, publish, dispatch, tablet पर पूरा, review, और PDF रिपोर्ट के रूप में वापस।
/tasks पर खोलते हैं — tablet पर install होने
वाला app। Planners इसी workspace तक Maintenance Management के PM Forms sub-tab से
पहुँचते हैं। यह एक ही workspace है, दो copies नहीं, और दोनों दरवाज़े एक ही permission
जाँचते हैं। इसके लिए Enhanced Maintenance ज़रूरी नहीं: forms की लाइन अपने-आप में काम करती है।
Offline सामान्य रास्ता है, fallback नहीं। हर जवाब उसी on-device queue से गुज़रता है, चाहे tablet में signal हो या न हो, और server की पुष्टि होने तक Queued दिखाता है। Offline code सिर्फ़ उसी दिन नहीं चलता जिस दिन ज़रूरत हो, बल्कि रोज़ चलता है — और जो काम device से निकला ही नहीं, उसके लिए technician को कभी "saved" नहीं दिखाया जाता।
टेम्पलेट बिल्डर
Checks, readings, comments, फ़ोटो और ज़रूरी documents वाले sections और items। Technician को ठीक जो दिखेगा, उसका preview देखें।
आपकी मौजूदा PDF से
जो form आप पहले से इस्तेमाल करते हैं, उसे import करें। पेज पर किसी फ़ोटो या हिस्से के चारों ओर box खींचकर उसे किसी item से जोड़ें, ताकि नया form वैसा ही दिखे जैसा आपके technicians पहचानते हैं। अगर आप हमारे बनाए form से शुरू करना चाहें, तो एक खाली authoring template भी मिलता है।
Versions जो बदलते नहीं
Draft को खुलकर edit किया जा सकता है; published revision freeze हो जाता है। पूरे हुए forms उसी exact version से pin रहते हैं जिस पर काम हुआ था, इसलिए बाद का कोई revision किसी रिकॉर्ड को कभी दोबारा नहीं लिख सकता। किसी revision को retire करके उसकी history मिटाए बिना उसे चलन से बाहर करें।
नामित technician को
किसी व्यक्ति और मशीन को assign करें। बाद में trail खोए बिना reassign या cancel करें।
Tablet queue, पहले offline
Install होने वाला app, जो सिर्फ़ उसी technician का काम दिखाता है। हर जवाब device पर queue होता है और server की पुष्टि तक Queued दिखता है — इसलिए बिना signal वाली जगह से कोई नुक़सान नहीं, और जो saved नहीं है वह कभी saved नहीं दिखता।
फ़ोटो और signatures
किसी भी item के साथ फ़ोटो लें, और स्क्रीन पर ही sign करें। Signatures रिकॉर्ड के अंदर रखे जाते हैं, उसके बगल में अलग फ़ाइल नहीं होते।
मशीन-विशेष documents
Template किसी तरह का document माँगता है — जैसे lockout procedure — और मशीन अपनी copy देती है, हमेशा current revision। अगर ज़रूरी document फ़ाइल में नहीं है, तो dispatch मना हो जाता है और बताया जाता है कि क्या कम है; technician के रिकॉर्ड में ठीक-ठीक दर्ज होता है कि उसे कौन-सा revision दिखाया गया था।
Submit, जाँच, स्वीकार
अधूरे submissions मना हो जाते हैं और छूटे हुए items form पर चिह्नित होते हैं। Reviewer comments के साथ accept या reject करता है; reject हुआ form दोबारा submit करने के लिए वापस जाता है।
पूरी रिपोर्ट
Pinned template के आधार पर stored रिकॉर्ड से बनी PDF: fail हुए checks उनके comments के साथ, findings का सारांश, दिखाया गया safety revision, signatures, review का नतीजा, और हर पेज पर content hash। Document vault में अपने-आप फ़ाइल होती है।
दस्तावेज़ लाइब्रेरी
हर मशीन के manuals, procedures, drawings और पूरी हुई रिपोर्टें, पूरी revision history के साथ। नया revision upload करें; हर पुराना revision वापस निकाला जा सकता है।
सुझाए गए विवरण
जब आप checklist के साथ कोई reference document import करते हैं, तो प्लेटफ़ॉर्म हर row के लिए विवरण सुझा सकता है। यह सिर्फ़ सुझाव देता है — author जो स्वीकार करना है उसे tick करता है, और उसके बिना कुछ नहीं लिखा जाता।
Check के बगल में procedure
Technician documents के बीच पन्ने पलटने के बजाय reference फ़ोटो या पेज को checklist item के बगल में खुला रखता है।
हर काम के लिए एक counter या calendar interval। PM forms के लिए इसके अलावा हर technician को एक tablet चाहिए — कोई भी browser चलेगा — और आपके मौजूदा काग़ज़ी forms, जिन्हें PDF के रूप में import किया जा सकता है।
रखरखाव की परत। Maintenance Tracking एक मशीन के counters पर नज़र रखता है; Enhanced Maintenance पूरे प्लांट की योजना बनाता है और Parts Inventory, Task Templates और PM Forms को एक स्क्रीन पर लाता है।
रिपोर्ट्स और एनालिटिक्स
OEE metrics, maintenance सारांश और trend analysis वाली scheduled मशीन performance रिपोर्टें, ईमेल से — और उनके पीछे का interactive analytics भी। प्लेटफ़ॉर्म जो कुछ भी रिकॉर्ड करता है, उस पर बाद में query की जा सकती है, और स्क्रीन पर दिखने वाली हर चीज़ फ़ाइल के रूप में बाहर ले जाई जा सकती है।
आप सवाल कैसे पूछते हैं
एक ठोस सवाल पूछें
Date range, कई मशीनों का चयन, location और shift — घंटे, shift, दिन या हफ़्ते के हिसाब से grouping, और line, bar या area chart में से अपनी पसंद।
एक-दूसरे के मुक़ाबले
मशीन बनाम मशीन, shift बनाम shift, ऑपरेटर बनाम ऑपरेटर, batch बनाम batch — दो अलग exports में नहीं, बल्कि साथ-साथ।
कारण खोजें
Loss waterfalls, downtime Pareto, phase Gantt charts, bottleneck सारांश और defect breakdowns — जो बताते हैं कि समय कहाँ गया।
अपने-आप
Template से बनी scheduled रिपोर्टें — रोज़, हफ़्ते या महीने में तैयार, distribution list को ईमेल, और archive में सुरक्षित।
Charts
- सारांश cards
- मौजूदा चयन के मुख्य आँकड़े, किसी भी chart को देखने से पहले।
- OEE trend और heatmap
- समय के साथ तीनों factors, और मशीन-बनाम-अवधि का grid जो वे patterns सामने लाता है जिन्हें औसत छिपा देता है।
- Cycle time का ट्रेंड
- एक रन या एक हफ़्ते में cycle time का drift — शुरुआती संकेत कि कुछ mechanical बदल रहा है।
- Quality और defects
- मशीन, प्रोडक्ट और अवधि के हिसाब से defect की गिनती और categories।
- Job हिस्ट्री
- पूरे हुए jobs — targets, actuals, speeds, outputs और अवधि के साथ — और रन के दौरान job में हुए हर बदलाव की timeline।
- Batch का performance
- हर batch के phase timings, मटीरियल खपत और quality नतीजे, कई batches में तुलना और bottleneck analysis के साथ।
- Alarm विश्लेषण
- मशीन और अवधि के हिसाब से alarm की frequency और duration, साथ में bubble view जो nuisance alarms को महँगे alarms से अलग करता है।
- मशीन hierarchy व्यू
- Performance को मशीन से cell और cell से area तक ऊपर जोड़ें, या प्लांट के आँकड़े से नीचे उसके पीछे के asset तक drill करें।
प्लेटफ़ॉर्म से बाहर
- एक्सपोर्ट
- Historical और batch डेटा CSV में; batch और job रिपोर्टें PDF में; recipes, alarm और tag configuration JSON या CSV में; QR labels प्रिंट होने वाली sheets में।
एक distribution list और एक schedule। जो कुछ रिपोर्ट होता है वह पहले से रिकॉर्ड हो रहा है, इसलिए कुछ नया इकट्ठा नहीं किया जाता।
रिपोर्टिंग की परत। यह वह history पढ़ती है जो दूसरे फ़ीचर लिखते हैं, इसीलिए आप जितने ज़्यादा फ़ीचर चालू करते हैं, यह उतनी बेहतर होती है।
ERP इंटीग्रेशन और Quality
आपके ERP के साथ दोतरफ़ा डेटा exchange — और उसके साथ Quality Management tab। ERP Integration चालू करने से दोनों चालू हो जाते हैं।
डेटा का आदान-प्रदान
Orders आते हैं
ERP से production orders import करें और material masters sync करें, ताकि आपके ऑपरेटर जो schedule देखें वही हो जिसका वादा business ने किया है।
Completions वापस post होते हैं
Completions export करें, receipts post करें और non-conformances बनाएँ — shop floor का नतीजा दोबारा टाइप किए बिना business system तक पहुँचता है।
Epicor Kinetic REST API v2
आपके तय interval पर auto-sync वाला direct connector। SAP, Oracle और दूसरे systems उसी order-import और completion-export interface से जुड़ते हैं।
Quality Management
मशीन पेज पर एक Quality tab, जिसमें holds, tests, serials, grade specs और material test reports शामिल हैं।
Quality Management
- Quality Holds
- मटीरियल या output पर hold लगाएँ और हटाएँ; status tab पर ट्रैक और गिना जाता है, ताकि hold पर रखी कोई चीज़ चुपचाप ship न हो जाए।
- Test Results
- प्रोडक्ट के साथ test के नतीजे दर्ज करें; pending tests बाक़ी काम के रूप में सामने दिखते हैं।
- Tube Serials
- हर बनी यूनिट के लिए serial number, मशीन पर configure किए गए facility code और default grade से बनता है, और genealogy के ज़रिए पीछे तक trace किया जा सकता है।
- Grade Specs
- हर grade को जो specification पूरा करना है, वह reference के रूप में रखा जाता है जिससे test results को परखा जाता है।
- MTR Reports
- दर्ज नतीजों और serials से बनी material test reports — वह certificate जो प्रोडक्ट के साथ जाता है।
- Non-conformances
- PulseMQ में दर्ज होकर ERP में post होते हैं, ताकि एक quality event दो systems में एक ही रिकॉर्ड रहे, न कि दो रिकॉर्ड जो आपस में मेल न खाएँ।
एक ERP endpoint और credentials। Epicor Kinetic के लिए direct connector साथ आता है; SAP, Oracle और दूसरे उसी order-import और completion-export interface से जुड़ते हैं।
बिज़नेस की परत, और Quality Management का दरवाज़ा। Orders ERP से आते हैं, completions और non-conformances वापस post होते हैं, ताकि shop floor का नतीजा दोबारा टाइप किए बिना business system तक पहुँचे।
Sustainability ट्रैकिंग
ESG rollups पर काम जारी हैपर्यावरणीय performance की monitoring। Environmental tab पर कोई meter map करें — power, flow, temperature, humidity — और वह प्लेटफ़ॉर्म के किसी भी दूसरे signal की तरह व्यवहार करता है: dashboard पर लाइव, trends chart पर, और history में। लंबी अवधि की ESG परत, जो इन readings को scores और अवधि-वार रिपोर्टों में जोड़ती है, अभी बन रही है।
दो हिस्से, अलग-अलग चरणों में। Map किए गए environmental signal की लाइव monitoring आज काम करती है। अपने-आप होने वाला ESG aggregation — हर shift और हर अवधि के rollups, sustainability scoring, और उन पर बने reporting views — अभी development में है। अगर आपकी कोई compliance reporting बाध्यता है, तो उसके हिसाब से योजना बनाने से पहले timing के बारे में हमसे बात करें।
आज उपलब्ध
- Environmental टैब
- मशीन जो environmental signals publish करती है — power, flow, temperature, humidity आदि — उन्हें display names, units और visibility के साथ configure करें, ठीक वैसे ही जैसे किसी भी process metric को।
- बिजली (power) मॉनिटरिंग
- Power consumption widget मशीन का map किया गया energy signal पढ़ता है और समय के साथ उसका chart बनाता है, साथ में peak-window analysis, जिससे बिजली का बिल बढ़ाने वाले demand spikes पकड़े जा सकें।
- Environmental विजेट
- Water usage, waste reduction और carbon footprint widgets वही signal दिखाते हैं जो आप उनसे जोड़ें, target और capacity thresholds के साथ — इसलिए जो साइट पहले से पानी को meter करती है, वह उसे अभी dashboard पर ला सकती है।
- Trends और history
- Environmental signals, Trends tab पर production values के साथ chart होते हैं और मशीन की बाक़ी history के साथ सुरक्षित रहते हैं।
Development में
- ऑटोमैटिक rollups
- Energy, पानी और waste का हर shift और हर अवधि का aggregation, एक रिपोर्ट करने योग्य रिकॉर्ड के रूप में — न कि सिर्फ़ एक लाइव reading जिसे आप देखते रहें।
- Sustainability स्कोरिंग
- संयुक्त ESG score और उसका dashboard।
- Carbon की गणना
- Energy consumption से emissions। जब यह आएगा, तो conversion factor आप ख़ुद तय करेंगे और auditor के सामने उसका बचाव कर सकेंगे।
ऐसी metering जो reading publish करे — energy, flow या ऐसा ही कुछ। यही एक फ़ीचर है जिसकी सीमा software नहीं, बल्कि मशीन पर लगे instruments हैं।
पर्यावरण की परत। यह meters को उसी तरह पढ़ती है जैसे OEE production signals को पढ़ता है, इसलिए खपत को साइट के बिल के बजाय उस रन से जोड़ा जा सकता है जिसकी वजह से वह हुई।
Diagnostics / HMI Embed
मशीन की अपनी on-device स्क्रीन को dashboard में लाएँ, ताकि fault की जाँच करने वाले supervisor को panel तक चलकर न जाना पड़े — और dashboard कभी controller होने का दिखावा न करे।
ऐसा लाइव mimic जो mobile uplink पर भी चलता है। Device की पूरी on-board application stream करने के बजाय, PulseMQ उसकी structure एक बार लाता है और फिर सिर्फ़ बदलती values भेजता है — हर update में लगभग दो सौ गुना कम डेटा। यही फ़र्क़ है एक ऐसे process mimic में जिसे देखना अच्छा लगे, और एक ऐसे में जिसे कोई दोबारा न खोले।
आप क्या देखते हैं
- लाइव diagnostics
- मशीन के on-device controller से AlarmIQ diagnostics और playback view, मशीन पेज के Diagnostics / HMI tab के अंदर।
- Bridge HMI
- चाहें तो diagnostics view के साथ ख़ुद operator HMI भी।
- Process mimic
- Device के अपने declarative manifest से dashboard में बना native process mimic — structure एक बार आती है और सिर्फ़ लाइव values stream होती हैं, जिससे यह mobile uplink पर भी तेज़ रहता है।
यह कैसे पहुँचाया जाता है
- डिज़ाइन से read-only
- Device ही source of truth रहता है और dashboard सिर्फ़ उसे दिखाता है। Embed के ज़रिए कोई write path नहीं है; मशीन में बदलाव करने वाली कोई भी चीज़ अब भी device के अपने permission checks से गुज़रती है।
- Gateway enrolment (पंजीकरण)
- ज़रूरी है कि device gateway registry में enrolled हो, और देखने वाला signed in हो — stream नेटवर्क के लिए खुली नहीं है।
मशीन का on-device controller, gateway registry में enrolled। Device पर कुछ भी install नहीं होता।
एक खिड़की, परत नहीं। Device ही source of truth रहता है और dashboard सिर्फ़ उसे दिखाता है, ताकि supervisor panel तक चले बिना मशीन की अपनी स्क्रीन देख सके।
AI असिस्टेंट
Natural language में MES operations। सवाल पूछें और commands दें सरल अंग्रेज़ी में — AWS Bedrock पर Claude से संचालित, हर मशीन के budget controls और मासिक usage caps के साथ।
आप इससे क्या पूछ सकते हैं
- प्लांट के बारे में पूछें
- मशीन का status जाँचें, schedules देखें, downtime की जाँच करें — जवाब लाइव और historical डेटा से, उस मशीन के संदर्भ में जो आपने खोल रखी है।
यह क्या कर सकता है
- इसे काम दें
- Work orders dispatch करें, maintenance item जोड़ें, process value परिभाषित करें, task template बनाएँ, OEE baseline बदलें — शब्दों में बताया गया, असली configuration पर किया गया।
- गाइडेड मशीन सेटअप
- नई मशीन को पूरी chain से गुज़ारता है: बनाना, features चुनना, status map करना, process और production signals map करना, OEE signals चुनना, baselines सेट करना, alarms और maintenance जोड़ना, फिर नतीजे को validate करना।
सीमाएँ
- आपके roles से बँधा
- असिस्टेंट ठीक वही कर सकता है जो signed-in व्यक्ति ख़ुद हाथ से कर सकता था, उससे ज़्यादा कुछ नहीं। बड़े बदलाव करने से पहले उनकी पुष्टि ली जाती है।
- दिखने वाली लागत
- Budget controls हर मशीन के लिए सेट होते हैं और usage हर महीने ट्रैक और capped होता है, ताकि यह फ़ीचर चुपचाप बिल न बढ़ा सके।
कुछ नहीं। हर मशीन के लिए मासिक budget सेट करें और यह तैयार है; यह सिर्फ़ वही कर सकता है जो signed-in व्यक्ति हाथ से कर सकता था।
अंदर आने का एक रास्ता, अपनी अलग परत नहीं। यह उसी डेटा और उन्हीं actions तक पहुँचता है जिन तक स्क्रीनें पहुँचती हैं, इसलिए यह configuration के उस काम में सबसे काम का है जिसमें वरना tabs में ढूँढ़ते रहना पड़ता।
भाग तीन — चुनाव
कोई मशीन कौन-से फ़ीचर ले सकती है, हर फ़ीचर किस पर निर्भर है, और शुरू करने के तीन रास्ते।
क्या आपके लिए सही है, और इसे अपनाने में क्या लगता है।
हर फ़ीचर एक बार में एक मशीन पर चालू किया जाता है, इसलिए आप छोटे दायरे से शुरू करके बाद में उसे बढ़ा सकते हैं। क्या उपलब्ध है, यह दो बातें तय करती हैं: मशीन का production mode, और क्या कोई फ़ीचर किसी दूसरे फ़ीचर पर निर्भर है।
| फ़ीचर | कहाँ उपलब्ध | किस पर निर्भर | आपको क्या देना होगा |
|---|---|---|---|
| OEE Monitoring | कोई भी mode | — | एक state सिग्नल, एक count या length सिग्नल, और ideal rate |
| Alarm Notifications | कोई भी mode | — | जिन tags पर नज़र रखनी है वे, और हर व्यक्ति का एक ईमेल पता |
| Maintenance Tracking | कोई भी mode | — | हर काम के लिए एक counter या कैलेंडर अंतराल |
| Enhanced Maintenance | कोई भी mode | Maintenance Tracking | PM फ़ॉर्म के लिए हर टेक्नीशियन के पास एक टैबलेट; आपके मौजूदा फ़ॉर्म PDF के रूप में |
| ISA-88 Equipment Modules | Parts — और Continuous, जहाँ यह Hybrid Mode के रूप में दिखता है | — | controller से PackML states |
| Material Tracking & Genealogy | जहाँ भी ISA-88 चालू हो | ISA-88 Equipment Modules | मशीन पर एक scanner और छपे हुए position label |
| Job Tracking | Parts, जब ISA-88 बंद हो | — | एक count सिग्नल और एक target |
| ISA-106 Continuous Process | Continuous, जब ISA-88 बंद हो | — | एक state word और एक boundary counter |
| Reports & Analytics | कोई भी mode | जिस चीज़ की भी आप रिपोर्ट चाहते हैं | एक distribution list और एक schedule |
| ERP Integration | कोई भी mode | — | एक ERP endpoint और credentials |
| Quality Management | कोई भी mode | ERP Integration | ग्रेड specifications और आपकी टेस्ट व्यवस्था |
| Sustainability Tracking | कोई भी mode | — | ऐसी metering जो reading publish करे |
| AI Assistant | कोई भी mode | — | हर मशीन के लिए एक मासिक बजट |
| Diagnostics / HMI Embed | कोई भी mode | — | gateway में enrolled ऑन-डिवाइस controller |
शुरुआत के तीन रास्ते
उन आँकड़ों से शुरू करें जो किसी के पास नहीं हैं
OEE Monitoring, Alarm Notifications और Reports & Analytics। एक हफ़्ते के अंदर आप जान जाते हैं कि आपकी असली availability कितनी है, कौन-से stop बार-बार होते हैं, और कौन-सी मशीन चुपचाप सबसे ज़्यादा नुकसान कर रही है — किसी के काम करने का तरीक़ा बदले बिना।
ज़रूरत: वे सिग्नल जो आप पहले से publish करते हैं
फिर हर आँकड़े को उसके स्रोत से जोड़ें
हर मशीन से मेल खाता execution model जोड़ें, और जहाँ lot मायने रखते हैं वहाँ Material Tracking। अब कोई आँकड़ा सामान्य रूप से किसी shift का नहीं, बल्कि एक job, एक batch और एक lot का होता है।
ज़रूरत: एक handshake block और scanners
फिर कागज़ी काम बंद करें
ERP Integration और Quality, PM फ़ॉर्म के साथ Enhanced Maintenance, और जहाँ आपकी प्रक्रिया माँगे वहाँ electronic signatures। यही वह स्तर है जो clipboard, spreadsheet और प्रति-यूज़र फ़ॉर्म सब्सक्रिप्शन की जगह लेता है।
ज़रूरत: एक ERP endpoint और टैबलेट
यहाँ कोई भी फ़ैसला ऐसा नहीं जिसे पलटा न जा सके। किसी फ़ीचर को फिर से बंद किया जा सकता है, किसी मशीन को deactivate किया जा सकता है ताकि उसका history रखते हुए वह कोई संसाधन खर्च न करे, और production mode ही अकेला विकल्प है जो मशीन बनाते समय तय हो जाता है।
परिशिष्ट
उदाहरण, और कैटलॉग के पीछे का तकनीकी संदर्भ।
उदाहरण
तीन आम दिन — यह दिखाने के लिए कि भाग दो के फ़ीचर चालू होने के बाद, जब कुछ गड़बड़ होती है, तो कैसे काम करते हैं।
एक discrete लाइन, सोमवार की सुबह
- 06:00 — shift अपने आप खुलती है
- लाइन चालू होती है और मशीन का state सिग्नल बदलता है। PulseMQ shift खोलता है, availability timeline शुरू करता है और गिनती शुरू कर देता है। कुछ भी शुरू करने के लिए किसी को लॉग इन नहीं करना पड़ता।
- 08:12 — एक stop जिसे कोई नहीं लिखता
- लाइन ग्यारह मिनट idle रहती है। यह अपनी अवधि के साथ timeline पर दर्ज होता है, और operator से कहा जाता है कि वह इसे आपकी reason-code सूची के अनुसार वर्गीकृत करे।
- 09:40 — performance खिसकने लगती है
- Cycle time धीरे-धीरे ideal से चार प्रतिशत ऊपर चला जाता है। Trend इसे एक अकेली ख़राब reading की बजाय एक ढलान के रूप में दिखाता है — और यही फ़र्क़ है tooling पर गंभीर बातचीत और कंधे उचकाने के बीच।
- 14:00 — shift बंद
- Shift का OEE, उसके तीनों factor, downtime का बँटवारा और counts आपके shift कैलेंडर के अनुसार अपने आप history में लिख दिए जाते हैं। रिपोर्ट बिना किसी के तैयार किए ईमेल से पहुँच जाती है।
एक batch जो ग़लत ड्रम के साथ शुरू नहीं होगा
- Recipe dispatch होती है
- एक supervisor recipe, मशीन और parameters चुनता है। Control recipe dispatch के समय फ़्रीज़ हो जाती है, इसलिए कल master में बदलाव करने से आज जो चला वह नहीं बदल सकता।
- Equipment रुका रहता है
- Controller अपना verification-required flag उठाता है। जब तक मटीरियल की पुष्टि नहीं होती, कुछ भी शुरू नहीं होता।
- Operator scan करता है
- पहले position label, फिर ड्रम का अपना GS1 label। PulseMQ जाँचता है कि यह सही मटीरियल है, सही मात्रा में है, released है और expire नहीं हुआ है।
- ग़लत ड्रम अस्वीकार होता है
- जवाब एक status code के रूप में वापस जाता है और लाइन रुकी रहती है — batch बनने से पहले, उसके disposition के बाद नहीं।
- सही ड्रम से रुकावट हटती है
- जुड़ा हुआ lot वापस controller में लिखा जाता है, cleared flag सेट होता है, और batch चलता है। जब तक रिकॉर्ड मौजूद है, वह lot अब उस batch की genealogy का हिस्सा है।
बिना नेटवर्क सिग्नल वाले बेसमेंट में एक PM
- काम dispatch होता है
- एक planner प्रकाशित फ़ॉर्म को एक नामित टेक्नीशियन और एक मशीन को सौंपता है। अगर मशीन की lockout procedure फ़ाइल में नहीं है, तो dispatch अस्वीकार हो जाता है और कारण बताता है।
- टेक्नीशियन नेटवर्क कवरेज से बाहर चला जाता है
- उसके टैबलेट में फ़ॉर्म पहले से है। जवाब, readings और फ़ोटो सामान्य रूप से दर्ज होते हैं।
- कुछ भी ख़ुद को saved नहीं बताता
- हर जवाब डिवाइस की queue में Queued चिह्न के साथ रहता है। जब काम फ़ाइल नहीं हुआ है, तब app यह नहीं कहता कि हो गया।
- वह वापस ऊपर आता है
- Queue खाली होती है, server हर batch की पुष्टि करता है, और उसके बाद ही जवाब queued दिखना बंद होते हैं।
- रिकॉर्ड बंद होता है
- Submission की जाँच server पर होती है; जो कुछ छूटा है वह फ़ॉर्म पर चिह्नित होता है। एक reviewer इसे स्वीकार करता है, और एक PDF मशीन के vault में फ़ाइल होती है — जिसमें दिखाया गया lockout revision और हर पेज पर content hash होता है।
आपका डेटा कैसे आता है
PulseMQ, MQTT पर Sparkplug B बोलता है — मशीन डेटा publish करने का इंडस्ट्रियल मानक। अगर आपके controls इसे publish कर सकते हैं, तो हम इसे पढ़ सकते हैं; अगर नहीं, तो एक छोटा edge gateway यह कमी पूरी करता है। मशीन पर कुछ भी बदला नहीं जाता।
मशीन से स्क्रीन तक एक सेकंड से काफ़ी कम में। इस रास्ते पर कहीं भी कोई operator हाथ से कोई आँकड़ा नहीं डालता।
- Sparkplug B native
- Birth, data, death और command messages को specification के अनुसार ही संभाला जाता है — दोबारा जुड़ने वाला device अपनी publish की हुई हर चीज़ फिर से declare करता है, इसलिए PulseMQ कभी पुरानी tag list पर नहीं चलता।
- Report-by-exception को समझता है
- Sparkplug केवल वही publish करता है जो बदला है। PulseMQ updates के बीच पूरी तस्वीर अपने पास रखता है और उन गिने-चुने सिग्नलों को force-read करता है जहाँ कोई बदलाव छूटना मायने रखेगा, जैसे command acknowledgements।
- Device की अपने आप पहचान
- ख़ुद को announce करने वाला हर node और device अपनी publish की गई tag list, अपने parent node और last-seen समय के साथ register होता है — इसमें sensors, saws, pumps और मशीन से जुड़े दूसरे उपकरण भी शामिल हैं।
- Tag के नाम आपके हाथ में
- Controller के raw tags को normalise करके आसान नामों, units और categories से map किया जाता है। PLC को छुए बिना स्क्रीन पर नाम बदलें।
- Offline की पहचान
- हर पाँच मिनट में एक जाँच उस मशीन को फ़्लैग करती है जो अपनी threshold से ज़्यादा देर से चुप है, उसे offline चिह्नित करती है, इस बदलाव को रिकॉर्ड करती है, और उसके खुले alarms का फिर से मूल्यांकन करती है।
- स्तरों में storage
- लाइव values सीधे स्क्रीन तक stream होती हैं; recovery और reporting के लिए एक टिकाऊ रिकॉर्ड धीमी रफ़्तार से लिखा जाता है; state changes, acknowledgements और पूरे हुए outputs उसी पल लिखे जाते हैं जब वे होते हैं।
- ऐतिहासिक archive
- हर processed message query के लिए सुविधाजनक layout में long-term storage में भी फ़ाइल होता है, ताकि दो साल बाद का audit भी उस shift को दोबारा जोड़कर देख सके।
- पुरानी मशीनों के साथ भी काम करता है
- बीस साल पुराने controllers भी दायरे में हैं। ज़रूरत MQTT तक पहुँचने के एक रास्ते की है, आधुनिक PLC की नहीं।
प्लांट मॉडल और equipment
प्लेटफ़ॉर्म आपके प्लांट का एक मॉडल रखता है, सिर्फ़ मशीनों की सूची नहीं — इसी से कोई आँकड़ा ऊपर के स्तर तक जुड़ पाता है और किसी fault की नीचे तक जाँच हो पाती है।
- Hierarchy (पदानुक्रम)
- कंपनी, location, area, cell, मशीन — ISA-95 मॉडल के अनुसार, work centres और cell positions के साथ।
- Cell Layout
- Areas और cells का विज़ुअल व्यू, उनमें मौजूद मशीनों और उनके लाइव status के साथ, जिसे asset तक खोला जा सकता है। Administrators इसी स्क्रीन से areas और cells जोड़ते हैं और मशीनें assign करते हैं।
- मशीन की भूमिकाएँ
- Primary, auxiliary या standalone। एक auxiliary asset — जैसे saw, conveyor या dust collector — अपनी parent मशीन से जुड़ा होता है और उसी के तहत रिपोर्ट करता है।
- लाइन topology
- मशीनों के बीच upstream और downstream संबंध, ताकि किसी रुकावट को इस संदर्भ में समझा जा सके कि उसे क्या feed करता है।
- इक्विपमेंट modules
- मशीन के अंदर के sub-units, जिन्हें एक tree के रूप में परिभाषित किया जाता है — हर एक के अपने सिग्नल और material tracking होते हैं, और हर एक को आपस में होड़ करने वाले batches के बीच arbitrate किया जा सकता है।
- इक्विपमेंट के प्रकार
- दोबारा इस्तेमाल होने वाली परिभाषाएँ, ताकि एक तरह की दसवीं मशीन शून्य से नहीं, बल्कि एक pattern से configure हो।
- इक्विपमेंट की क्षमता
- कौन-सा equipment कौन-सी procedure चला सकता है — इसकी जाँच batch को ऐसी जगह भेजने से पहले होती है जहाँ वह चल ही नहीं सकता।
- QR लेबल
- मशीनों, positions और devices के लिए प्रिंट करने योग्य labels, ताकि asset number टाइप करने की जगह scan किया जा सके।
मशीन configuration
यह सब configuration है, code नहीं। कोई फ़ीचर चालू करें और उसका टैब दिखने लगता है; इस गाइड की हर स्क्रीन उन settings से चलती है जिन्हें एक engineer किसी आम दोपहर बिना software release के बदल सकता है।
Mapping उलटी दिशा में चलती है। मशीन को PulseMQ में configure करें, फिर उसी से PLC का tag structure generate करें — Studio 5000 के लिए L5X, एक Ignition UDT, या एक CSV tag list। आपका controls engineer spreadsheet से नाम हाथ से टाइप करने की बजाय एक generated contract import करता है — और ज़्यादातर MES integrations के पहले तीन हफ़्ते इसी हाथ के काम में जाते हैं।
| टैब | वहाँ आप क्या सेट करते हैं |
|---|---|
| General | नाम, identifiers, location, work centre, production mode, time zone, serial number। |
| Features | सेक्शन 02 के तेरह फ़ीचर कार्ड — चालू, बंद, और क्या हर एक पूरी तरह configure है। |
| MQTT Config | Namespace, broker settings और heartbeat की अपेक्षाएँ। |
| MQTT Tags | मशीन जो कुछ publish करती है वह सब — search, filter, alias, categorise करें और custom tags जोड़ें। |
| Tag Management | Tag के नाम, units और categories, CSV import और export के साथ। |
| Metrics | OEE सिग्नल, production सिग्नल, continuous OEE, flexible production और environmental सिग्नल: हर एक को कौन-सा tag feed करता है, उसका display name, unit और visibility। |
| Maintenance | Counter की परिभाषाएँ और setpoints, interval या cycle आधारित, और task templates। |
| Alarms | Alarm बनाना और edit करना, conditions, severity, notification, test firing, CSV import और export। |
| Environmental | Temperature, humidity और दूसरे environmental factors, जिन्हें track और log करना है। |
| Equipment Module | ISA-88 module tree, उसकी signal mapping और उसके material tracking structures। |
| Batch Tracking | Batch configuration, PackML सिग्नल, material interlock और validation structures। |
| Batch Queue | Queue का व्यवहार और मशीन के लिए batches किस क्रम में लगते हैं। |
| Recipe | Recipe download mode, recipient, queue location और parameter-to-signal mapping। |
| Material Catalog | Material की परिभाषाएँ, units of measure, GS1 codes और tracking mode। |
| ISA-106 | Procedural states, job boundaries, production context, production logging, recipe structure, material tracking, quality और serialisation, operating mode और ERP integration। |
| PLC Integration | Communication settings, state mapping, command paths और handshake timing। |
| Auxiliary | Auxiliary equipment, pairing, scan modes और मशीन-विशेष commands। |
| Reports | Report templates, metric का चयन, schedule और ईमेल पाने वाले। |
- Signal path बनाने का टूल
- Structured tag paths एक base path, एक element और एक field से जोड़े जाते हैं, जो आपकी controls टीम के पहले से बनाए UDT structures से मेल खाते हैं — दोनों में से किसी भी separator convention के साथ।
- UDT बनाना (generation)
- PLC tag structure सीधे मशीन के configuration से generate करें और उसे Studio 5000 के लिए Rockwell L5X, JSON में Ignition UDT, या PLC और IoT bridge के लिए एक flat CSV tag list के रूप में download करें। Download से पहले स्क्रीन बता देती है कि कितने tags बनेंगे।
- ISA-88 recipe संरचनाएँ
- इसी सिद्धांत पर recipe और phase structures L5X के रूप में export होते हैं, ताकि controller का recipe interface हाथ से उतारा नहीं, generate किया जाए।
- सेटअप wizard
- नई मशीन के लिए एक guided रास्ता — बनाने से लेकर features, signals और baselines होते हुए validation तक — हाथ से या AI Assistant के ज़रिए।
- लागत पर नियंत्रण
- किसी मशीन को deactivate किया जा सकता है ताकि वह processing और storage खर्च करना बंद कर दे, जबकि उसका configuration और history सुरक्षित रहें।
Scanners, printers और devices
मशीन के आसपास का hardware उसी जगह से register, address और test किया जा सकता है जहाँ से ख़ुद मशीन।
Device के प्रकार
- लेबल प्रिंटर
- Barcode स्कैनर
- तराज़ू (scales)
- RFID रीडर
- Vision सिस्टम
- Marking सिस्टम
कनेक्शन
- नेटवर्क
- USB
- Serial
- MQTT
- Edge gateway
प्रबंधन
- Register, edit और remove करें
- किसी मशीन या position को assign करें
- Test भेजें
- लाइव online status
- प्रिंट करने योग्य QR label
- Scan से pairing
- Handheld scanner या auxiliary asset को उसका label scan करके किसी मशीन से pair करें — न कोई address टाइप करना, न कोई configuration file edit करना।
- Scan modes
- Devices को load, close-out या reject mode में सेट किया जा सकता है, ताकि एक ही scanner बिना menu के कई steps में काम आए।
- प्रिंट कहाँ हो (print targets)
- हर मशीन के लिए configure किए गए triggers पर label printers को job, batch और material label डेटा मिलता है।
Users, roles और security
Access हर request के लिए server पर तय होता है — browser में बटन छिपाकर नहीं — और किसी कंपनी का डेटा सिर्फ़ उसी कंपनी के लोगों तक पहुँच सकता है।
| Role (भूमिका) | आम तौर पर किसके पास क्या |
|---|---|
| Viewer | Dashboards, metrics और history का read-only access। |
| Maintenance | अपनी task queue, PM फ़ॉर्म, counter resets और maintenance records। |
| Supervisor | Production execution — dispatch, start, pause, complete, disposition — और साथ में वह सब जो एक viewer देखता है। |
| Engineer | मशीन configuration, tags, signals, alarms और OEE setup। |
| Customer Admin | अपनी पूरी कंपनी में users, locations, alarm और notification policy, और reports। |
| Administrator | पूरे प्लेटफ़ॉर्म का administration, जिसमें service providers के लिए multi-company संचालन भी शामिल है। |
- साइन-इन
- Password policy और session expiry वाले managed accounts, या SAML या OIDC federation के ज़रिए आपका अपना identity provider, ताकि लोग वही credentials इस्तेमाल करें जो उनके पास पहले से हैं।
- Permission matrix (अनुमतियों की तालिका)
- Permissions क्षेत्र के अनुसार समूहों में हैं — machines, users, system, alarms, materials, reports, maintenance — और एक ही बार परिभाषित हैं, ताकि कौन क्या कर सकता है, इस पर स्क्रीन और server में कभी मतभेद न हो।
- Server पर लागू
- हर request में भेजने वाले की identity होती है, और कुछ भी पढ़ने या लिखने से पहले उसकी role और उसकी कंपनी के अनुसार जाँच होती है। अनजानी role को मना कर दिया जाता है, जाने नहीं दिया जाता।
- कंपनियों का अलगाव
- डेटा customer के हिसाब से विभाजित है। एक कंपनी के users दूसरी कंपनी की machines, batches, recipes या documents तक नहीं पहुँच सकते।
- इलेक्ट्रॉनिक हस्ताक्षर
- जहाँ आपकी प्रक्रिया को इनकी ज़रूरत हो: एक घोषित अर्थ (meaning), sign करते समय password की दोबारा पुष्टि, sign किए गए रिकॉर्ड पर एक अटूट hash chain, author और approver के बीच कर्तव्यों का बँटवारा, और append-only history। Signatures कभी edit या delete नहीं होते — केवल superseded होते हैं।
- Audit trail
- Configuration के बदलाव, dispositions, overrides, resets और approvals — किसने, क्या और कब — के साथ रिकॉर्ड होते हैं।
- आपातकालीन lockdown
- अगर कुछ रोकना ज़रूरी हो, तो administrator प्लेटफ़ॉर्म को तुरंत एक maintenance स्क्रीन पर लॉक कर सकता है।
- डिज़ाइन से ही recoverable
- Operational डेटा पर point-in-time recovery के साथ continuous backup, और configuration उसके change history के साथ सुरक्षित।
डेटा, retention और integration
आपका production डेटा आपका है, हमेशा वापस पाया जा सकता है, और प्लेटफ़ॉर्म से ऐसे formats में बाहर जाता है जिन्हें दूसरे सिस्टम पढ़ सकें।
- लाइव signal store
- मशीन की मौजूदा और हाल की values, जिन्हें dashboards और उनके पीछे की गणनाओं के लिए तुरंत उपलब्ध रखा जाता है।
- प्रोडक्शन रिकॉर्ड
- Jobs, batches, work orders, material lots, genealogy, alarms और maintenance records — हर एक अपने अलग रिकॉर्ड के रूप में, जिसे मशीन, status और तारीख़ से query किया जा सकता है।
- Shift हिस्ट्री
- हर shift का OEE उसके component आँकड़ों, downtime के बँटवारे और counts के साथ, long-term trending के लिए रखा जाता है।
- लंबी अवधि का archive
- पूरे हुए jobs और batches एक schedule पर archival storage में चले जाते हैं, पीछे एक searchable index छोड़ते हुए, और उन्हें ज्यों-का-त्यों restore किया जा सकता है। लागत कम रखने के लिए पुराने archives अपने आप cold storage में चले जाते हैं।
- Query के लिए तैयार layout
- Archive एक partitioned, analytics के अनुकूल structure में लिखा जाता है, ताकि आपके अपने BI या data science tools उसे सीधे पढ़ सकें।
- REST API
- जो interface dashboard इस्तेमाल करता है, वही आपके सिस्टम के लिए उपलब्ध है: machines, jobs, batches, work orders, materials, recipes, alarms और reports।
- लाइव subscriptions
- उन applications के लिए जिन्हें poll की बजाय push चाहिए — machine status, job progress और batch status बदलते ही stream होकर बाहर जाते हैं।
- ERP के साथ डेटा का आदान-प्रदान
- सेक्शन 12 में बताए गए connector पर orders अंदर आते हैं, completions और receipts बाहर जाते हैं।
- फ़ाइल के ज़रिए आदान-प्रदान
- ऐतिहासिक और tabular डेटा के लिए CSV, recipes और configuration के लिए JSON, reports और भरे हुए फ़ॉर्म के लिए PDF।
डिप्लॉयमेंट और संचालन
इसे चलाने के दो तरीक़े, और दोनों में एक ही प्रोडक्ट।
क्लाउड
Managed और hosted, प्लांट नेटवर्क पर या उसके बाहर किसी भी browser से उपलब्ध। Updates लगातार आते रहते हैं और आपको कोई server नहीं संभालना पड़ता। आपका edge outbound publish करता है — आपके firewall में कोई inbound छेद नहीं।
ऑन-प्रेमिस
उन साइटों के लिए जो इंटरनेट तक बिल्कुल नहीं पहुँच सकतीं। प्लेटफ़ॉर्म बिना किसी बाहरी निर्भरता के आपके नेटवर्क के अंदर चलता है, और जो फ़ीचर वरना बाहर कॉल करता, वह गायब होने की बजाय एक काम करने वाले manual रास्ते पर आ जाता है।
- इंस्टॉलेशन
- आम तौर पर एक हफ़्ते के अंदर live। हमें आपसे ज़्यादातर बस network access और एक tag list चाहिए, और install करने के लिए production रोकना नहीं पड़ता।
- SCADA के साथ-साथ
- PulseMQ आपके control system की जगह नहीं लेता। यह वही पढ़ता है जो control system publish करता है, और उसके ऊपर execution, history और reporting की परत जोड़ता है।
- डिवाइस
- Desktop browsers, प्लांट फ़्लोर के panel PC और टैबलेट। टैबलेट पर यह एक app के रूप में install होता है और network outage के दौरान भी काम करता रहता है।
- कई साइट
- एक कंपनी के तहत कई locations — हर location के हिसाब से filtering, हर location के हिसाब से notification routing, और सभी locations की roll-up reporting के साथ।
- Health मॉनिटरिंग
- हर मशीन का connection state, retention के साथ message logging, और offline की पहचान — आपको पता प्लेटफ़ॉर्म से चलता है, किसी supervisor से नहीं।
हम आगे क्या बना रहे हैं
साफ़-साफ़ बता रहे हैं, क्योंकि roadmap की किसी चीज़ को तैयार फ़ीचर बताने से ही भरोसा टूटता है। ये बन चुके हैं या बन रहे हैं, लेकिन अभी आम उपयोग में नहीं हैं।
- Downtime के कारणों की कोडिंग
- Operator के लिए stop का वर्गीकरण, आपकी अपनी reason-code सूची के अनुसार, जो कारण को availability analysis में जोड़ता है। बन चुका है और provision हो चुका है; production lines पर लागू किया जा रहा है।
- ESG rollups और scoring
- लाइव environmental monitoring आज काम करती है (सेक्शन 13)। जो अभी बन रहा है वह उसके ऊपर की परत है: ऊर्जा, पानी और waste का हर shift और हर अवधि के हिसाब से रिपोर्ट करने योग्य records में एकत्रीकरण, composite sustainability score, और आपके तय किए factor पर खपत से निकाला गया carbon।
- मेंटेनेंस alarm baselines
- Counter reset से maintenance alarm को clear करना, उस baseline को रखकर जिसके आधार पर alarm उठा था।
- अतिरिक्त ERP connectors
- Epicor Kinetic आज direct connector के रूप में उपलब्ध है। SAP और Oracle, order-import और completion-export interface के ज़रिए जुड़ते हैं; उनके लिए direct connectors development में हैं।