04 ਮਈ 2025·8 ਮਿੰਟ
Siemens ਅਤੇ ਕਲਾਉਡ: ਆਟੋਮੇਸ਼ਨ, ਸੌਫਟਵੇਅਰ ਅਤੇ ਡਿਜਿਟਲ ਟਵਿਨਸ
ਦੇਖੋ ਕਿ Siemens ਆਟੋਮੇਸ਼ਨ, ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਅਤੇ ਡਿਜਿਟਲ ਟਵਿਨਸ ਨੂੰ ਕਿਵੇਂ ਜੋੜਦਾ ਹੈ ਤਾਂ ਜੋ ਮਸ਼ੀਨਾਂ ਅਤੇ ਫੈਕਟਰੀਆਂ ਨੂੰ ਕਲਾਉਡ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਕੁਨੈਕਟ ਕੀਤਾ ਜਾ ਸਕੇ।
ਦੇਖੋ ਕਿ Siemens ਆਟੋਮੇਸ਼ਨ, ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਅਤੇ ਡਿਜਿਟਲ ਟਵਿਨਸ ਨੂੰ ਕਿਵੇਂ ਜੋੜਦਾ ਹੈ ਤਾਂ ਜੋ ਮਸ਼ੀਨਾਂ ਅਤੇ ਫੈਕਟਰੀਆਂ ਨੂੰ ਕਲਾਉਡ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਕੁਨੈਕਟ ਕੀਤਾ ਜਾ ਸਕੇ।
"ਭੌਤਿਕ ਅਰਥਵਿਵਸਥਾ ਨੂੰ ਕਲਾਉਡ ਨਾਲ ਜੋੜਨਾ" ਦਾ ਅਰਥ ਹੈ ਅਸਲ ਦੁਨੀਆ ਦੇ ਉਦਯੋਗਿਕ ਕੰਮ—ਲਾਈਨ 'ਤੇ ਚੱਲ ਰਹੀਆਂ ਮਸ਼ੀਨਾਂ, ਪੰਪ ਜਿਹੜੇ ਪਾਣੀ ਚਲਾਉਂਦੇ ਹਨ, ਰੋਬੋਟ ਉਤਪਾਦ ਜੋੜਦੇ ਹਨ, ਟਰੱਕ ਮਾਲ ਲੋਡ ਕਰਦੇ ਹਨ—ਉਹਨਾਂ ਨੂੰ ਐਸੇ ਸੌਫਟਵੇਅਰ ਨਾਲ ਜੋੜਨਾ ਜੋ ਉਹਨਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਕੋਆਰਡੀਨੇਸ਼ਨ ਅਤੇ ਸੁਧਾਰ ਕਰ ਸਕੇ।
ਇੱਥੇ "ਭੌਤਿਕ ਅਰਥਵਿਵਸਥਾ" ਸਿਰਫ਼ ਉਹ ਹਿੱਸੇ ਹਨ ਜੋ ਵਸਤੂਆਂ ਨੂੰ ਬਣਾਉਂਦੇ ਅਤੇ ਹਿਲਾਉਂਦੇ ਹਨ: ਨਿਰਮਾਣ, ਊਰਜਾ ਉਤਪਾਦਨ ਅਤੇ ਵੰਡ, ਇਮਾਰਤੀ ਸਿਸਟਮ, ਅਤੇ ਲੋਜਿਸਟਿਕਸ। ਇਹ ਵਾਤਾਵਰਣ ਲਗਾਤਾਰ ਸਿਗਨਲ ਉਤਪੰਨ ਕਰਦੇ ਹਨ (ਗਤੀ, ਤਾਪਮਾਨ, ਕੰਪਨ, ਗੁਣਵਤਾ ਚੈੱਕ, ਊਰਜਾ ਵਰਤੋਂ), ਪਰ ਅਸਲ ਮੁੱਲ ਉਸ ਵੇਲੇ ਉੱਪਰ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਸਿਗਨਲ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।
ਕਲਾਉਡ ਸਕੇਲਬਲ ਕੰਪਿਊਟਿੰਗ ਅਤੇ ਸਾਂਝੇ ਡੇਟਾ ਐਕਸੈਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਫੈਕਟਰੀ ਅਤੇ ਪਲਾਂਟ ਡੇਟਾ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤਕ ਪਹੁੰਚਦਾ ਹੈ, ਟੀਮਾਂ ਕਈ ਲਾਈਨਾਂ ਜਾਂ ਸਾਈਟਾਂ ਵਿੱਚ ਪੈਟਰਨ ਦੇਖ ਸਕਦੀਆਂ ਹਨ, ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਤુલਨਾ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਮੈਨਟੇਨੈਂਸ ਦੀ ਯੋਜਨਾ ਬਣਾ ਸਕਦੀਆਂ ਹਨ, ਸ਼ਡਿਊਲ ਸੰਵਾਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਗੁਣਵਤਾ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਟਰੇਸ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ "ਸਭ ਕੁਝ ਕਲਾਉਡ ਨੂੰ ਭੇਜੋ।" ਮਕਸਦ ਹੈ ਸਹੀ ਡੇਟਾ ਸਹੀ ਥਾਂ ਪੁਹੁੰਚੇ ਤਾਂ ਜੋ ਅਸਲ ਸੰਸਾਰ ਵਿੱਚ ਕਾਰਵਾਈਆਂ ਸੁਧਾਰ ਲਿਆ ਸਕਣ।
ਇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਅਕਸਰ ਤਿੰਨ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਰਾਹੀਂ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ ਅਸੀਂ ਕਾਨਸੈਪਟਾਂ ਨੂੰ ਪ੍ਰਯੋਗਿਕ ਉਦਾਹਰਣਾਂ ਨਾਲ ਸਮਝਾਵਾਂਗੇ—ਡੇਟਾ edge-to-cloud ਕਿਵੇਂ ਹਿਲਦਾ ਹੈ, ਇਨਸਾਈਟਸ ਨੂੰ ਸ਼ਾਪ-ਫਲੋਰ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਾਇਲਟ ਤੋਂ ਸਕੇਲ ਤੱਕ ਇਕ ਅਪਣਾਉਣ ਪਥ। ਜੇ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਕਦਮਾਂ ਦਾ ਪ੍ਰੀਵਿਊ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਅੱਗੇ ਦੇ ਹਵਾਲੇ '/blog/a-practical-adoption-roadmap-pilot-to-scale' ਨੂੰ ਦੇਖੋ।
Siemens ਦੀ "ਭੌਤਿਕ ਨੂੰ ਕਲਾਉਡ ਨਾਲ ਜੋੜੋ" ਕਹਾਣੀ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨੀ ਤਰ੍ਹਾਂ ਸਮਝਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਤਿੰਨ ਲੇਅਰਾਂ ਵਜੋਂ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਆਟੋਮੇਸ਼ਨ ਜੋ ਅਸਲ-ਦੁਨੀਆ ਦਾ ਡੇਟਾ ਉਤਪੰਨ ਅਤੇ ਕੰਟ੍ਰੋਲ ਕਰਦਾ ਹੈ, ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਜੋ ਉਸ ਡੇਟਾ ਨੂੰ ਲਾਈਫਸਾਈਕਲ ਵਿੱਚ ਢਾਂਚਾਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਡੇਟਾ ਪਲੇਟਫਾਰਮ ਜੋ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਉਥੇ ਭੇਜਦੇ ਹਨ ਜਿੱਥੇ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਇਸਦਾ ਉਪਯੋਗ ਕਰ ਸਕਦੇ ਹਨ।
ਸ਼ਾਪ ਫਲੋਰ 'ਤੇ, Siemens ਦਾ ਉਦਯੋਗਿਕ ਆਟੋਮੇਸ਼ਨ ਡੋਮੇਨ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ ਕੰਟਰੋਲਰ (PLCs), ਡ੍ਰਾਈਵਜ਼, HMI/ਓਪਰੇਟਰ ਪੈਨਲ, ਅਤੇ ਉਦਯੋਗਿਕ ਨੈੱਟਵਰਕ—ਉਹ ਸਿਸਟਮ ਜੋ ਸੈਂਸਰ ਪੜ੍ਹਦੇ ਹਨ, ਕੰਟਰੋਲ ਲੌਜਿਕ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਮਸ਼ੀਨਾਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਰੱਖਦੇ ਹਨ।
ਇਹ ਲੇਅਰ ਨਤੀਜੇ-ਅਹੰਕਾਰਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਕਲਾਉਡ ਇਨਸਾਈਟਸ ਆਖ਼ਿਰਕਾਰ ਸੈਟਪਾਇੰਟ, ਵਰਕ ਨਿਰਦੇਸ਼, ਅਲਾਰਮ ਅਤੇ ਮੈਨਟੇਨੈਂਸ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
Siemens ਦਾ ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਉਹ ਟੂਲ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਉਤਪਾਦਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਦੌਰਾਨ ਵਰਤੇ ਜਾਂਦੇ ਹਨ—ਸੋਚੋ ਇੰਜੀਨੀਅਰਿੰਗ, ਸਿਮੂਲੇਸ਼ਨ, PLM, ਅਤੇ MES ਜੋ ਇੱਕ ਧਾਗੇ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ। ਹਕੀਕਤੀ ਤੌਰ 'ਤੇ, ਇਹ ਉਹ “ਗਲੂ” ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਮਿਆਰੀਕਰਨ, ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ ਅਤੇ as-designed, as-planned, ਅਤੇ as-built ਦ੍ਰਿਸ਼ਆਂ ਨੂੰ ਮਿਲਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਫ਼ਾਇਦਾ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਅਤੇ ਮਾਪਯੋਗ ਹੁੰਦਾ ਹੈ: ਤੇਜ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਬਦਲਾਅ, ਘੱਟ ਰੀਵਰਕ, ਵੱਧ uptime, ਜ਼ਿਆਦਾ ਇੱਕਸਾਰ ਗੁਣਵਤਾ, ਅਤੇ ਘੱਟ ਬਰਬਾਦੀ/ਕਚਰਾ ਕਿਉਂਕਿ ਫੈਸਲੇ ਇਕੋ ਜਿਹੇ ਸੰਰਚਿਤ ਸੰਦਰਭ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ।
ਮਸ਼ੀਨਾਂ ਅਤੇ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਡੇਟਾ ਲੇਅਰ ਹਨ (ਅਕਸਰ ਉਦਯੋਗਿਕ IoT ਅਤੇ edge-to-cloud ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੇ ਤਹਿਤ ਗਿਣੇ ਜਾਂਦੇ)। ਮਕਸਦ ਹੈ ਸਹੀ ਡੇਟਾ ਨੂੰ—ਸੁਰੱਖਿਅਤ ਅਤੇ ਸੰਦਰਭ ਸਮੇਤ—ਕਲਾਉਡ ਜਾਂ ਹਾਈਬ੍ਰਿਡ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਭੇਜਣਾ ਜਿੱਥੇ ਟੀਮ ਡੈਸ਼ਬੋਰਡ, ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਕ੍ਰਾਸ-ਸਾਈਟ ਤੁਲਨਾਵਾਂ ਚਲਾ ਸਕਦੇ ਹਨ।
ਤੁਸੀਂ ਅਕਸਰ ਇਹਨਾਂ ਟੁਕੜਿਆਂ ਨੂੰ Siemens Xcelerator ਦੇ ਹੇਠਾਂ ਦੇਖੋਗੇ—Siemens ਦੇ ਪੋਰਟਫੋਲਿਓ ਲਈ ਇੱਕ ਛੱਤ ਅਤੇ ਭਾਈਚਾਰੇ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਦਾ ਇੱਕ ਐਕੋਸਿਸਟਮ। ਇਹਨਾਂ ਨੂੰ ਇਕੋ ਉਤਪਾਦ ਵਜੋਂ ਨਾ ਦੇਖੋ; ਇਹ ਯੋਗਤਾਵਾਂ ਨੂੰ ਪੈਕੇਜ ਅਤੇ ਜੁੜਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ।
Shop floor (sensors/machines) → automation/control (PLC/HMI/drives) → edge (collect/normalize) → cloud (store/analyze) → apps (maintenance, quality, energy) → actions back on the shop floor (adjust, schedule, alert).
ਇਹ ਲੂਪ—ਅਸਲੀ ਉਪਕਰਨ ਤੋਂ ਕਲਾਉਡ ਇਨਸਾਈਟ ਅਤੇ ਵਾਪਸੀ ਅਸਲ ਕਾਰਵਾਈ ਤੱਕ—ਸਮਾਰਟ ਮੈਨੂਫੈਕਚਰਿੰਗ ਉਪਰਾਲਿਆਂ ਦੀ ਸੂਤਰੀ ਲਕੀਰ ਹੈ।
ਫੈਕਟਰੀਆਂ ਦੋ ਬਹੁਤ ਹੀ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀਆਂ ਤਕਨੀਕਾਂ 'ਤੇ ਚਲਦੀਆਂ ਹਨ ਜੋ ਅਲੱਗ-ਅਲੱਗ ਵਿਕਸਿਤ ਹੋਈਆਨ।
Operational Technology (OT) ਉਹ ਹੈ ਜੋ ਭੌਤਿਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਸੈਂਸਰ, ਡ੍ਰਾਈਵਜ਼, PLCs, CNCs, SCADA/HMI ਸਕ੍ਰੀਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਸਿਸਟਮ। OT ਮਿੱਲੀਸੈਕਿੰਡ, uptime, ਅਤੇ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਿਹੇਵਿਯਰ ਦੀ ਪਰਵਾਹ ਕਰਦਾ ਹੈ।
Information Technology (IT) ਉਹ ਹੈ ਜੋ ਜਾਣਕਾਰੀ ਪ੍ਰਬੰਧਿਤ ਕਰਦੀ ਹੈ: ਨੈੱਟਵਰਕ, ਸਰਵਰ, ਡੇਟਾਬੇਸ, ਆਈਡੈਂਟੀਟੀ ਪ੍ਰਬੰਧਨ, ERP, ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਕਲਾਉਡ ਐਪਸ। IT ਮਿਆਰੀਕਰਨ, ਸਕੇਲਿੰਗ, ਅਤੇ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਦੀ ਪਰਵਾਹ ਕਰਦਾ ਹੈ।
ਰਵਾਇਤੀ ਤੌਰ ਤੇ, ਫੈਕਟਰੀਆਂ ਨੇ OT ਅਤੇ IT ਨੂੰ ਅਲੱਗ ਰੱਖਿਆ ਕਿਉਂਕਿ ਅਲੱਗਤਾ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਂਦੀ ਸੀ। ਕਈ ਉਤਪਾਦਨ ਨੈੱਟਵਰਕ ਸਾਲਾਂ ਤੱਕ “ਸਿਰਫ਼ ਚਲਣ” ਲਈ ਬਣਾਏ ਗਏ ਸਨ, ਘੱਟ ਬਦਲਾਅ, ਘੱਟ ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ, ਅਤੇ ਜਿਸ-ਦਾ ਹੱਥ ਕੌਣ ਲਗਾ ਸਕਦਾ ਹੈ ਉਸ ਤੇ ਕਠੋਰ ਨਿਯੰਤਰਣ।
ਸ਼ਾਪ ਫਲੋਰ ਨੂੰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਤੇ ਕਲਾਉਡ ਸਿਸਟਮਾਂ ਨਾਲ ਜੋੜਨਾ ਆਸਾਨ ਲਗਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਆਮ ਰੁਕਾਵਟਾਂ ਵਿੱਚ ਨਹੀਂ ਫਸਦੇ:
T_001 ਵਰਗੇ ਟੈਗ ਨਾਂ ਲਾਈਨ ਤੋਂ ਬਾਹਰ ਕੁਝ ਵੀ ਮਤਲਬ ਨਹੀਂ ਰੱਖਦੇ ਜੇ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਢਾਂਚੇ (asset, location, unit, product) ਨਾਲ ਨਕਸ਼ਾ ਨਾ ਕਰੋ.ਬਰਾਬਰ ਜੇਕਰ ਹਰ ਡਿਵਾਇਸ ਕਨੈਕਟ ਕੀਤਾ ਹੋਵੇ, ਮੁੱਲ ਸੀਮਤ ਹੈ ਜੇ ਤੱਕ ਕੋਈ ਸਾਣਝਾ ਡੇਟਾ ਮਾਡਲ ਨਹੀਂ—ਇੱਕ ਸਾਂਝਾ ਤਰੀਕਾ assets, ਘਟਨਾਵਾਂ, ਅਤੇ KPIs ਨੂੰ ਵਰਨਣ ਕਰਨ ਲਈ। ਮਿਆਰੀਕਰਨ ਘੱਟ ਇਕਾਈ ਨਕਸ਼ਾ ਘਟਾਉਂਦਾ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਕਈ ਪਲਾਂਟਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਤੋਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਮਕਸਦ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸਾਈਕਲ ਹੈ: ਡੇਟਾ → ਇਨਸਾਈਟ → ਬਦਲਾਵ। ਮਸ਼ੀਨ ਡੇਟਾ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਣ ਹੁੰਦੀ ਹੈ (ਅਕਸਰ ਉਤਪਾਦਨ ਸੰਦਰਭ ਨਾਲ), ਅਤੇ ਫਿਰ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦੀ ਹੈ—ਸ਼ਡਿਊਲ ਅੱਪਡੇਟ, ਸੈਟਪਾਇੰਟ ਸੁਧਾਰ, ਗੁਣਵੱਤਾ ਚੈੱਕਾਂ ਵਿੱਚ ਸੁਧਾਰ, ਜਾਂ ਮੈਨਟੇਨੈਂਸ ਯੋਜਨਾਵਾਂ ਬਦਲਣਾ—ਤਾਕਿ ਕਲਾਉਡ ਇਨਸਾਈਟਸ ਅਸਲ ਵਿੱਚ ਸ਼ਾਪ-ਫਲੋਰ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸੁਧਾਰ ਸਕਣ।
ਫੈਕਟਰੀ ਡੇਟਾ ਕਲਾਉਡ ਵਿੱਚ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਮਸ਼ੀਨ 'ਤੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। Siemens-ਸਟਾਈਲ ਸੈਟਅੱਪ ਵਿੱਚ, "ਆਟੋਮੇਸ਼ਨ ਲੇਅਰ" ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਭੌਤਿਕ ਸਿਗਨਲ ਭਰੋਸੇਯੋਗ, ਸਮੇਂ-ਟੈਸਟamped ਜਾਣਕਾਰੀ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਹੋਰ ਸਿਸਟਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਸਕਦੇ ਹਨ।
ਹਕੀਕਤੀ ਤੌਰ 'ਤੇ, ਆਟੋਮੇਸ਼ਨ ਇਕ suchstack ਹੈ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰ ਰਹੇ ਕੰਪੋਨੇਟ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
ਕਿਸੇ ਵੀ ਡੇਟਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਸੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਹਰ ਸਿਗਨਲ ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਵਾਤਾਵਰਣ ਇਸ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ:
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਸਰੋਤ 'ਤੇ ਡੇਟਾ ਮਿਆਰੀਕਰਿਤ ਹੁੰਦਾ ਹੈ—ਟੈਗ ਨਾਂ, ਯੂਨਿਟ, ਸਕੇਲਿੰਗ, ਅਤੇ ਸਥਿਤੀਆਂ—ਤਾਂ ਜੋ ਉੱਚ-ਸਤਰੀ ਸੌਫਟਵੇਅਰ ਅੰਦੇਜ਼ਾ ਨਾ ਲਗਾਏ।
ਇੱਕ ਮਿਸਾਲੀ ਪ੍ਰਵਾਹ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ:
ਇੱਕ ਬੇਅਰਿੰਗ ਤਾਪਮਾਨ ਸੈਂਸਰ ਚੇਤਾਵਨੀ ਸੀਮਾ ਤੋਂ ਉਪਰ ਚੱਲ ਜਾਂਦਾ → PLC ਇਸਨੂੰ ਪਛਾਣਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਥਿਤੀ ਬਿਟ ਸੈੱਟ ਕਰਦਾ ਹੈ → HMI/SCADA ਇੱਕ ਅਲਾਰਮ ਉਠਾਉਂਦਾ ਅਤੇ ਇਵੈਂਟ ਨੂੰ ਟਾਈਮਸਟੈਂਪ ਦੇ ਨਾਲ ਲੌਗ ਕਰਦਾ ਹੈ → ਹਾਲਤ ਮੈਨਟੇਨੈਂਸ ਨਿਯਮਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜੀ ਜਾਂਦੀ ਹੈ → ਇੱਕ ਮੈਂਟੇਨੈਂਸ ਵਰਕ ਆਰਡਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ("Inspect motor M-14, bearing overheating"), ਜਿਸ ਵਿੱਚ ਆਖ਼ਰੀ ਮੂਲ ਅਤੇ ਚਾਲੂ ਸੰਦਰਭ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ।
ਇਹ ਚੇਨ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਡੇਟਾ ਇੰਜਨ ਕਹਿਣ ਦਾ ਕਾਰਨ ਹੈ: ਇਹ ਕੱਚੇ ਮਾਪਾਂ ਨੂੰ ਉਪਭੋਗਤਾਯੋਗ, ਫੈਸਲਾ-ਤਿਆਰ ਸਿਗਨਲਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਆਟੋਮੇਸ਼ਨ ਭਰੋਸੇਯੋਗ ਸ਼ਾਪ-ਫਲੋਰ ਡੇਟਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਪਰ ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਉਹ ਹੈ ਜੋ ਇਸ ਡੇਟਾ ਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ, ਉਤਪਾਦਨ, ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਵਿੱਚ ਸਮਨਵਿਤ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਇੱਕ ਹੀ ਟੂਲ ਨਹੀਂ—ਇਹ ਸਿਸਟਮਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜੋ ਹਰ ਇੱਕ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ "ਮਾਲਕ" ਹੁੰਦਾ ਹੈ:
ਡਿਜਿਟਲ ਧਾਗਾ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ ਉਹ ਇਕੋ ਲਗਾਤਾਰ ਸੈੱਟ ਉਤਪਾਦ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਡੇਟਾ ਜੋ ਕੰਮ ਦੇ ਨਾਲ-ਨਾਲ ਚਲਦਾ ਹੈ—ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਮੈਨੂਫੈਕਚਰਿੰਗ ਯੋਜਨਾ ਤੱਕ ਅਤੇ ਫਿਰ ਸ਼ਾਪ ਫਲੋਰ ਵਾਪਸ।
ਹਰ ਵਿਭਾਗ ਵਿੱਚ ਜਾਣਕਾਰੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਅਤੇ ਕੌਣ ਸਹੀ ਹੈ ਇਸ 'ਤੇ ਝਗੜਾ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਜੁੜੇ ਸਿਸਟਮ ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਡਿਜ਼ਾਈਨ ਦੇ ਅਪਡੇਟ ਮੈਨੂਫੈਕਚਰਿੰਗ ਵਿੱਚ ਬਹਿ ਸਕਣ, ਅਤੇ ਉਤਪਾਦਨ ਫੀਡਬੈਕ ਇੰਜੀਨੀਅਰਿੰਗ ਤੱਕ ਵਾਪਸ ਜਾ ਸਕੇ।
ਜਦੋਂ ਇਹ ਟੂਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ, ਕੰਪਨੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਵਿਹਾਰਕ ਨਤੀਜੇ ਵੇਖਦੀਆਂ ਹਨ:
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ "ਤਾਜ਼ਾ ਫਾਈਲ" ਖੋਜਣ ਵਿੱਚ ਘਟੇ ਸਮੇਂ ਅਤੇ throughput, ਗੁਣਵਤਾ, ਅਤੇ ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਵਾਧਾ।
ਇੱਕ ਡਿਜਿਟਲ ਟਵਿਨ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇੱਕ ਜੀਉਂਦੇ ਮਾਡਲ ਵਜੋਂ ਕਿਸੇ ਅਸਲ ਚੀਜ਼ ਦਾ—ਇੱਕ ਉਤਪਾਦ, ਇੱਕ ਉਤਪਾਦਨ ਲਾਈਨ, ਜਾਂ ਇੱਕ ਐਸੈੱਟ—ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਅਸਲੀ-ਦੁਨੀਆ ਡੇਟਾ ਨਾਲ ਜੁੜਿਆ ਰਹਿੰਦਾ ਹੈ। "ਟਵਿਨ" ਹਿੱਸਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਹ ਸਿਰਫ ਡਿਜ਼ਾਈਨ 'ਤੇ ਨਹੀਂ ਰਹਿੰਦਾ। ਜਿਵੇਂ ਜਿਵੇਂ ਭੌਤਿਕ ਚੀਜ਼ ਬਣਦੀ, ਚਲਦੀ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਹੁੰਦੀ ਹੈ, ਟਵਿਨ ਉਸ ਨਾਲ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਹੋਇਆ, ਸਿਰਫ ਜੋ ਯੋਜਨਾ ਸੀ ਉਹ ਨਹੀਂ।
Siemens ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ, ਡਿਜਿਟਲ ਟਵਿਨ ਆਮਤੌਰ 'ਤੇ ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਅਤੇ ਆਟੋਮੇਸ਼ਨ 'ਤੇ ਫੈਲੇ ਹੁੰਦੇ ਹਨ: ਇੰਜੀਨੀਅਰਿੰਗ ਡੇਟਾ (ਜਿਵੇਂ CAD ਅਤੇ ਲੋੜਾਂ), ਓਪਰੇਸ਼ਨਲ ਡੇਟਾ (ਮਸ਼ੀਨਾਂ ਅਤੇ ਸੈਂਸਰਾਂ ਤੋਂ), ਅਤੇ ਕਾਰکردਗੀ ਡੇਟਾ (ਗੁਣਵੱਤਾ, ਡਾਉਨਟਾਈਮ, ਊਰਜਾ) ਜੁੜਦੇ ਹਨ ਤਾਂ ਕਿ ਟੀਮ ਇੱਕ ਹੀ, ਸੰਗਤ ਰਿਫਰੈਂਸ ਨਾਲ ਫੈਸਲੇ ਕਰ ਸਕਣ।
ਟਵਿਨ ਨੂੰ ਅਕਸਰ ਕੇਵਲ ਵਿਜ਼ੂਅਲ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਸਮਝ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਕ ਰੇਖਾ ਖਿੱਚਣ ਲਈ مفید ਹੈ:
ਵੱਖ-ਵੱਖ "ਟਵਿਨ" ਵੱਖ-ਵੱਖ ਪ੍ਰਸ਼ਨਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੇ ਹਨ:
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਟਵਿਨ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਸਰੋਤਾਂ ਤੋਂ ਖੁਰਾਕ ਲੈਂਦਾ ਹੈ:
ਜਦੋਂ ਇਹ ਇਨਪੁਟ ਜੁੜ ਜਾਂਦੇ ਹਨ, ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸਮੱਸਿਆ ਦੂਰ ਕਰ ਸਕਦੀ ਹੈ, ਬਦਲਾਵਾਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੀ ਹੈ ਪਹਿਲਾਂ ਕਿ ਉਹ ਲਾਗੂ ਕਰਨ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਸੰਗਤ ਰੱਖ ਸਕਦੀ ਹੈ।
ਸਿਮੂਲੇਸ਼ਨ ਇੱਕ ਡਿਜੀਟਲ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੈਸ਼ਕਸ਼ ਕਰਨਾ ਹੈ ਕਿ ਉਤਪਾਦ, ਮਸ਼ੀਨ, ਜਾਂ ਉਤਪਾਦਨ ਲਾਈਨ ਵੱਖ-ਵੱਖ ਹਾਲਤਾਂ 'ਚ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰੇਗੀ। ਵਰਚੁਅਲ ਕਮਿਸ਼ਨਿੰਗ ਉਸ ਤੋਂ ਇੱਕ ਕਦਮ ਅੱਗੇ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਆਟੋਮੇਸ਼ਨ ਲੌਜਿਕ ਨੂੰ simulated ਪ੍ਰਕਿਰਿਆ ਦੇ ਖਿਲਾਫ਼ "ਕਮਿਸ਼ਨ" ਕਰਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ ਅਸਲੀ ਸਾਜੋ-ਸਮਾਨ ਨੂੰ ਛੇੜੋ।
ਅਮਲੀ ਸੈਟਅੱਪ ਵਿੱਚ, ਮਕੈਨਿਕਲ ਡਿਜ਼ਾਈਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵਿਵਹਾਰ ਇੱਕ ਸਿਮੂਲੇਸ਼ਨ ਮਾਡਲ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ (ਅਕਸਰ ਡਿਜਿਟਲ ਟਵਿਨ ਨਾਲ ਸਬੰਧਿਤ), ਜਦਕਿ ਕੰਟਰੋਲ ਸਿਸਟਮ ਉਹੀ PLC/ਕੰਟਰੋਲਰ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ਾਪ ਫਲੋਰ 'ਤੇ ਵਰਤੋਂਗੇ।
ਰੀਅਲ ਲਾਈਨ ਦੇ ਇਕੱਠੇ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੰਟਰੋਲਰ ਇੱਕ ਵਰਚੁਅਲ ਵਰਜਨ ਨੂੰ "ਡਰਾਈਵ" ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਸੰਭਵ ਹੁੰਦਾ ਹੈ ਕਿ ਕੰਟਰੋਲ ਲੌਜਿਕ ਨੂੰ simulated ਪ੍ਰਕਿਰਿਆ ਦੇ ਖਿਲਾਫ਼ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾਵੇ:
ਵਰਚੁਅਲ ਕਮਿਸ਼ਨਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਆਖਰੀ-ਪੜਾਅ ਦੇ ਰੀਵਰਕ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਮੁੱਦਿਆਂ ਦੀ ਪਛਾਣ ਕਰਾਉਂਦੀ ਹੈ—ਜਿਵੇਂ race conditions, ਸਟੇਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ ਛੁੱਟ ਜਾਣ ਵਾਲੀਆਂ handshakes, ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਮੋਸ਼ਨ ਸੀਕਵੰਸ। ਇਹ ਗੁਣਵਤਾ ਦੀ ਸਹਾਇਤਾ ਵੀ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਬਦਲਾਅ (ਗਤੀ, dwell ਸਮਾਂ, reject logic) throughput ਅਤੇ ਖ਼ਰਾਬੀ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਉਣਗੇ।
ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਮਿਸ਼ਨਿੰਗ ਬਿਲਕੁਲ ਸੁਖਦਾਇਕ ਹੋਵੇਗੀ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਖਤਰੇ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਥੋੜਾ ਅੱਗੇ ਖਿੱਚ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ iteration ਤੇਜ਼ ਅਤੇ ਘੱਟ ਵਿਘਨਕ ਹੁੰਦੇ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਨਿਰਮਾਤਾ ਆਪਣੀ ਪੈਕਿੰਗ ਲਾਈਨ ਦੀ ਰਫ਼ਤਾਰ 15% ਵਧਾਉਣੀ چاہੁੰਦਾ ਹੈ ਤਾਕਿ ਮੌਸਮੀ ਮੰਗ ਪੂਰੀ ਹੋ ਸਕੇ। ਉਤਪਾਦਨ 'ਤੇ ਸਿੱਧਾ ਤਬਦੀਲ ਕਰਨ ਦੀ ਥਾਂ, ਇੰਜੀਨੀਅਰ ਪਹਿਲਾਂ ਅਪਡੇਟ ਕੀਤੀ PLC ਲੌਜਿਕ ਨੂੰ simulated ਲਾਈਨ 'ਤੇ ਚਲਾਉਂਦੇ ਹਨ:
ਵਰਚੁਅਲ ਟੈਸਟਾਂ ਤੋਂ ਬਾਅਦ, ਟੀਮ ਸੁਧਰੀ ਹੋਈ ਲੌਜਿਕ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਵਿੰਡੋ ਦੌਰਾਨ ਡਿਪਲੋਇ ਕਰਦੀ ਹੈ—ਜਿਸ ਸਮੇਂ ਉਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਏਜ ਕੇਸਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਮਾਡਲ ਇਸਨੂੰ ਕਿਵੇਂ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ, ਤਾਂ '/blog/digital-twin-basics' ਵੇਖੋ।
Edge-to-cloud ਉਹ ਰਸਤਾ ਹੈ ਜੋ ਅਸਲ ਮਸ਼ੀਨ ਵਿਹਾਰ ਨੂੰ ਵਰਤੋਂਯੋਗ ਕਲਾਉਡ ਡੇਟਾ ਵਿੱਚ ਬਦਲਦਾ ਹੈ—ਬਿਨਾਂ ਫੈਕਟਰੀ ਫਲੋਰ ਦੀ uptime ਦੀ ਬਲੀਚੜ੍ਹ ਦੇ।
Edge computing ਮਤਲਬ ਹੈ ਉਹ ਸਥਾਨਕ ਪ੍ਰੋਸੈਸਿੰਗ ਜੋ ਮਸ਼ੀਨਾਂ ਦੇ ਨੇੜੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਅਕਸਰ ਇੱਕ ਉਦਯੋਗਿਕ PC ਜਾਂ ਗੇਟਵੇ ਤੇ)। ਹਰ ਕੱਚਾ ਸਿਗਨਲ ਕਲਾਉਡ ਨੂੰ ਭੇਜਣ ਦੀ ਥਾਂ, edge ਸਾਈਟ 'ਤੇ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ, ਬਫਰ, ਅਤੇ ਸੰਪੰਨ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਫੈਕਟਰੀਆਂ ਨੂੰ ਕੰਟਰੋਲ ਲਈ ਘੱਟ ਲੈਟੈਂਸੀ ਅਤੇ ਇੰਟਰਨੈੱਟ ਕਨੈਕਟੀਵਿਟੀ ਕਮਜ਼ੋਰ ਹੋਣ ਉੱਪਰ ਵੀ ਉੱਚ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਅਕਸਰ ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:
ਡਿਵਾਈਸ/ਸੈਂਸਰ ਜਾਂ PLC → edge gateway → cloud platform → ਐਪਸ
Industrial IoT (IIoT) ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਡੇਟਾ ਇਨਜੈਸ਼ਨ, ਡਿਵਾਈਸ ਅਤੇ ਸੌਫਟਵੇਅਰ ਫਲੀਟ ਪ੍ਰਬੰਧਨ (ਵਰਜਨ, ਸਿਹਤ, ਰਿਮੋਟ ਅਪਡੇਟ), ਯੂਜ਼ਰ ਐਕਸੈਸ ਕੰਟਰੋਲ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਉਸ ਓਪਰੇਟਿੰਗ ਲੇਅਰ ਵਾਂਗ ਸੋਚੋ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਫੈਕਟਰੀ ਸਾਈਟਾਂ ਨੂੰ ਲਗਾਤਾਰ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਬੰਧਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਜਿਆਦਾਤਰ ਮਸ਼ੀਨ ਡੇਟਾ ਟਾਈਮ-ਸਿਰੀਜ਼ ਹੁੰਦਾ ਹੈ: ਸਮੇਂ ਦੇ ਨਾਲ ਦਰਜ ਕੀਤੀਆਂ ਕੀਮਤਾਂ।
Line1_FillTemp).ਕੱਚਾ ਟਾਈਮ-ਸਿਰੀਜ਼ ਉਸ ਵੇਲੇ ਬਹੁਤ ਜਿਆਦਾ ਉਪਯੋਗੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਸੰਦਰਭ ਜੋੜਦੇ ਹੋ—asset IDs, product, batch, shift, ਅਤੇ work order—ਤਾਂ ਜੋ ਕਲਾਉਡ ਐਪਸ ਓਪਰੇਸ਼ਨਲ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਣ, ਸਿਰਫ਼ ਰੁਝਾਨ ਪਲੌਟ ਨਹੀਂ।
ਬੰਦ-ਲੂਪ ਓਪਰੇਸ਼ਨ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਤਪਾਦਨ ਡੇਟਾ ਸਿਰਫ ਇਕੱਠਾ ਅਤੇ ਰਿਪੋਰਟ ਨਹੀਂ ਹੁੰਦਾ—ਉਸਨੂੰ ਅਗਲੇ ਘੰਟੇ, ਸ਼ਿਫਟ, ਜਾਂ ਬੈਚ ਨੂੰ ਸੁਧਾਰਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
Siemens-ਸਟੈਕ ਵਿੱਚ, ਆਟੋਮੇਸ਼ਨ ਅਤੇ edge ਸਿਸਟਮ ਮਸ਼ੀਨਾਂ ਤੋਂ ਸਿਗਨਲ ਕੈਪਚਰ ਕਰਦੇ ਹਨ, ਇੱਕ MES/ਓਪਰੇਸ਼ਨ ਲੇਅਰ ਉਹਨਾਂ ਨੂੰ ਵਰਕ ਸੰਦਰਭ ਵਿੱਚ ਆਯੋਜਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਉਡ ਵਿਸ਼ਲੇਸ਼ਣ ਪੈਟਰਨ ਨੂੰ ਐਸੇ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜੋ ਵਾਪਸ ਸ਼ਾਪ ਫਲੋਰ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।
MES/ਓਪਰੇਸ਼ਨ ਸੌਫਟਵੇਅਰ (ਉਦਾਹਰਣ ਵਜੋਂ Siemens Opcenter) ਲਾਈਵ ਉਪਕਰਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਡੇਟਾ ਵਰਤਦਾ ਹੈ ਤਾਂ ਕਿ ਕੰਮ ਜਿੰਝ ਹੋ ਰਿਹਾ ਹੈ ਉਸਦੇ ਨਾਲ ਮੇਲ ਖਾਏ:
ਬੰਦ-ਲੂਪ ਕੰਟਰੋਲ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਠੀਕ-ਠੀਕ ਜਾਣਦੇ ਹਾਂ ਕੀ ਬਣਾਇਆ ਗਿਆ, ਕਿਵੇਂ, ਅਤੇ ਕਿਹੜੇ ਇਨਪੁਟ ਨਾਲ।
MES ਟਰੇਸਬਿਲਟੀ ਆਮ ਤੌਰ 'ਤੇ lots/serial numbers, process parameters, ਵਰਤਿਆ ਗਿਆ ਉਪਕਰਣ, ਅਤੇ ਓਪਰੇਟਰ ਕਾਰਵਾਈਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦੀ ਹੈ, ਜੋ genealogy (ਕੰਪੋਨੈਂਟ-ਤੋਂ-ਫਿਨਿਸ਼ਡ-ਗੁੱਡ ਰਿਸ਼ਤੇ) ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਅਨੁਕੂਲਤਾ ਲਈ ਲਾਜ਼ਮੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਇਤਿਹਾਸ ਕਲਾਉਡ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਰੂਟ ਕਾਰਨਾਂ ਦੀ ਪਹਚਾਣ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਇੱਕ cavity, ਇੱਕ ਸਪਲਾਇਰ ਲੌਟ, ਇੱਕ ਰੈਸੀਪੀ ਕਦਮ) ਨਾ ਕਿ ਜੇਨਰਿਕ ਸਿਫਾਰਸ਼ਾਂ ਜਾਰੀ ਕਰਨ।
ਕਲਾਉਡ ਇਨਸਾਈਟਸ ਤਦ ਹੀ ਕਾਰਵਾਈਯੋਗ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਾਫ਼, ਸਥਾਨਕ ਕਾਰਵਾਈਆਂ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦੇ ਹਨ: ਸੁਪਰਵਾਈਜ਼ਰਾਂ ਨੂੰ ਅਲਰਟ, ਕੰਟਰੋਲ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਸੈਟਪਾਇੰਟ ਸੁਝਾਅ, ਜਾਂ SOP ਅਪਡੇਟ ਜੋ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਆਦਰਸ਼ ਤੌਰ 'ਤੇ, MES "ਡਿਲਿਵਰੀ ਚੈਨਲ" ਬਣਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਹੀ ਨਿਰਦੇਸ਼ ਸਹੀ ਸਟੇਸ਼ਨ ਤੱਕ ਸਹੀ ਸਮੇਂ 'ਤੇ ਪਹੁੰਚੇ।
ਇੱਕ ਪਲਾਂਟ ਪਾਵਰ-ਮੀਟਰ ਅਤੇ ਮਸ਼ੀਨ-ਸਾਈਕਲ ਡੇਟਾ ਕਲਾਉਡ 'ਤੇ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਅਤੇ ਗਰਮ-ਅਪ ਦੌਰਾਨ ਮੁੜ ਮੁੜ ਊਰਜਾ ਸਪਾਈਕਸ ਦੇ ਪੈਟਰਨ ਨੂੰ ਪਛਾਣਦਾ ਹੈ। ਵਿਸ਼ਲੇਸ਼ਣ ਨੇ ਸਪਾਈਕਸ ਨੂੰ ਇੱਕ ਖਾਸ ਰੀਸਟਾਰਟ ਸੀਕਵੰਸ ਨਾਲ ਜੋੜ ਦਿੱਤਾ।
ਟੀਮ ਵਾਪਸੀ 'ਤੇ edge ਨੂੰ ਇੱਕ ਤਬਦੀਲੀ ਭੇਜਦੀ ਹੈ: restart ramp rate ਸਹੀ ਕਰੋ ਅਤੇ PLC ਲੌਜਿਕ ਵਿੱਚ ਇੱਕ ਛੋਟਾ interlock ਚੈੱਕ ਜੋੜੋ। MES ਫਿਰ ਅਪਡੇਟ ਪੈਰਾਮੀਟਰ ਨੂੰ ਮਾਨੀਟਰ ਕਰਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸਪਾਈਕ ਪੈਟਰਨ ਲਾਪਤਾ ਹੋ ਗਿਆ—ਇਸ ਤਰ੍ਹਾਂ ਇਨਸਾਈਟ ਤੋਂ ਕੰਟਰੋਲ ਤੇ ਫਿਰ ਵੈਰੀਫਾਈ ਕੀਤੇ ਸੁਧਾਰ ਤੱਕ ਲੂਪ ਬੰਦ ਹੁੰਦਾ ਹੈ।
ਫੈਕਟਰੀ ਸਿਸਟਮਾਂ ਨੂੰ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲ ਜੋੜਨਾ ਆਮ ਦਫ਼ਤਰੀ IT ਨਾਲੋਂ ਵੱਖਰੇ ਕਿਸਮ ਦੇ ਖਤਰਿਆਂ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ: ਸੁਰੱਖਿਆ, uptime, ਉਤਪਾਦ ਗੁਣਵਤਾ, ਅਤੇ ਨਿਯਮਾਵਲੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ।
ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ “ਉਦਯੋਗਿਕ ਕਲਾਉਡ ਸੁਰੱਖਿਆ” ਅਸਲ ਵਿੱਚ ਨਿਸ਼ਠਾਵਾਨ ਪਹਿਚਾਣ, ਨੈੱਟਵਰਕ ਡਿਜ਼ਾਇਨ, ਅਤੇ ਡੇਟਾ ਵਰਤੋਂ ਲਈ ਸਪਸ਼ਟ ਨਿਯਮਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ।
ਹਰ ਵਿਅਕਤੀ, ਮਸ਼ੀਨ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਪਹਿਚਾਣ ਮੰਨੋ ਜਿਸਨੂੰ ਸਪਸ਼ਟ ਅਨੁਮਤੀਆਂ ਦੀ ਲੋੜ ਹੈ।
Role-based access control ਵਰਤੋ ਤਾਂ ਜੋ ਓਪਰੇਟਰ, ਮੈਨਟੇਨੈਂਸ, ਇੰਜੀਨੀਅਰ, ਅਤੇ ਬਾਹਰੀ ਵਿਕਰੇਤਾ ਸਿਰਫ਼ ਉਹੀ ਦੇਖਣ ਅਤੇ ਕਰਨ ਜੋ ਉਹਨੂੰ ਲੋੜ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਇੱਕ ਵੈਂਡਰ ਐਕਾਉਂਟ ਨੂੰ ਕਿਸੇ ਖਾਸ ਲਾਈਨ ਲਈ ਡਾਇਗਨੋਸਟਿਕ ਦੇਖਣ ਦੀ ਆਗਿਆ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ PLC ਲੌਜਿਕ ਬਦਲਣ ਜਾਂ ਉਤਪਾਦਨ ਰੈਸੀਪੀ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਨਹੀਂ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਰਿਮੋਟ ਐਕਸੈਸ ਲਈ ਮਜ਼ਬੂਤ ਸਤਿਿਕਰਨ (MFA ਸਮੇਤ) ਵਰਤੋ, ਅਤੇ ਸਾਂਝੇ ਖਾਤਿਆਂ ਤੋਂ ਬਚੋ। ਸਾਂਝੇ ਕ੍ਰੈਡੈਂਸ਼ਲਜ਼ ਕਿਸਨੇ ਕਿੰਨੇ ਬਦਲਾਅ ਕੀਤੇ ਇਹ ਆਡਿਟ ਕਰਨ ਅਸੰਭਵ ਬਣਾ ਦਿੰਦੇ ਹਨ।
ਕਈ ਪਲਾਂਟ ਅਜੇ ਵੀ "air-gapped" ਦੀਆਂ ਗੱਲਾਂ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲੀ ਓਪਰੇਸ਼ਨ ਅਕਸਰ ਰਿਮੋਟ ਸਹਾਇਤਾ, ਸਪਲਾਇਰ ਪੋਰਟਲ, ਗੁਣਵਤਾ ਰਿਪੋਰਟਿੰਗ, ਜਾਂ ਕਾਰਪੋਰੇਟ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।
ਇਸ ਦੀ ਥਾਂ ਕਿ ਤਨਾਅਵਧੀ ਇੱਕਲਤਾ ਉੱਤੇ ਨਿਰਭਰ ਰਹਿਣ, ਸੈਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਡਿਜ਼ਾਇਨ ਕਰੋ। ਇੱਕ ਆਮ ਤਰੀਕਾ ਹੈ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਨੈੱਟਵਰਕ ਨੂੰ OT ਨੈੱਟਵਰਕ ਤੋਂ ਵੱਖ ਕਰਨਾ, ਫਿਰ ਨਿਯੰਤਰਿਤ ਰਾਹਾਂ ਨਾਲ ਜ਼ੋਨ (cells/areas) ਬਣਾਉਣਾ।
ਮਕਸਦ ਸਧਾਰਣ ਹੈ: blast radius ਸੀਮਿਤ ਕਰੋ। ਜੇ ਇੱਕ ਵਰਕਸਟੇਸ਼ਨ ਕੰਪ੍ਰੋਮਾਈਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਕਿ ਇਹ ਸਾਈਟ ਦੇ ਸਾਰੇ ਕੰਟਰੋਲਰਾਂ ਤੱਕ ਰਸਤਾ ਖੋਲ ਦੇਵੇ।
ਪਲਾਂਟ ਤੋਂ ਡੇਟਾ ਸਟ੍ਰੀਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਆਗੇ ਹੀ ਮਲਕਦਾਰੀ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ। ਗਵਰਨੈਂਸ ਸਿਰਫ਼ ਅਨੁਕੂਲਤਾ ਨਹੀਂ ਹੈ—ਇਹ "ਡੇਟਾ ਸਪ੍ਰਾਲ", ਨਕਲੀ ਡੈਸ਼ਬੋਰਡ, ਅਤੇ ਆਧਿਕਾਰਤ ਨੰਬਰਾਂ 'ਤੇ ਝਗੜਿਆਂ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਪਲਾਂਟ ਲੈਪਟਾਪਾਂ ਵਾਂਗ ਪੈਚ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਕੁਝ ਐਸੈੱਟਾਂ ਦੀ ਲੰਬੀ ਪ੍ਰਮਾਣਿਕਤਾ ਚੱਕਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਣਯੋਜਿਤ ਡਾਊਨਟਾਈਮ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
ਸਟੇਜਡ ਰੋਲਆਉਟ ਵਰਤੋ: ਅਪਡੇਟਾਂ ਨੂੰ ਲੈਬ ਜਾਂ ਪਾਇਲਟ ਲਾਈਨ ਵਿੱਚ ਟੈਸਟ ਕਰੋ, ਮੈਨਟੇਨੈਂਸ ਵਿੰਡੋਜ਼ ਸ਼ਡਿਊਲ ਕਰੋ, ਅਤੇ rollback ਯੋਜਨਾਵਾਂ ਰੱਖੋ। edge ਡਿਵਾਈਸਾਂ ਅਤੇ ਗੇਟਵੇਜ਼ ਲਈ ਡਿਫੌਲਟ images ਅਤੇ ਕੰਫਿਗਰੇਸ਼ਨ ਮਿਆਰੀਕਰਤ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਈਟਾਂ 'ਤੇ ਬਿਨਾਂ ਹੈਰਾਨੀ ਦੇ ਅਪਡੇਟ ਕਰ ਸਕੋ।
ਇੱਕ ਵਧੀਆ ਉਦਯੋਗਿਕ ਕਲਾਉਡ ਪ੍ਰੋਗਰਾਮ "ਬਿਗ ਬੈਂਗ" ਪਲੇਟਫਾਰਮ ਰੋਲਆਉਟ ਬਾਰੇ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਨਕਲਯੋਗ ਪੈਟਰਨ ਬਣਾਉਣ ਬਾਰੇ ਜ਼ਿਆਦਾ। ਆਪਣਾ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਟੈਂਪਲੇਟ ਵਜੋਂ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕੋ—ਤਕਨੀਕੀ ਅਤੇ ਪ੍ਰਚਾਲਕੀ ਦੋਹਾਂ ਤੌਰ 'ਤੇ।
ਇੱਕ ਐਸੈਟ, ਇੱਕ ਮਸ਼ੀਨ, ਜਾਂ ਇੱਕ ਯੂਟਿਲਿਟੀ ਸਿਸਟਮ ਚੁਣੋ ਜਿੱਥੇ ਵਿਆਪਾਰਕ ਪ੍ਰਭਾਵ ਸਪਸ਼ਟ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਾਥਮਿਕ ਸਮੱਸਿਆ ਨਿਰਧਾਰਿਤ ਕਰੋ (ਉਦਾਹਰਣ: ਪੈਕਿੰਗ ਲਾਈਨ 'ਤੇ ਅਣਉਪਚਾਰਿਤ ਡਾਊਨਟਾਈਮ, ਇੱਕ ਫਾਰਮਿੰਗ ਸਟੇਸ਼ਨ 'ਤੇ ਸਕ੍ਰੈਪ, ਜਾਂ ਸੰਕੁਚਿਤ ਹਵਾ ਵਿੱਚ ਵਧੀਕ ਊਰਜਾ ਵਰਤੋਂ)।
ਤੇਜ਼ ਮੁੱਲ ਸਾਬਤ ਕਰਨ ਲਈ ਇਕ ਮੈਟਰਿਕ ਚੁਣੋ: OEE ਘਟ ਘੰਟੇ, ਸਕ੍ਰੈਪ ਦਰ, kWh ਪ੍ਰਤੀ ਯੂਨਿਟ, ਮੀਨ ਟਾਈਮ ਬੀਟਵੀਨ ਫੇਲਿਅਰ, ਜਾਂ ਚੇੰਜਓਵਰ ਸਮਾਂ। ਇਹ ਮੈਟਰਿਕ ਪਾਇਲਟ ਲਈ ਤੁਹਾਡਾ "ਉੱਤਮ-ਤਾਰਾ" ਅਤੇ ਸਕੇਲ ਲਈ ਤੁਹਾਡਾ ਬੇਸਲਾਈਨ ਬਣੇਗਾ।
ਅਧਿਕਤਮ ਪਾਇਲਟ ਬੁਨਿਆਦੀ ਡੇਟਾ ਮੁੱਦਿਆਂ ਵਜੋਂ ਰੁਕੇ ਹੁੰਦੇ ਹਨ, ਨ ਕਿ ਕਲਾਉਡ ਮਸਲਿਆਂ ਵਜੋਂ।
ਜੇ ਇਹ ਸਥਿਤੀਆਂ ਮੌਜੂਦ ਨਹੀਂ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਠੀਕ ਕਰੋ—ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਉਦਯੋਗਿਕ ਸੌਫਟਵੇਅਰ ਸਿਰਫ਼ ਉਸ ਡੇਟਾ ਦੀ ਹੱਦ ਤੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਮਿਲਦਾ ਹੈ।
ਜੇ ਤੁਸੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਸਟਮ ਅੰਦਰੂਨੀ ਟੂਲ (ਉਦਾਹਰਣ ਲਈ, ਹਲਕੇ-ਫੁਕੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੈਸ਼ਬੋਰਡ, ਐਕਸਪਸ਼ਨ ਕ IUues, ਮੈਨਟੇਨੈਂਸ ਟਰਿਆਜ਼ ਐਪ, ਜਾਂ ਡੇਟਾ-ਗੁਣਵੱਤਾ ਚੈਕਰ) ਬਣਾਉਣਗੇ, ਤਾਂ ਵਿਚਾਰ ਕਰੋ ਕਿ 아이ਡਿਆ ਤੋਂ ਵਰਕਿੰਗ ਸਾਫਟਵੇਅਰ ਤਕ ਇੱਕ ਤੇਜ਼ ਰਸਤਾ ਹੋਵੇ। ਟੀਮਾਂ ਅਕਸਰ ਇਹ "ਗਲੂ ਐਪਸ" Koder.ai ਵਰਗੇ ਚੈਟ-ਚਲਾਉਂਦੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਜਦੋਂ ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਯੂਜ਼ਰ ਵਰਕਫ਼ਲੋ ਵੈਰੀਫਾਈ ਹੋ ਜандੇ ਹਨ ਤਾਂ ਦੁਬਾਰਾ ਵਿਕਸਿਤ ਕਰਦੀਆਂ ਹਨ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸਲ ਦੁਨੀਆ ਦੇ ਚਾਲੂ ਕਾਰਜ (ਮਸ਼ੀਨਾਂ, ਯੂਟਿਲਿਟੀਜ਼, ਲੌਜਿਸਟਿਕਸ) ਭਰੋਸੇਯੋਗ ਸਿਗਨਲਾਂ ਨੂੰ ਸੌਫਟਵੇਅਰ ਨੂੰ ਭੇਜਣ ਜੋ ਉਹਨਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਕਰ ਸਕੇ, ਅਤੇ ਫਿਰ ਇਨਸਾਈਟਸ ਨੂੰ ਸ਼ਾਪ ਫਲੋਰ 'ਤੇ ਕਾਰਵਾਈਆਂ (ਸੈਟਪਾਇੰਟ, ਵਰਕ ਨਿਰਦੇਸ਼, ਮੈਨਟੇਨੈਂਸ ਟਾਸਕ) ਵਿੱਚ ਬਦਲਣਾ। ਲਕੜੀ ਅੰਤ ਹੈ ਨਤੀਜੇ — uptime, ਗੁਣਵੱਤਾ, throughput, ਊਰਜਾ; ਨਾ ਕਿ “ਹਰ ਚੀਜ਼ ਅੱਪਲੋਡ ਕਰਨੀ।”
ਇੱਕ ਵਰਤੋਂ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਡੇਟਾ ਭੇਜੋ:
ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਉੱਚ-ਫ੍ਰਿਕਵੈਂਸੀ ਡੇਟਾ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਇਕੱਠਾ ਕਰੋ, ਫਿਰ ਘਟਨਾਵਾਂ, ਬਦਲਾਵਾਂ, ਅਤੇ ਗਣਿਤ ਕੀਤੇ KPI ਕਲਾਉਡ ਨੂੰ ਐਗਜ਼ਪੋਰਟ ਕਰੋ।
ਇਸਨੂੰ ਤਿੰਨ ਪਰਤਾਂ ਵਜੋਂ ਸੋਚੋ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
ਮੁੱਲ ਉਸ 'ਬੰਦ ਲੂਪ' ਤੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਤਿੰਨਾਂ ਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਇਕ ਪਰਤ ਤੋਂ ਅਲੱਗ।
ਇੱਕ ਲਾਭਕਾਰੀ “ਸ਼ਬਦਾਂ ਵਿੱਚ ਡਿਆਗ੍ਰਾਮ” ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਅਕਸਰ ਟਕਰਾਵ ਦੇ ਸਰੋਤ:
T_001 ਬਿਨਾਂ asset/product/batch ਨਕਸ਼ਾ ਦੇ).ਕਨੈਕਟੀਵਿਟੀ ਖਾਲੀ ਰੁਝਾਨ ਦਿਖਾਉਂਦੀ ਹੈ; ਡੇਟਾ ਮਾਡਲ ਮਤਲਬ ਦਿੰਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ, ਇਹਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇੱਕ ਸਥਿਰ ਮਾਡਲ ਨਾਲ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਾਈਨਾਂ ਅਤੇ ਪਲਾਂਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਇੱਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਬਣ ਕੇ ਰਹਿ ਜਾਣ।
ਡਿਜਿਟਲ ਟਵਿਨ ਇੱਕ ਜੀਉਂਦਾ ਮਾਡਲ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਅਸਲੀ ਓਪਰੇਸ਼ਨਲ ਡੇਟਾ ਨਾਲ ਜੁੜਿਆ ਰਹਿੰਦਾ ਹੈ। ਆਮ ਕਿਸਮਾਂ:
ਇੱਕ ਟਵਿਨ (ਸਿਰਫ ਜੀਓਮੀਟਰੀ) ਅਤੇ (ਬਿਨਾਂ ਭਵਿੱਖਬਾਣੀ ਜਾਂ ਕਾਰਨ-ਵਿਸ਼ਲੇਸ਼ਣ)।
ਵਰਚੁਅਲ ਕਮਿਸ਼ਨਿੰਗ ਵਿੱਚ ਅਸਲੀ PLC ਲੋਜਿਕ ਨੂੰ ਇੱਕ ਸਿਮੂਲੇਟਡ ਪ੍ਰਕਿਰਿਆ/ਲਾਈਨ ਦੇ ਵਿਰੁੱਧ ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਅਸਲੀ ਉਪਕਰਨ ਨੂੰ ਛੇੜਿਆ ਜਾਵੇ। ਇਹ ਤੁਹਾਨੂੰ ਮਦਦ ਕਰਦਾ ਹੈ:
ਇਹ ਸਭ ਆਨ-ਸਾਈਟ ਕਮਿਸ਼ਨਿੰਗ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਅਕਸਰ ਦੋਸ਼ਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਕੜ ਲੈਂਦਾ ਹੈ ਜਿੱਥੇ ਦੁਹਰਾਵ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਵਯਮਿਕ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ‘ਇੱਕ ਐਸੈਟ, ਇੱਕ ਸਮੱਸਿਆ, ਇੱਕ ਮੈਟਰਿਕ’ ਪਹੁੰਚ ਵਰਤੋਂ:
ਮੁੱਖ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ:
ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ: ਯਾਦ ਰੱਖੋ ਕਿ ਜੇ ਕਲਾਉਡ ਲਿੰਕ ਡਾਊਨ ਹੋਵੇ ਤਾਂ ਫੈਕਟਰੀ ਨੂੰ ਚਲਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕੰਮ “ਅਨੁਵਾਦ + ਸੰਦਰਭ + ਗਵਰਨੈਂਸ” ਹੈ, ਸਿਰਫ਼ ਨੈੱਟਵਰਕਿੰਗ ਹੀ ਨਹੀਂ।
ਸੁਰੱਖਿਆ ਤਦ ਹੀ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ uptime, ਸੁਰੱਖਿਆ ਅਤੇ ਆਡਿਟਯੋਗਤਾ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤੀ ਜਾਵੇ, ਸਿਰਫ਼ IT ਸੁਵਿਧਾ ਲਈ ਨਹੀਂ।