IoT Hub ਮੈਸੇਜ ਰੂਟਿੰਗ ਬਨਾਮ Event Grid — ਟੈਲੀਮੈਟਰੀ ਅਤੇ ਇਵੈਂਟ ਇੱਕੋ ਸਮੱਸਿਆ ਕਿਉਂ ਨਹੀਂ ਹਨ

ਇੱਕ ਤਾਪਮਾਨ ਰੀਡਿੰਗ, ਇੱਕ ਵਾਈਬ੍ਰੇਸ਼ਨ ਨਮੂਨਾ, ਇੱਕ ਮਸ਼ੀਨ ਚੱਕਰ, ਅਤੇ ਇੱਕ ਡਿਵਾਈਸ ਡਿਸਕਨੈਕਟ, ਇਹ ਸਾਰੇ ਈਵੈਂਟ ਵਜੋਂ ਵਰਣਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਇੱਕੋ ਆਰਕੀਟੈਕਚਰਲ ਸਮੱਸਿਆ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦੇ। ਇੰਡਸਟਰੀਅਲ IoT ਅਤੇ ਮੈਨੂਫੈਕਚਰਿੰਗ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ, ਲਗਾਤਾਰ ਟੈਲੀਮੈਟਰੀ ਅਤੇ ਵੱਖਰੇ ਈਵੈਂਟਾਂ ਨੂੰ ਉਲਝਾਉਣ ਨਾਲ ਸ਼ੋਰ ਵਾਲੇ ਵਰਕਫਲੋ, ਅਧੂਰਾ ਉਤਪਾਦਨ ਇਤਿਹਾਸ, ਬੇਲੋੜੀ ਪ੍ਰੋਸੈਸਿੰਗ, ਅਤੇ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣ ਸਕਦੇ ਹਨ ਜੋ ਲੋੜੀਂਦੇ ਸੰਦਰਭ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ।

ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਯਥਾਰਥਕ ਮੈਨੂਫੈਕਚਰਿੰਗ ਦ੍ਰਿਸ਼ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ Azure IoT Hub Message Routing ਅਤੇ Azure Event Grid ਵਿਚਕਾਰ ਆਰਕੀਟੈਕਚਰਲ ਫਰਕ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਸਮਝਾਉਂਦੇ ਹਾਂ। ਇੱਕ ਪ੍ਰੈੱਸ ਲਾਈਨ ਇੱਕ ਇੰਡਸਟਰੀਅਲ ਗੇਟਵੇ ਰਾਹੀਂ ਲਗਾਤਾਰ ਤਾਪਮਾਨ, ਵਾਈਬ੍ਰੇਸ਼ਨ, ਚੱਕਰ ਗਿਣਤੀ, ਊਰਜਾ ਖਪਤ, ਅਤੇ ਮਸ਼ੀਨ-ਸਥਿਤੀ ਜਾਣਕਾਰੀ ਭੇਜਦੀ ਹੈ। ਉਹ ਮਾਪ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਇਤਿਹਾਸ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸਦਾ ਇੰਜੀਨੀਅਰਾਂ, ਡੇਟਾ ਟੀਮਾਂ, ਰੱਖ-ਰਖਾਅ ਟੀਮਾਂ, ਅਤੇ ਉਤਪਾਦਨ ਸਿਸਟਮਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਡਿਵਾਈਸ ਡਿਸਕਨੈਕਟ ਵੱਖਰਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਤਬਦੀਲੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਲਈ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ ਜਾਂ ਵਿਅਕਤੀ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਟੈਲੀਮੈਟਰੀ ਇੱਕ ਰਿਕਾਰਡ ਹੈ, ਅਲਰਟ ਨਹੀਂ
ਟੈਲੀਮੈਟਰੀ ਸਮੇਂ ਦੇ ਨਾਲ ਦੁਹਰਾਏ ਗਏ ਮਾਪਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਤਾਪਮਾਨ ਮੁੱਲ ਜਾਂ ਵਾਈਬ੍ਰੇਸ਼ਨ ਮਾਪ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਬਹੁਤ ਘੱਟ ਦੱਸਦਾ ਹੈ। ਅਸਲ ਜਾਣਕਾਰੀ ਕ੍ਰਮ ਵਿੱਚ ਹੁੰਦੀ ਹੈ: ਮੁੱਲ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲੇ, ਉਸ ਪਲ 'ਤੇ ਮਸ਼ੀਨ ਕੀ ਕਰ ਰਹੀ ਸੀ, ਰੁਕਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ, ਕੀ ਨੈੱਟਵਰਕ ਰੁਕਾਵਟ ਦੌਰਾਨ ਮਾਪ ਗਾਇਬ ਹੋ ਗਏ, ਅਤੇ ਕੀ ਪਿਛਲੇ ਉਤਪਾਦਨ ਰਨਾਂ ਵਿੱਚ ਵੀ ਇਹੀ ਵਿਹਾਰ ਦਿਖਾਈ ਦਿੱਤਾ।


