Azure 'ਤੇ ਡਿਜੀਟਲ ਟਵਿਨ: ਅਸਲ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕੀ ਮਾਡਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

स्वागत है इस नए एपिसोड में, जहाँ हम विक्रेता-प्रचार को एक तरफ़ रखकर Azure पर digital twins की असली समस्याओं पर बात करते हैं। हर कोई digital twin चाहता है, पर लगभग कोई भी उस असली समस्या से शुरू नहीं करता जिसे उसके plant को हल करना है। आपका डेटा पहले से ही आपके ERP, MES, historians और IoT layers में बिखरा हुआ है, फिर भी operators यह पता लगाने के लिए आज भी manual phone calls, spreadsheets और बिखरे हुए alarms पर निर्भर हैं कि कोई fault असल में किस चीज़ को प्रभावित करता है।

ASSET से नहीं, DECISION से शुरू करें
विस्तृत architecture diagrams या asset hierarchies बनाने से पहले, आपको एक ऐसे बार-बार होने वाले business decision से शुरुआत करनी होगी जो पहले से ही देरी, भ्रम या teams के बीच handoffs का कारण बनता है। अगर कोई यह नाम नहीं बता सकता कि फ़ैसला कौन लेता है, उसका सटीक समय क्या है और कौन-सी कार्रवाई ज़रूरी है, तो आपके पास digital twin का use case नहीं है, बल्कि सिर्फ़ डेटा इकट्ठा करने का विचार है। एक सच्चा digital twin कोई चमकदार CAD फ़ाइल या dashboard tile नहीं है जो sensor value बदलने पर लाल हो जाए; यह एक model का ऐसा instance है जिसमें identity, मौजूदा operating facts, change history और वे contextual relationships होते हैं जो बताते हैं कि किसी को परवाह क्यों करनी चाहिए।

TELEMETRY से पहले IDENTITY का model बनाएँ
PLC tag को twin property से जोड़ने से पहले, आपको equipment identity की मूल समस्या हल करनी होगी। अलग-अलग systems एक ही machine को पूरी तरह अलग नामों से पुकारते हैं—PLC program, MES, ERP और पुराने maintenance register शायद ही कभी एक-दूसरे से मेल खाते हैं। बिना canonical twin ID के डेटा भेजने से ऐसे fragmented twins बनते हैं जो एक-दूसरे से असहमत रहते हैं। एक स्थिर, अनूठा identifier स्थापित करें जो सामान्य operational बदलावों के दौरान भी एक जैसा रहे, और उसके साथ अपने source system references को साफ़ तौर पर मैप करें।

CURRENT STATE, EVENTS और TIME SERIES HISTORY को अलग रखें
एक आम जाल यह है कि हर high-frequency sensor reading और historical log को सीधे twin graph में ठूँस दिया जाए, जो जल्दी ही noise से भर जाता है। अपनी architecture को scalable और साफ़ रखने के लिए ज़िम्मेदारियों को अलग-अलग layers में बाँटना होगा:

• The Twin Graph: अभी के फ़ैसलों को सहारा देने वाला मौजूदा operating context और relationships रखता है।
  
• Event Streams: ऐसी सार्थक घटनाओं को दर्ज करते हैं—जैसे machine fault उठना या batch का आगे बढ़ना—जो workflows बदलती हैं और जिन पर प्रतिक्रिया ज़रूरी होती है।
  
• Time Series Storage: spindle temperatures, vibration streams और power draws जैसे raw telemetry को गहन historical analysis और pattern tracking के लिए सुरक्षित रखता है।
  

RELATIONSHIPS ही operational अर्थ देते हैं
पारंपरिक containment tree केवल यह बताता है कि भौतिक equipment plant में कहाँ स्थित है, पर वह यह नहीं समझा सकता कि workflows फ़्लोर पर कैसे फैलते हैं। Operating relationships—जैसे एक machine का downstream pack line को फ़ीड करना, किसी operation का material lot consume करना, या किसी साझा fixture से capacity की बाधा पैदा होना—वह context देते हैं जिसकी planners को किसी exception के दौरान सख़्त ज़रूरत होती है। अपने model को orders, active operations, tooling constraints और material genealogy के इर्द-गिर्द टिकाकर, आपकी architecture स्थिर asset register से हटकर plant का एक सच्चा operating map बन जाती है।


इस podcast का supporter बनें: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.