प्रकाशित: 28 मार्च 2026 · पढ़ने में 9 मिनट
ज़्यादातर छोटे और मध्यम मैन्युफैक्चरिंग प्लांट्स में जाइए, तो production स्टेटस supervisor की मेज़ के पास एक whiteboard पर ट्रैक होता मिलेगा। Shift leads उसे हर एक-दो घंटे में अपडेट करते हैं। जब तक आँकड़े लिखे जाते हैं, वे पुराने हो चुके होते हैं। Shift के अंत में कोई whiteboard को Excel spreadsheet में उतारता है। अगली सुबह जब management spreadsheet देखता है, तब तक डेटा 12 से 18 घंटे पुराना हो चुका होता है।
इस देरी की वजह से समस्याओं पर real time में प्रतिक्रिया देना असंभव हो जाता है। सुबह 10:15 बजे बंद हुई मशीन अगले दिन तक डेटा में नहीं दिखती। तब तक root cause के विवरण धुँधले हो जाते हैं, failure देखने वाला operator घर जा चुका होता है, और असली समस्या ठीक करने की जल्दी ख़त्म हो चुकी होती है। जो समस्याएँ मिनटों में सुलझ सकती थीं, वे हफ़्तों चलने वाले बार-बार के नुकसान बन जाती हैं।
Real-time production dashboard यह देरी पूरी तरह ख़त्म कर देता है। मशीन स्टेटस, OEE, job की प्रगति और downtime events सबको, हर जगह, उसी पल दिखते हैं। Shop floor पर इससे जो व्यवहारिक बदलाव आता है, वह तुरंत होता है और मापा जा सकता है: operators समस्याओं पर तेज़ी से प्रतिक्रिया देते हैं, supervisors बेहतर फ़ैसले लेते हैं, और management को shift के अंत की रिपोर्ट्स का इंतज़ार किए बिना ज़रूरी डेटा मिल जाता है।
जो dashboard सब कुछ दिखाने की कोशिश करता है, वह कुछ भी काम का नहीं दिखाता। सबसे अच्छे production dashboards ख़ास दर्शकों और उपयोगों को ध्यान में रखकर डिज़ाइन किए जाते हैं। ये हैं ज़रूरी हिस्से:
एक नज़र में आपको दिखना चाहिए कि कौन-सी मशीनें चल रही हैं, idle हैं, changeover में हैं या fault में। रंगों से पहचान मानक तरीका है: चलने के लिए हरा, idle या changeover के लिए पीला, fault या बंद के लिए लाल। यह मैन्युफैक्चरिंग में andon board जैसा ही है — वह visual management सिस्टम जिसे Toyota ने 1950 के दशक में शुरू किया, और जो आज भी shop floor visibility के सबसे असरदार tools में से एक है।
हर मशीन tile में मौजूदा state, वह कितनी देर से उस state में है, और सक्रिय job (अगर है) दिखना चाहिए। 3 मिनट से idle मशीन कोई ख़ास बात नहीं। 45 मिनट से idle मशीन की जाँच ज़रूरी है।
हर मशीन (या production line) को मौजूदा shift का OEE, Availability (उपलब्धता), Performance (प्रदर्शन) और Quality (गुणवत्ता) में बाँटकर दिखाना चाहिए। सिर्फ़ कुल OEE संख्या दिखाना काफ़ी नहीं — OEE 62% है, यह जानने से पता नहीं चलता कि क्या ठीक करना है। यह देखना कि Availability 71%, Performance 94% और Quality 93% है, तुरंत आपको उस downtime समस्या की ओर ले जाता है जो संख्या को नीचे खींच रही है।
हर मशीन के लिए मौजूदा work order, लक्ष्य मात्रा, मौजूदा गिनती (अच्छे parts और rejects) और पूरा होने का अनुमानित समय दिखाएँ। Progress bars से operators और supervisors को दिखता है कि job schedule से आगे है, सही रास्ते पर है या पीछे। Changeovers की योजना और downstream operations के तालमेल के लिए यह जानकारी ज़रूरी है।
हाल के downtime events की scroll होती सूची या timeline, जिसमें अवधि, reason code (अगर दिया गया हो) और यह कि event अब भी सक्रिय है या नहीं। इसके दो फ़ायदे हैं: सक्रिय downtime events पर तत्परता बनती है, और एक चालू log मिलता है जिसे supervisors shift handover के दौरान देख सकते हैं।
Critical alarms साफ़-साफ़ दिखने चाहिए — उपकरण faults, out-of-spec पर्यावरणीय स्थितियाँ, मटीरियल की कमी और quality holds। ये स्टेटस की जानकारी से दिखने में अलग होने चाहिए, ताकि इन्हें नज़रअंदाज़ करना असंभव हो।
मौजूदा shift के चालू कुल आँकड़े: कुल बने parts, कुल अच्छे parts, कुल scrap, कुल downtime मिनट, और कुल OEE। इनसे अलग-अलग मशीनों के metrics को संदर्भ मिलता है और supervisors आँक पाते हैं कि पूरा प्लांट रोज़ के लक्ष्य पूरे कर रहा है या नहीं।
Shop floor की दीवार पर लगा एक बड़ा TV (55" से 75") सबको एक जैसी visibility देने का सबसे असरदार तरीका है। हर कोई — operators, material handlers, maintenance technicians, supervisors — बिना कोई application खोले या कंप्यूटर तक गए production की मौजूदा स्थिति देख सकता है। इसका मनोवैज्ञानिक असर बड़ा है: सबके सामने दिखता डेटा जवाबदेही और तत्परता पैदा करता है, जो कंप्यूटर स्क्रीन में बंद डेटा नहीं कर पाता।
दीवार के displays के लिए छोटे form-factor वाला PC (Intel NUC, Raspberry Pi या mini PC) इस्तेमाल करें, जिस पर browser kiosk mode में चले। Browser boot होते ही dashboard का URL खोलता है और full-screen चलता है — न address bar, न taskbar, और न किसी के ग़लती से उसे बंद कर पाने की गुंजाइश। Display को अपने-आप refresh होना चाहिए और network रुकावटों से बिना किसी manual दख़ल के उबरना चाहिए।
Supervisors, planners और managers आम तौर पर अपनी मेज़ से dashboard देखते हैं। वही dashboard एक सामान्य browser window में काम करना चाहिए, जहाँ अलग-अलग मशीनों में drill down करने, पुराना डेटा देखने, और ऐसी configuration settings तक पहुँचने की सुविधा हो जो shop floor display के लिए ठीक नहीं।
Plant managers और maintenance स्टाफ़ शायद ही कभी अपनी मेज़ पर होते हैं। फ़ोन और tablets पर चलने वाला responsive dashboard उन्हें कहीं से भी production स्टेटस देखने देता है — shop floor, break room या अपनी कार से। Critical alarms (मशीन faults, लंबा downtime, quality holds) के लिए push notifications पक्का करती हैं कि सही लोगों को समस्याओं का पता चले, भले ही वे स्क्रीन न देख रहे हों।
PLC से dashboard तक की data pipeline में कई layers होती हैं। हर layer को समझने से आप सही architecture चुन पाते हैं और आम गलतियों से बचते हैं।
आपको हर मशीन के PLC से signals का एक तय सेट चाहिए: machine state (running/idle/faulted), part count, cycle time, reject count, और आपकी प्रक्रिया से जुड़े कोई भी अतिरिक्त signals (spindle speed, तापमान, दबाव आदि)। ये signals PLC program में परिभाषित होने चाहिए और PLC के communication protocol के ज़रिए उपलब्ध होने चाहिए।
PLC से डेटा निकालने के दो प्रमुख protocols हैं OPC-UA और MQTT। OPC-UA पारंपरिक औद्योगिक तरीका है: plant network पर एक server PLC से डेटा इकट्ठा करता है और उसे client applications को उपलब्ध कराता है। MQTT नया और हल्का तरीका है: plant network पर एक edge gateway PLC डेटा को एक message broker पर publish करता है, जो उसे कितने भी subscribers तक पहुँचाता है।
Real-time dashboards के लिए MQTT के बड़े फ़ायदे हैं। यह event-driven है (डेटा बदलने पर publish होता है, तय समय पर poll नहीं होता), हल्का है (बहुत कम bandwidth और processing का बोझ), और स्वाभाविक रूप से वह publish/subscribe पैटर्न सपोर्ट करता है जिसकी dashboards को ज़रूरत है। Sparkplug B, MQTT के ऊपर ढाँचा और अर्थ (semantics) जोड़ता है — मानक birth/death certificates, metric definitions और state management — जो इसे production माहौल के लिए व्यावहारिक बनाते हैं।
कच्चे PLC signals को सार्थक metrics में बदलना पड़ता है। 147 से 148 होते part count signal का मतलब निकालना होता है: “Work Order WO-2024-0847 के लिए Machine 3 पर एक अच्छा part बना।” OEE को state signals, count signals और समय के मेल से कैलकुलेट करना होता है। यह processing layer कच्चे MQTT डेटा और dashboard के बीच होती है।
आख़िरी कदम है processed डेटा को कम से कम latency के साथ browser तक पहुँचाना। WebSocket connections या GraphQL subscriptions से server, updates उपलब्ध होते ही browser को push कर देता है, browser को बदलावों के लिए poll नहीं करना पड़ता। इसी से एक सेकंड से कम की update latency मिलती है — PLC signal बदलने के 500 milliseconds के भीतर dashboard पर machine state का बदलाव दिख जाता है।
आम गलतियाँ जो dashboard का असर घटाती हैं:
Production dashboard से निवेश पर रिटर्न (ROI) तीन स्रोतों से आता है:
Downtime पर तेज़ प्रतिक्रिया। जब सबको दिखता है कि Machine 5 पिछले 12 मिनट से बंद है, तो प्रतिक्रिया का समय काफ़ी घट जाता है। Maintenance को तुरंत सूचना मिलती है, न कि तब जब कोई चलकर जाए और बताए। मैन्युफैक्चरिंग consulting इंडस्ट्री के अध्ययन लगातार दिखाते हैं कि real-time visibility लागू करने के बाद unplanned stops पर औसत प्रतिक्रिया समय 30-50% घट जाता है।
डेटा इकट्ठा करने में कम मेहनत। Supervisors और operators production counts, downtime events और quality डेटा हाथ से दर्ज करने में काफ़ी समय लगाते हैं। Automated dashboards यह manual डेटा एंट्री ख़त्म कर देते हैं, और हर supervisor के लिए हर shift में 30 से 60 मिनट असली supervision के काम के लिए बचते हैं।
बेहतर फ़ैसले। जब management production का प्रदर्शन real time में देख सकता है, तो overtime, job scheduling, maintenance की प्राथमिकताओं और पूँजी निवेश के फ़ैसले अंदाज़े के बजाय डेटा पर आधारित होते हैं। इस ROI को मापना सबसे मुश्किल है, लेकिन अक्सर इसका असर सबसे बड़ा होता है।
PulseMQ एक browser-आधारित production monitoring प्लेटफ़ॉर्म है, जो MQTT और Sparkplug B के ज़रिए PLC से जुड़ता है। डेटा PLC से edge gateway होते हुए cloud तक जाता है, जहाँ उसे process करके GraphQL subscriptions के ज़रिए जुड़े browsers तक push किया जाता है। नतीजा है 500ms से कम update latency वाला लाइव dashboard, जो दीवार पर लगे TV, desktop browsers और mobile devices पर चलता है।
प्लेटफ़ॉर्म में ख़ास तौर पर shop floor displays के लिए बना kiosk mode है: full-screen, अपने-आप refresh होने वाला, network रुकावटों से अपने-आप उबरने वाला, और प्लांट के हर एरिया से जुड़ी मशीनें और metrics दिखाने के लिए configure किया जा सकने वाला। Display स्क्रीनों पर login की ज़रूरत नहीं। Supervisors TV को छुए बिना अपने browser से तय कर सकते हैं कि हर display पर क्या दिखे।
क्योंकि PulseMQ cloud-आधारित है, install या maintain करने के लिए कोई on-premises server नहीं है। आपके network पर अकेला हार्डवेयर edge gateway है (MQTT bridge चलाने वाला एक छोटा industrial PC या Raspberry Pi)। बाक़ी सब — data processing, OEE कैलकुलेशन, dashboards, पुराने डेटा का स्टोरेज और alerting — AWS में चलता है। देखें कि छोटे मैन्युफैक्चरर्स के लिए cloud MES लागत का समीकरण कैसे बदलता है।
लाइव OEE, मशीन स्टेटस, job की प्रगति और downtime — दीवार पर, आपकी मेज़ पर, और आपके फ़ोन पर। PLC से browser तक 500ms से कम में updates।
डेमो शेड्यूल करें