ਆਮ ਇੰਡਸਟਰੀਅਲ ਟੈਲੀਮੈਟਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ:
• ਤਾਪਮਾਨ, ਵਾਈਬ੍ਰੇਸ਼ਨ, ਦਬਾਅ, ਊਰਜਾ ਖਪਤ, ਅਤੇ ਕਰੰਟ ਡਰਾਅ
• ਮਸ਼ੀਨ ਸਥਿਤੀਆਂ ਜਿਵੇਂ ਚੱਲ ਰਹੀ, ਵਿਹਲੀ, ਰੁਕੀ, ਜਾਂ ਖਰਾਬ
• ਚੱਕਰ ਗਿਣਤੀ, ਉਤਪਾਦਨ ਕਾਊਂਟਰ, ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਮਾਪ
• ਸਰੋਤ ਟਾਈਮਸਟੈਂਪ, ਡਿਵਾਈਸ ਪਛਾਣਕਰਤਾ, ਕ੍ਰਮ ਨੰਬਰ, ਅਤੇ ਕੋਰਿਲੇਸ਼ਨ ਜਾਣਕਾਰੀ

ਉਹ ਰਿਕਾਰਡ ਬਾਅਦ ਵਿੱਚ ਕੰਡੀਸ਼ਨ ਮਾਨੀਟਰਿੰਗ, ਗੁਣਵੱਤਾ ਜਾਂਚਾਂ, ਊਰਜਾ ਵਿਸ਼ਲੇਸ਼ਣ, OEE ਗਣਨਾਵਾਂ, Microsoft Fabric ਵਿਸ਼ਲੇਸ਼ਣ, Power BI ਰਿਪੋਰਟਿੰਗ, ਅਤੇ ਉਤਪਾਦਨ ਅਨੁਕੂਲਨ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ। ਇਸੇ ਲਈ ਟੈਲੀਮੈਟਰੀ ਨੂੰ ਰਿਟੈਂਸ਼ਨ, ਰੀਪਲੇਅ, ਡੁਪਲੀਕੇਟ ਹੈਂਡਲਿੰਗ, ਸੁਤੰਤਰ ਉਪਭੋਗਤਾਵਾਂ, ਅਤੇ ਉਤਪਾਦਨ ਟਾਈਮਲਾਈਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

IOT HUB MESSAGE ROUTING ਟੈਲੀਮੈਟਰੀ ਡੇਟਾ ਪਲੇਨ ਵਜੋਂ
Azure IoT Hub ਨਿਯੰਤਰਿਤ ਡਿਵਾਈਸ-ਤੋਂ-ਕਲਾਊਡ ਸੀਮਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਡਿਵਾਈਸਾਂ ਅਤੇ ਗੇਟਵੇ ਆਪਣੀਆਂ ਪਛਾਣਾਂ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਹਨ, ਡਿਵਾਈਸ-ਤੋਂ-ਕਲਾਊਡ ਸੁਨੇਹੇ ਭੇਜਦੇ ਹਨ, ਡਿਵਾਈਸ-ਪ੍ਰਬੰਧਨ ਸਥਿਤੀ ਬਣਾਈ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਨਿਯੰਤਰਿਤ ਕਲਾਊਡ-ਤੋਂ-ਡਿਵਾਈਸ ਸੰਚਾਰ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਟੈਲੀਮੈਟਰੀ ਸੁਨੇਹਾ IoT Hub ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, Message Routing ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਡੇਟਾ ਨੂੰ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। Routing ਸੁਨੇਹਾ ਪ੍ਰਾਪਰਟੀਆਂ, ਸਿਸਟਮ ਪ੍ਰਾਪਰਟੀਆਂ, ਸੁਨੇਹਾ ਬਾਡੀ ਦੇ ਹਿੱਸਿਆਂ, ਅਤੇ ਡਿਵਾਈਸ ਟਵਿਨ ਜਾਣਕਾਰੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਡਾਊਨਸਟ੍ਰੀਮ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਉਤਪਾਦਨ ਟੈਲੀਮੈਟਰੀ, ਊਰਜਾ ਮਾਪ, ਡਾਇਗਨੌਸਟਿਕਸ, ਜਾਂ ਹੋਰ ਸੁਨੇਹਾ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਆਮ ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖ ਸਕਦਾ ਹੈ: ਇੰਡਸਟਰੀਅਲ ਗੇਟਵੇ → Azure IoT Hub → Message Routing → Event Hubs ਜਾਂ Storage → ਪ੍ਰੋਸੈਸਿੰਗ → Microsoft Fabric।

ਇੱਕ ਉਪਭੋਗਤਾ ਲਗਭਗ-ਰੀਅਲ-ਟਾਈਮ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕੋਈ ਹੋਰ ਕੱਚਾ ਆਰਕਾਈਵ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਤੀਜਾ ਉਪਭੋਗਤਾ Microsoft Fabric ਲਈ ਕਿਊਰੇਟਿਡ ਓਪਰੇਸ਼ਨਲ ਡੇਟਾ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਉਪਭੋਗਤਾ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਟੈਲੀਮੈਟਰੀ ਰੀਡਿੰਗ ਨੂੰ ਵਰਕਫਲੋ ਇਨਵੋਕੇਸ਼ਨ ਵਿੱਚ ਬਦਲੇ।

ਕ੍ਰਮ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਇੰਡਸਟਰੀਅਲ ਟੈਲੀਮੈਟਰੀ ਕ੍ਰਮ ਪ੍ਰਤੀ ਖਾਸ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਮਸ਼ੀਨ ਦੱਸਦੀ ਹੈ ਕਿ ਉਹ ਚੱਲਣ ਵਾਲੀ ਸਥਿਤੀ ਵਿੱਚ ਦਾਖਲ ਹੋਈ, ਫਿਰ ਕਈ ਚੱਕਰ ਗਿਣਤੀਆਂ ਭੇਜੀਆਂ, ਫਿਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਵਿਚਲਨ ਹੋਇਆ ਅਤੇ ਅੰਤ ਵਿੱਚ ਰੁਕੀ ਸਥਿਤੀ ਆਈ। ਜੇਕਰ ਉਹ ਰਿਕਾਰਡ ਗਲਤ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਇਹ ਸਿੱਟਾ ਕੱਢ ਸਕਦਾ ਹੈ ਕਿ ਮਸ਼ੀਨ ਰੁਕੀ ਹੋਈ ਹੋਣ ਦੌਰਾਨ ਪੁਰਜੇ ਬਣਾਉਂਦੀ ਰਹੀ, ਜਾਂ ਕਿ ਪ੍ਰਕਿਰਿਆ ਵਿਚਲਨ ਉਤਪਾਦਨ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੋਇਆ।

ਇਹੀ ਸਮੱਸਿਆ ਡਾਊਨਟਾਈਮ ਗਣਨਾਵਾਂ, OEE, ਉਤਪਾਦਨ ਗਿਣਤੀਆਂ, ਅਤੇ ਕੰਡੀਸ਼ਨ ਮਾਨੀਟਰਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇਹ ਫਰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਰੋਤ ਨੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕਦੋਂ ਦੇਖਿਆ, IoT Hub ਨੇ ਸੁਨੇਹਾ ਕਦੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਨੇ ਇਸਨੂੰ ਕਦੋਂ ਪ੍ਰੋਸੈਸ ਕੀਤਾ।

ਇੱਕ ਮਜ਼ਬੂਤ ਟੈਲੀਮੈਟਰੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਇਸ ਲਈ ਵਿਚਾਰਨਾ ਚਾਹੀਦਾ ਹੈ:
• ਸਰੋਤ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਕਲਾਊਡ ਪ੍ਰਾਪਤੀ ਟਾਈਮਸਟੈਂਪ
• ਐਸੈੱਟ ਜਾਂ ਵਰਕਲੋਡ ਲਈ ਢੁਕਵੀਂ ਸਥਿਰ ਪਾਰਟੀਸ਼ਨਿੰਗ
• ਡੁਪਲੀਕੇਟ ਖੋਜ ਲਈ ਸੁਨੇਹਾ ID ਜਾਂ ਕ੍ਰਮ ਨੰਬਰ
• ਇਡੈਮਪੋਟੈਂਟ ਉਪਭੋਗਤਾ ਜੋ at-least-once ਡਿਲਿਵਰੀ ਨੂੰ ਸੰਭਾਲ ਸਕਣ

ਨੈੱਟਵਰਕ ਰੁਕਾਵਟਾਂ ਇਸਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਗੇਟਵੇ ਟੈਲੀਮੈਟਰੀ ਨੂੰ ਬਫਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਨੈਕਟੀਵਿਟੀ ਵਾਪਸ ਆਉਣ 'ਤੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ Azure ਆਗਮਨ ਸਮਾਂ ਅਸਲ ਮਸ਼ੀਨ ਟਾਈਮਸਟੈਂਪ ਤੋਂ ਕਾਫੀ ਬਾਅਦ ਦਾ ਹੋ ਸਕਦਾ ਹੈ।

EVENT GRID ਇੱਕ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ
Azure Event Grid ਪਬਲਿਸ਼-ਐਂਡ-ਸਬਸਕ੍ਰਾਈਬ ਸੂਚਨਾਵਾਂ ਦੇ ਆਸਪਾਸ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਹਜ਼ਾਰਾਂ ਰੀਡਿੰਗਾਂ ਤੋਂ ਲਗਾਤਾਰ ਮਸ਼ੀਨ ਦੀ ਸਥਿਤੀ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, Event Grid ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਸਿਸਟਮਾਂ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੁਝ ਬਦਲਿਆ ਹੈ ਅਤੇ ਸਬਸਕ੍ਰਾਈਬਰਾਂ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣ ਦਾ ਮੌਕਾ ਦਿੰਦਾ ਹੈ।
IoT ਵਾਤਾਵਰਣ ਵਿੱਚ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਡਿਵਾਈਸ ਬਣਾਉਣਾ, ਡਿਵਾਈਸ ਮਿਟਾਉਣਾ, ਕਨੈਕਟ ਹੋਣਾ, ਡਿਸਕਨੈਕਟ ਹੋਣਾ, ਜਾਂ ਧਿਆਨ ਨਾਲ ਚੁਣੀਆਂ ਟੈਲੀਮੈਟਰੀ-ਆਧਾਰਿਤ ਸਥਿਤੀਆਂ ਸ਼ਾਮਲ ਹਨ। ਇੱਕ ਡਿਵਾਈਸ-ਬਣਾਇਆ ਈਵੈਂਟ ਐਸੈੱਟ ਆਨਬੋਰਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਡਿਵਾਈਸ-ਡਿਸਕਨੈਕਟਡ ਈਵੈਂਟ ਤਕਨੀਕੀ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਖੋਜੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸਥਿਤੀ ਰੱਖ-ਰਖਾਅ ਵਰਕਫਲੋ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ।

ਆਮ ਸਬਸਕ੍ਰਾਈਬਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
• Azure Functions
• Logic Apps
• Webhooks
• ਸੁਰੱਖਿਆ ਵਰਕਫਲੋ
• ਐਸੈੱਟ-ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ
• ਓਪਰੇਸ਼ਨਲ ਐਪਲੀਕੇਸ਼ਨਾਂ

ਮੂਲ ਆਰਕੀਟੈਕਚਰਲ ਫਰਕ ਸਧਾਰਨ ਹੈ: ਟੈਲੀਮੈਟਰੀ ਪੁੱਛਦੀ ਹੈ ਕਿ ਕੋਈ ਐਸੈੱਟ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਜਦੋਂ ਕਿ ਈਵੈਂਟ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ ਹੈ ਅਤੇ ਕੀ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

ਈਵੈਂਟਾਂ ਨੂੰ ਜਾਂਚਾਂ ਸ਼ੁਰੂ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਹਕੀਕਤ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ
Event Grid ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸੂਚਨਾ ਵਿਧੀ ਵਜੋਂ ਵਿਚਾਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਭੌਤਿਕ ਸੰਸਾਰ ਦੀ ਅੰਤਿਮ ਪ੍ਰਮਾਣਿਕ ਸਥਿਤੀ ਵਜੋਂ ਨਹੀਂ। ਈਵੈਂਟ ਡਿਲਿਵਰੀ ਦੁਹਰਾਈ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਬਸਕ੍ਰਾਈਬਰ ਨੂੰ ਬਿਨਾਂ ਜਾਂਚ ਕੀਤੇ ਈਵੈਂਟਾਂ ਨੂੰ ਅੰਤਿਮ ਮੌਜੂਦਾ ਸਥਿਤੀ ਵਜੋਂ ਅੰਨ੍ਹੇਵਾਹ ਨਹੀਂ ਸਮਝਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਡਿਵਾਈਸ-ਡਿਸਕਨੈਕਟਡ ਈਵੈਂਟ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਤੀ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ Azure Function ਮੌਜੂਦਾ ਡਿਵਾਈਸ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ, ਹਾਲੀਆ ਟੈਲੀਮੈਟਰੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਸੰਬੰਧਿਤ ਰਜਿਸਟਰੀ ਜਾਣਕਾਰੀ ਵੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਫੈਸਲਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਜਾਂਚ ਖੁੱਲ੍ਹੀ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

ਹੈਂਡਲਰ ਇਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ:
• ਇਡੈਮਪੋਟੈਂਟ ਪ੍ਰੋਸੈਸਿੰਗ
• ਮੌਜੂਦਾ-ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ
• ਈਵੈਂਟ ਪਛਾਣ ਅਤੇ ਟਾਈਮਸਟੈਂਪ
• ਨਤੀਜੇ ਵਜੋਂ ਕਾਰਵਾਈ ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਿਤ ਮਾਲਕੀ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਡੁਪਲੀਕੇਟ ਈਵੈਂਟਾਂ ਨੂੰ ਡੁਪਲੀਕੇਟ ਟਿਕਟਾਂ, ਡੁਪਲੀਕੇਟ ਅਲਰਟਾਂ, ਜਾਂ ਟਕਰਾਉਂਦੇ ਓਪਰੇਸ਼ਨਲ ਰਿਕਾਰਡਾਂ ਨੂੰ ਬਣਾਉਣਾ ਨਹੀਂ ਚਾਹੀਦਾ।

ਡਿਵਾਈਸ ਡਿਸਕਨੈਕਟ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਮਸ਼ੀਨ ਰੁਕ ਗਈ
ਇੰਡਸਟਰੀਅਲ IoT ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਲਾਊਡ ਕਨੈਕਟੀਵਿਟੀ, ਡੇਟਾ-ਕਲੈਕਸ਼ਨ ਸਿਹਤ, ਅਤੇ ਉਤਪਾਦਨ ਸਥਿਤੀ ਵਿਚਲਾ ਫਰਕ ਹੈ। ਜੇਕਰ ਇੱਕ ਇੰਡਸਟਰੀਅਲ ਗੇਟਵੇ IoT Hub ਤੋਂ ਡਿਸਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕਲਾਊਡ ਨੇ ਉਸ ਗੇਟਵੇ 'ਤੇ ਦ੍ਰਿਸ਼ਟੀ ਗੁਆ ਦਿੱਤੀ ਹੈ। ਇਸਦਾ ਆਪਣੇ-ਆਪ ਮਤਲਬ ਨਹੀਂ ਕਿ ਭੌਤਿਕ ਮਸ਼ੀਨ ਰੁਕ ਗਈ ਹੈ।

PLC ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਉਪਕਰਣ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਗੇਟਵੇ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਕਨੈਕਟੀਵਿਟੀ ਗੁਆਉਂਦਾ ਹੈ। ਉਤਪਾਦਨ ਆਮ ਤੌਰ 'ਤੇ ਜਾਰੀ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਟੈਲੀਮੈਟਰੀ ਨੂੰ ਬਫਰ ਕਰਕੇ ਬਾਅਦ ਵਿੱਚ ਅਪਲੋਡ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਉਲਟਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਗੇਟਵੇ Azure ਨਾਲ ਕਨੈਕਟ ਰਹਿ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ PLC ਜਾਂ ਸਥਾਨਕ ਉਪਕਰਣ ਨਾਲ ਉਸਦਾ ਕਨੈਕਸ਼ਨ ਅਸਫਲ ਹੋ ਗਿਆ ਹੋਵੇ।

ਇਸ ਲਈ ਇੱਕ ਉਪਯੋਗੀ ਆਰਕੀਟੈਕਚਰ ਕਲਾਊਡ ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ, ਗੇਟਵੇ ਸਿਹਤ, ਮਸ਼ੀਨ ਉਤਪਾਦਨ ਸਥਿਤੀ, ਅਤੇ MES ਵਰਕ-ਆਰਡਰ ਸਥਿਤੀ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ। ਸਿਰਫ਼ ਇਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਹੀ ਕਾਰੋਬਾਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਤਕਨੀਕੀ ਕਨੈਕਟੀਵਿਟੀ ਸਮੱਸਿਆ ਨੇ ਅਸਲ ਵਿੱਚ ਉਤਪਾਦਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।

IOT HUB ਵਿੱਚ ਫਿਲਟਰਿੰਗ ਬਨਾਮ EVENT GRID ਵਿੱਚ ਫਿਲਟਰਿੰਗ
ਦੋਵੇਂ ਤਕਨਾਲੋਜੀਆਂ ਫਿਲਟਰਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਉਦੇਸ਼ ਵੱਖਰਾ ਹੈ। IoT Hub Message Routing ਫਿਲਟਰਿੰਗ ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਓਪਰੇਸ਼ਨਲ ਸੁਨੇਹੇ ਕਿਸੇ ਖਾਸ ਡੇਟਾ ਮਾਰਗ ਵਿੱਚ ਦਾਖਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। Event Grid ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਫਿਲਟਰਿੰਗ ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਸੂਚਨਾਵਾਂ ਕਿਸੇ ਖਾਸ ਸਬਸਕ੍ਰਾਈਬਰ ਨੂੰ ਮਿਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਉਦਾਹਰਣ ਲਈ, ਉਤਪਾਦਨ ਟੈਲੀਮੈਟਰੀ ਇੱਕ Event Hubs ਸਟ੍ਰੀਮ ਵਿੱਚ ਜਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਊਰਜਾ ਡੇਟਾ ਕਿਸੇ ਹੋਰ ਮੰਜ਼ਿਲ 'ਤੇ ਜਾਂਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਇੱਕ ਸਹਾਇਤਾ ਵਰਕਫਲੋ ਕਿਸੇ ਖਾਸ ਤੋਂ ਸਿਰਫ਼ ਡਿਸਕਨੈਕਟਡ ਈਵੈਂਟਾਂ ਦੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲੈ ਸਕਦਾ ਹੈ।