ਡਾਇਨਾਮਿਕ ਸਿਮੂਲੇਸ਼ਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ TOR ਲੋੜਾਂ ਦੀ ਆਟੋਮੈਟਿਕ ਤਸਦੀਕ

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

ਅਸੀਂ ਜਲਦੀ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡਾ ਸਿਸਟਮ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਅਸੀਂ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹਾਂ, ਕੀ ਸਾਡਾ ਡਿਜ਼ਾਈਨ ਉੱਡ ਜਾਵੇਗਾ ਜਾਂ ਫਲੋਟ ਹੋਵੇਗਾ? ਅਤੇ ਜੇ ਇਹ ਉੱਡਦਾ ਹੈ, ਤਾਂ ਕਿੰਨੀ ਉੱਚੀ? ਅਤੇ ਜੇ ਇਹ ਤੈਰਦਾ ਹੈ, ਤਾਂ ਕਿੰਨਾ ਡੂੰਘਾ?

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

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

ਇੱਕ ਦਸਤਾਵੇਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਤਕਨੀਕੀ ਲੋੜਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਸਮੇਂ, ਕਈ ਕਿਸਮਾਂ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ ਲੋੜਾਂ ਦੀ ਪੂਰਤੀ ਦੀ ਸਵੈਚਲਿਤ ਤਸਦੀਕ ਦੇ ਗਠਨ ਲਈ ਵੱਖ-ਵੱਖ ਪਹੁੰਚਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਲੋੜਾਂ ਦੇ ਇਸ ਛੋਟੇ ਪਰ ਯਥਾਰਥਵਾਦੀ ਸਮੂਹ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

1. ਵਾਟਰ ਟ੍ਰੀਟਮੈਂਟ ਸਿਸਟਮ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਵਾਯੂਮੰਡਲ ਦਾ ਹਵਾ ਦਾ ਤਾਪਮਾਨ:
   ਪਾਰਕਿੰਗ ਵਿੱਚ - ਮਾਈਨਸ 35 ਤੋਂ 35 ºС ਤੱਕ,
   ਫਲਾਈਟ ਵਿੱਚ - ਮਾਈਨਸ 35 ਤੋਂ 39 ºС ਤੱਕ.
2. ਫਲਾਈਟ ਵਿੱਚ ਵਾਯੂਮੰਡਲ ਹਵਾ ਦਾ ਸਥਿਰ ਦਬਾਅ 700 ਤੋਂ 1013 GPa (526 ਤੋਂ 760 mm Hg ਤੱਕ) ਹੁੰਦਾ ਹੈ।
3. ਫਲਾਈਟ ਵਿੱਚ SVO ਏਅਰ ਇਨਟੇਕ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਕੁੱਲ ਹਵਾ ਦਾ ਦਬਾਅ 754 ਤੋਂ 1200 GPa (566 ਤੋਂ 1050 mm Hg ਤੱਕ) ਹੈ।
4. ਠੰਡਾ ਹਵਾ ਦਾ ਤਾਪਮਾਨ:
   ਪਾਰਕਿੰਗ ਵਿੱਚ - 27 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ, ਤਕਨੀਕੀ ਬਲਾਕਾਂ ਲਈ - 29 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ,
   ਫਲਾਈਟ ਵਿੱਚ - 25 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ, ਤਕਨੀਕੀ ਬਲਾਕਾਂ ਲਈ - 27 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ.
5. ਕੂਲਿੰਗ ਹਵਾ ਦਾ ਪ੍ਰਵਾਹ:
   ਜਦੋਂ ਪਾਰਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਘੱਟੋ ਘੱਟ 708 ਕਿਲੋਗ੍ਰਾਮ/ਘੰਟਾ,
   ਫਲਾਈਟ ਵਿੱਚ - 660 kg/h ਤੋਂ ਘੱਟ ਨਹੀਂ।
6. ਯੰਤਰ ਦੇ ਡੱਬਿਆਂ ਵਿੱਚ ਹਵਾ ਦਾ ਤਾਪਮਾਨ 60 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ.
7. ਕੂਲਿੰਗ ਹਵਾ ਵਿੱਚ ਵਧੀਆ ਮੁਕਤ ਨਮੀ ਦੀ ਮਾਤਰਾ 2 ਗ੍ਰਾਮ/ਕਿਲੋ ਸੁੱਕੀ ਹਵਾ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ।

ਲੋੜਾਂ ਦੇ ਇਸ ਸੀਮਤ ਸਮੂਹ ਦੇ ਅੰਦਰ ਵੀ, ਘੱਟੋ-ਘੱਟ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਸਟਮ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਹੈ:

• ਸਿਸਟਮ ਦੀਆਂ ਓਪਰੇਟਿੰਗ ਹਾਲਤਾਂ ਲਈ ਲੋੜਾਂ (ਧਾਰਾ 1-3);
• ਸਿਸਟਮ ਲਈ ਪੈਰਾਮੀਟ੍ਰਿਕ ਲੋੜਾਂ (ਧਾਰਾ 3-7)।

ਸਿਸਟਮ ਓਪਰੇਟਿੰਗ ਹਾਲਾਤ ਲੋੜ
ਮਾਡਲਿੰਗ ਦੌਰਾਨ ਵਿਕਸਤ ਕੀਤੇ ਜਾ ਰਹੇ ਸਿਸਟਮ ਲਈ ਬਾਹਰੀ ਸਥਿਤੀਆਂ ਨੂੰ ਸੀਮਾ ਦੀਆਂ ਸਥਿਤੀਆਂ ਜਾਂ ਆਮ ਸਿਸਟਮ ਦੇ ਸੰਚਾਲਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਗਤੀਸ਼ੀਲ ਸਿਮੂਲੇਸ਼ਨ ਵਿੱਚ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸਿਮੂਲੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਓਪਰੇਟਿੰਗ ਹਾਲਤਾਂ ਨੂੰ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ।

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

ਲੋੜਾਂ ਦੀ ਪਛਾਣ ਅਤੇ ਕੋਡਿੰਗ

ਲੋੜਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸੌਖ ਲਈ, ਮੌਜੂਦਾ ਮਾਪਦੰਡ ਹਰੇਕ ਲੋੜ ਲਈ ਇੱਕ ਪਛਾਣਕਰਤਾ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਨ। ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਯੂਨੀਫਾਈਡ ਕੋਡਿੰਗ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ।

ਲੋੜ ਕੋਡ ਸਿਰਫ਼ ਇੱਕ ਨੰਬਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਲੋੜ ਦੇ ਆਰਡਰ ਨੰਬਰ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਾਂ ਇਸ ਵਿੱਚ ਲੋੜ ਦੀ ਕਿਸਮ ਲਈ ਇੱਕ ਕੋਡ, ਸਿਸਟਮ ਜਾਂ ਯੂਨਿਟ ਲਈ ਇੱਕ ਕੋਡ ਜਿਸ 'ਤੇ ਇਹ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਪੈਰਾਮੀਟਰ ਕੋਡ, ਇੱਕ ਸਥਾਨ ਕੋਡ, ਅਤੇ ਇੰਜਨੀਅਰ ਕਲਪਨਾ ਕਰ ਸਕਦਾ ਹੈ. (ਇੰਕੋਡਿੰਗ ਦੀ ਵਰਤੋਂ ਲਈ ਲੇਖ ਦੇਖੋ)

ਸਾਰਣੀ 1 ਲੋੜਾਂ ਦੀ ਕੋਡਿੰਗ ਦੀ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

1. ਲੋੜਾਂ ਦੇ ਸਰੋਤ ਦਾ ਕੋਡ R-ਲੋੜਾਂ TK;
2. ਲੋੜਾਂ ਦੀ ਕੋਡ ਕਿਸਮ E - ਲੋੜਾਂ - ਵਾਤਾਵਰਣਕ ਮਾਪਦੰਡ, ਜਾਂ ਓਪਰੇਟਿੰਗ ਹਾਲਤਾਂ
   S - ਸਿਸਟਮ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਲੋੜਾਂ;
3. ਏਅਰਕ੍ਰਾਫਟ ਸਟੇਟਸ ਕੋਡ 0 - ਕੋਈ ਵੀ, G - ਪਾਰਕ ਕੀਤਾ, F - ਫਲਾਈਟ ਵਿੱਚ;
4. ਭੌਤਿਕ ਪੈਰਾਮੀਟਰ ਕਿਸਮ ਕੋਡ T – ਤਾਪਮਾਨ, P – ਦਬਾਅ, G – ਵਹਾਅ ਦਰ, ਨਮੀ H;
5. ਲੋੜ ਦਾ ਸੀਰੀਅਲ ਨੰਬਰ।

ID ਲੋੜ	ਵੇਰਵਾ	ਪੈਰਾਮੀਟਰ
REGT01	ਵਾਟਰ ਕੂਲਿੰਗ ਸਿਸਟਮ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਅੰਬੀਨਟ ਹਵਾ ਦਾ ਤਾਪਮਾਨ: ਪਾਰਕਿੰਗ ਲਾਟ ਵਿੱਚ - ਮਾਈਨਸ 35ºС ਤੋਂ. 35 ºС ਤੱਕ.
REFT01	ਏਅਰ ਡਿਫੈਂਸ ਸਿਸਟਮ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਵਾਯੂਮੰਡਲ ਦਾ ਹਵਾ ਦਾ ਤਾਪਮਾਨ: ਉਡਾਣ ਵਿੱਚ - ਘਟਾਓ 35 ºС ਤੋਂ 39 ºС ਤੱਕ.
REFP01	ਫਲਾਈਟ ਵਿੱਚ ਸਥਿਰ ਵਾਯੂਮੰਡਲ ਹਵਾ ਦਾ ਦਬਾਅ 700 ਤੋਂ 1013 hPa (526 ਤੋਂ 760 mm Hg ਤੱਕ) ਹੈ।
REFP02	ਫਲਾਈਟ ਵਿੱਚ SVO ਏਅਰ ਇਨਟੇਕ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਕੁੱਲ ਹਵਾ ਦਾ ਦਬਾਅ 754 ਤੋਂ 1200 hPa (566 ਤੋਂ 1050 mm Hg ਤੱਕ) ਹੈ।
RSGT01	ਕੂਲਿੰਗ ਹਵਾ ਦਾ ਤਾਪਮਾਨ: ਜਦੋਂ ਪਾਰਕ ਕੀਤਾ ਜਾਵੇ ਤਾਂ 27 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ
RSGT02	ਕੂਲਿੰਗ ਹਵਾ ਦਾ ਤਾਪਮਾਨ: ਪਾਰਕਿੰਗ ਵਿੱਚ, ਤਕਨੀਕੀ ਇਕਾਈਆਂ ਲਈ 29 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ
RSFT01	ਫਲਾਈਟ ਵਿੱਚ ਠੰਡਾ ਕਰਨ ਵਾਲਾ ਹਵਾ ਦਾ ਤਾਪਮਾਨ 25 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ
RSFT02	ਕੂਲਿੰਗ ਹਵਾ ਦਾ ਤਾਪਮਾਨ: ਫਲਾਈਟ ਵਿੱਚ, ਤਕਨੀਕੀ ਇਕਾਈਆਂ ਲਈ 27 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ
RSGG01	ਕੂਲਿੰਗ ਹਵਾ ਦਾ ਪ੍ਰਵਾਹ: ਜਦੋਂ ਪਾਰਕ ਕੀਤਾ ਜਾਵੇ ਤਾਂ 708 ਕਿਲੋਗ੍ਰਾਮ/ਘੰਟਾ ਤੋਂ ਘੱਟ ਨਹੀਂ
RSFG01	ਕੂਲਿੰਗ ਏਅਰ ਵਹਾਅ: ਫਲਾਈਟ ਵਿੱਚ 660 ਕਿਲੋਗ੍ਰਾਮ/ਘੰਟੇ ਤੋਂ ਘੱਟ ਨਹੀਂ
RS0T01	ਯੰਤਰ ਦੇ ਡੱਬਿਆਂ ਵਿੱਚ ਹਵਾ ਦਾ ਤਾਪਮਾਨ 60 ºС ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੁੰਦਾ
RSH01	ਕੂਲਿੰਗ ਹਵਾ ਵਿੱਚ ਵਧੀਆ ਮੁਕਤ ਨਮੀ ਦੀ ਮਾਤਰਾ 2 ਗ੍ਰਾਮ/ਕਿਲੋ ਸੁੱਕੀ ਹਵਾ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ

ਲੋੜਾਂ ਤਸਦੀਕ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ.

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

ਅਤੇ ਕਿਉਂਕਿ ਤਸਦੀਕ ਇੱਕ ਐਲਗੋਰਿਦਮ ਹੈ, ਫਿਰ ਅਸੀਂ ਉਹੀ ਟੂਲ ਅਤੇ ਟੂਲ ਵਰਤ ਸਕਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਨਿਯੰਤਰਣ ਪ੍ਰੋਗਰਾਮ ਬਣਾਉਣ ਲਈ ਵਰਤਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, SimInTech ਵਾਤਾਵਰਨ ਤੁਹਾਨੂੰ ਮਾਡਲ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਪੈਕੇਜ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ ਵੱਖਰੇ ਪ੍ਰੋਜੈਕਟਾਂ (ਆਬਜੈਕਟ ਮਾਡਲ, ਕੰਟਰੋਲ ਸਿਸਟਮ ਮਾਡਲ, ਵਾਤਾਵਰਨ ਮਾਡਲ, ਆਦਿ) ਦੇ ਰੂਪ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ।

ਇਸ ਕੇਸ ਵਿੱਚ ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਪ੍ਰੋਜੈਕਟ ਉਹੀ ਐਲਗੋਰਿਦਮ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਪੈਕੇਜ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਡਾਇਨਾਮਿਕ ਮਾਡਲਿੰਗ ਮੋਡ ਵਿੱਚ ਇਹ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀਆਂ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਲਈ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ।

ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਦੀ ਇੱਕ ਸੰਭਾਵੀ ਉਦਾਹਰਨ ਚਿੱਤਰ 1 ਵਿੱਚ ਦਿਖਾਈ ਗਈ ਹੈ।

ਚਿੱਤਰ 1. ਇੱਕ ਤਸਦੀਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਡਿਜ਼ਾਈਨ ਦੀ ਉਦਾਹਰਨ।

ਜਿਵੇਂ ਕਿ ਨਿਯੰਤਰਣ ਐਲਗੋਰਿਦਮ ਲਈ, ਲੋੜਾਂ ਨੂੰ ਸ਼ੀਟਾਂ ਦੇ ਸਮੂਹ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਟ੍ਰਕਚਰਲ ਮਾਡਲਿੰਗ ਵਾਤਾਵਰਨ ਜਿਵੇਂ ਕਿ ਸਿਮਇਨਟੈਕ, ਸਿਮੁਲਿੰਕ, ਐਮੇਸਿਮ ਵਿੱਚ ਐਲਗੋਰਿਦਮ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸਹੂਲਤ ਲਈ, ਸਬ-ਮਾਡਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਬਹੁ-ਪੱਧਰੀ ਢਾਂਚੇ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਸੰਗਠਨ ਲੋੜਾਂ ਦੀ ਇੱਕ ਲੜੀ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਨੂੰ ਸੈੱਟਾਂ ਵਿੱਚ ਸਮੂਹ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੰਟਰੋਲ ਐਲਗੋਰਿਦਮ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਚਿੱਤਰ 2 ਦੇਖੋ)।

ਚਿੱਤਰ 2. ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਮਾਡਲ ਦੀ ਲੜੀਵਾਰ ਬਣਤਰ।

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

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

ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਵੇਲੇ, ਸੈਂਸਰਾਂ ਦੀਆਂ ਰੀਡਿੰਗਾਂ (ਅਸਲ ਸਿਸਟਮ ਸੈਂਸਰਾਂ ਦੇ ਐਨਾਲਾਗ) ਜੋ ਕਿ ਕੰਟਰੋਲ ਸਿਸਟਮ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਟੈਸਟ ਪ੍ਰੋਜੈਕਟ ਲਈ, ਡਾਇਨਾਮਿਕ ਮਾਡਲ ਵਿੱਚ ਗਿਣਿਆ ਗਿਆ ਕੋਈ ਵੀ ਮਾਪਦੰਡ ਉਸੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

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

ਚਿੱਤਰ 3. ਤਸਦੀਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਗੁੰਝਲਦਾਰ ਮਾਡਲ ਨਾਲ ਜੋੜਨਾ।

ਇੱਕ ਬੁਨਿਆਦੀ ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਸ਼ੀਟ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਚਿੱਤਰ 4 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹੈ। ਡਿਵੈਲਪਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਇੱਕ ਰਵਾਇਤੀ ਗਣਨਾ ਚਿੱਤਰ ਹੈ ਜਿਸ 'ਤੇ ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਐਲਗੋਰਿਦਮ ਨੂੰ ਗ੍ਰਾਫਿਕ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ।

ਚਿੱਤਰ 4. ਲੋੜਾਂ ਦੀ ਜਾਂਚ ਸ਼ੀਟ।

ਚੈੱਕ ਸ਼ੀਟ ਦੇ ਮੁੱਖ ਭਾਗਾਂ ਨੂੰ ਚਿੱਤਰ 5 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਚੈਕ ਐਲਗੋਰਿਦਮ ਨਿਯੰਤਰਣ ਐਲਗੋਰਿਦਮ ਦੇ ਡਿਜ਼ਾਇਨ ਚਿੱਤਰਾਂ ਦੇ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਸੱਜੇ ਪਾਸੇ ਡਾਟਾਬੇਸ ਤੋਂ ਸਿਗਨਲ ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਬਲਾਕ ਹੈ. ਇਹ ਬਲਾਕ ਸਿਮੂਲੇਸ਼ਨ ਦੌਰਾਨ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ।

ਪ੍ਰਾਪਤ ਸਿਗਨਲਾਂ ਨੂੰ ਲੋੜਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਹਵਾਈ ਜਹਾਜ਼ ਦੀ ਸਥਿਤੀ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਉਚਾਈ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਭਾਵੇਂ ਇਹ ਪਾਰਕ ਕੀਤਾ ਗਿਆ ਹੋਵੇ ਜਾਂ ਉਡਾਣ ਵਿੱਚ)। ਇਸ ਮੰਤਵ ਲਈ, ਤੁਸੀਂ ਮਾਡਲ ਦੇ ਹੋਰ ਸੰਕੇਤਾਂ ਅਤੇ ਗਣਨਾ ਕੀਤੇ ਮਾਪਦੰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ.

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

ਚਿੱਤਰ 5. ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਗਣਨਾ ਸ਼ੀਟ ਦਾ ਢਾਂਚਾ।

ਟੈਸਟ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਮਾਪਦੰਡ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਮੌਜੂਦ ਸਿਗਨਲਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਜੋ ਕਿ ਸਿਮੂਲੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਗਣਨਾ ਕੀਤੇ ਪੈਰਾਮੀਟਰਾਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਕੁਝ ਵੀ ਸਾਨੂੰ ਡਰਾਫਟ ਲੋੜਾਂ ਦੇ ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ ਵਾਧੂ ਗਣਨਾਵਾਂ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ, ਜਿਵੇਂ ਅਸੀਂ ਪੁਸ਼ਟੀਕਰਨ ਸ਼ਰਤਾਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ।

ਉਦਾਹਰਨ ਲਈ, ਇਹ ਲੋੜ:

ਟੀਚੇ 'ਤੇ ਉਡਾਣ ਦੌਰਾਨ ਸੁਧਾਰ ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਸਰਗਰਮੀਆਂ ਦੀ ਗਿਣਤੀ 5 ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਅਤੇ ਸੁਧਾਰ ਪ੍ਰਣਾਲੀ ਦਾ ਕੁੱਲ ਓਪਰੇਟਿੰਗ ਸਮਾਂ 30 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਆਮ ਲੋੜਾਂ ਤਸਦੀਕ ਬਲਾਕ।

ਹਰੇਕ ਮਿਆਰੀ ਲੋੜ ਦਾ ਚੈੱਕ ਬਾਕਸ ਕਿਸੇ ਖਾਸ ਕਿਸਮ ਦੀ ਲੋੜ ਦੀ ਪੂਰਤੀ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਵਾਤਾਵਰਣ ਸੰਬੰਧੀ ਲੋੜਾਂ ਵਿੱਚ ਪਾਰਕ ਕੀਤੇ ਜਾਣ ਅਤੇ ਉਡਾਣ ਦੌਰਾਨ ਅੰਬੀਨਟ ਓਪਰੇਟਿੰਗ ਤਾਪਮਾਨਾਂ ਦੀ ਇੱਕ ਸੀਮਾ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਇਸ ਬਲਾਕ ਨੂੰ ਪੈਰਾਮੀਟਰ ਦੇ ਰੂਪ ਵਿੱਚ ਮਾਡਲ ਵਿੱਚ ਹਵਾ ਦਾ ਤਾਪਮਾਨ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਪੈਰਾਮੀਟਰ ਨਿਰਧਾਰਤ ਤਾਪਮਾਨ ਸੀਮਾ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।</p>

ਬਲਾਕ ਵਿੱਚ ਦੋ ਇੰਪੁੱਟ ਪੋਰਟ ਹਨ, ਪਰਮ ਅਤੇ ਕੰਡੀਸ਼ਨ।

ਪਹਿਲੇ ਨੂੰ ਪੈਰਾਮੀਟਰ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ. ਇਸ ਕੇਸ ਵਿੱਚ, "ਬਾਹਰੀ ਤਾਪਮਾਨ".

ਇੱਕ ਬੁਲੀਅਨ ਵੇਰੀਏਬਲ ਦੂਜੀ ਪੋਰਟ ਨੂੰ ਸਪਲਾਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਜਾਂਚ ਕਰਨ ਲਈ ਸ਼ਰਤ।

ਜੇਕਰ ਦੂਜੇ ਇੰਪੁੱਟ 'ਤੇ TRUE (1) ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਬਲਾਕ ਇੱਕ ਲੋੜ ਦੀ ਪੁਸ਼ਟੀਕਰਨ ਗਣਨਾ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਦੂਜਾ ਇੰਪੁੱਟ FALSE (0) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੈਸਟ ਦੀਆਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਗਣਨਾ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾ ਸਕੇ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਸ ਇੰਪੁੱਟ ਦੀ ਵਰਤੋਂ ਮਾਡਲ ਦੀ ਸਥਿਤੀ ਦੇ ਅਧਾਰ ਤੇ ਜਾਂਚ ਨੂੰ ਸਮਰੱਥ ਜਾਂ ਅਯੋਗ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਜਹਾਜ਼ ਸਿਮੂਲੇਸ਼ਨ ਦੌਰਾਨ ਜ਼ਮੀਨ 'ਤੇ ਹੈ, ਤਾਂ ਫਲਾਈਟ ਨਾਲ ਸਬੰਧਤ ਲੋੜਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਅਤੇ ਉਲਟ - ਜੇ ਜਹਾਜ਼ ਉਡਾਣ ਵਿੱਚ ਹੈ, ਤਾਂ ਸਟੈਂਡ 'ਤੇ ਸੰਚਾਲਨ ਨਾਲ ਸਬੰਧਤ ਲੋੜਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।

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

ਇਸ ਬਲਾਕ ਦੇ ਪੈਰਾਮੀਟਰ ਹਨ:

• ਸੀਮਾ ਸ਼ਰਤਾਂ: ਉਪਰਲੀ (ਉੱਪਰ ਸੀਮਾ) ਅਤੇ ਹੇਠਲੀ (ਡਾਊਨ ਲਿਮਿਟ) ਰੇਂਜ ਸੀਮਾਵਾਂ ਜਿਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ;
• ਸੀਮਾ ਰੇਂਜਾਂ (ਟਾਈਮ ਇੰਟਰਵਲ) 'ਤੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਲੋੜੀਂਦਾ ਸਿਸਟਮ ਐਕਸਪੋਜ਼ਰ ਸਮਾਂ;
• ਬੇਨਤੀ ID ReqName;
• ਰੇਂਜ Out_range ਨੂੰ ਪਾਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਇੱਕ ਬੂਲੀਅਨ ਵੇਰੀਏਬਲ ਹੈ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਜਾਂਚ ਕੀਤੀ ਰੇਂਜ ਤੋਂ ਵੱਧ ਮੁੱਲ ਲੋੜ ਦੀ ਉਲੰਘਣਾ ਹੈ।

ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਟੈਸਟ ਵੈਲਯੂ ਆਉਟਪੁੱਟ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਸਿਸਟਮ ਵਿੱਚ ਕੁਝ ਹਾਸ਼ੀਏ ਹਨ ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਆਪਣੀ ਓਪਰੇਟਿੰਗ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਦੂਜੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇੱਕ ਆਉਟਪੁੱਟ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਸੈੱਟਪੁਆਇੰਟ ਨੂੰ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰੱਖਣ ਵਿੱਚ ਅਸਮਰੱਥ ਹੈ।

ਚਿੱਤਰ 6. ਡਾਇਗ੍ਰਾਮ ਅਤੇ ਇਸਦੇ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਇੱਕ ਖਾਸ ਜਾਇਦਾਦ ਜਾਂਚ ਬਲਾਕ।

ਇਸ ਬਲਾਕ ਦੀ ਗਣਨਾ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਨਤੀਜਾ ਵੇਰੀਏਬਲ ਆਉਟਪੁੱਟ 'ਤੇ ਬਣਦਾ ਹੈ, ਜੋ ਹੇਠਾਂ ਦਿੱਤੇ ਮੁੱਲਾਂ ਨੂੰ ਲੈਂਦਾ ਹੈ:

• 0 - rNone, ਮੁੱਲ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ;
• 1 - rDone, ਲੋੜ ਪੂਰੀ ਹੋ ਗਈ ਹੈ;
• 2 - rFault, ਲੋੜ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

ਬਲਾਕ ਚਿੱਤਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਪਛਾਣਕਰਤਾ ਟੈਕਸਟ;
• ਮਾਪ ਸੀਮਾ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਡਿਜੀਟਲ ਡਿਸਪਲੇ;
• ਪੈਰਾਮੀਟਰ ਸਥਿਤੀ ਦਾ ਰੰਗ ਪਛਾਣਕਰਤਾ।

ਬਲਾਕ ਦੇ ਅੰਦਰ ਇੱਕ ਗੁੰਝਲਦਾਰ ਲਾਜ਼ੀਕਲ ਇਨਫਰੈਂਸ ਸਰਕਟ ਹੋ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਚਿੱਤਰ 6 ਵਿੱਚ ਦਿਖਾਈ ਗਈ ਯੂਨਿਟ ਦੀ ਓਪਰੇਟਿੰਗ ਤਾਪਮਾਨ ਰੇਂਜ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਅੰਦਰੂਨੀ ਸਰਕਟ ਚਿੱਤਰ 7 ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।

ਚਿੱਤਰ 7. ਤਾਪਮਾਨ ਰੇਂਜ ਨਿਰਧਾਰਨ ਯੂਨਿਟ ਦਾ ਅੰਦਰੂਨੀ ਚਿੱਤਰ।

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

ਗਣਨਾ ਦੇ ਨਤੀਜੇ ਬਲਾਕ ਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਆਮ ਰਿਪੋਰਟ ਫਾਈਲ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਅਧਾਰ ਤੇ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। (ਚਿੱਤਰ 8 ਦੇਖੋ)

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

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

ਗਣਨਾ ਦੇ ਨਤੀਜੇ ਬਲਾਕ ਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਆਮ ਰਿਪੋਰਟ ਫਾਈਲ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਅਧਾਰ ਤੇ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। (ਚਿੱਤਰ 8 ਦੇਖੋ)

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

ਚਿੱਤਰ 8. ਸਿਮੂਲੇਸ਼ਨ ਨਤੀਜਿਆਂ 'ਤੇ ਆਧਾਰਿਤ ਰਿਪੋਰਟ ਫਾਈਲ ਦੀ ਉਦਾਹਰਨ।

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

ਚਿੱਤਰ 9. ਗਲੋਬਲ ਪ੍ਰੋਜੈਕਟ ਸਿਗਨਲਾਂ ਵਿੱਚ ਰਿਪੋਰਟ ਫਾਰਮੈਟ ਸੈੱਟ ਕਰਨਾ

ਲੋੜਾਂ ਲਈ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ.

ਸੰਪੱਤੀ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਲਈ, ਹਰੇਕ ਆਮ ਬਲਾਕ ਲਈ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਮਿਆਰੀ ਢਾਂਚਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। (ਚਿੱਤਰ 10 ਦੇਖੋ)

ਚਿੱਤਰ 10. ਇੱਕ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲੋੜ ਚੈੱਕ ਬਲਾਕ ਦੀ ਬਣਤਰ ਦੀ ਉਦਾਹਰਨ।

ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

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

ਲੋੜਾਂ ਲਈ ਸਿਗਨਲ ਡਾਟਾਬੇਸ ਢਾਂਚੇ ਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਲੋੜਾਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਆਸਾਨੀ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਲੋੜਾਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਗੱਲਬਾਤ ਦਾ ਇੱਕ ਆਮ ਚਿੱਤਰ ਚਿੱਤਰ 11 ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ।

ਚਿੱਤਰ 11. ਲੋੜਾਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਦੇ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦਾ ਚਿੱਤਰ।

SimInTech ਟੈਸਟ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਲੋੜ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀ ਦੇ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਦਾ ਕ੍ਰਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

1. ਸੰਦਰਭ ਦੀਆਂ ਸ਼ਰਤਾਂ ਨੂੰ ਲੋੜਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ।
2. ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ ਜੋ ਤਕਨੀਕੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਗਣਿਤਿਕ ਮਾਡਲਿੰਗ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
3. ਚੁਣੀਆਂ ਗਈਆਂ ਲੋੜਾਂ ਦੇ ਗੁਣਾਂ ਨੂੰ ਮਿਆਰੀ ਬਲਾਕਾਂ (ਉਦਾਹਰਨ ਲਈ, ਅਧਿਕਤਮ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਤਾਪਮਾਨ) ਦੇ ਢਾਂਚੇ ਵਿੱਚ ਸਿਮਇਨਟੈਕ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
4. ਗਣਨਾ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਢਾਂਚੇ ਦੇ ਡੇਟਾ ਨੂੰ ਬਲਾਕ ਡਿਜ਼ਾਈਨ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਇੱਕ ਸਿਗਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
5. ਇੱਕ ਵਾਰ ਗਣਨਾ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਲੋੜਾਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਲੋੜਾਂ ਦੇ ਪੜਾਅ 3 ਤੋਂ 5 ਨੂੰ ਡਿਜ਼ਾਈਨ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਡਿਜ਼ਾਈਨ ਅਤੇ/ਜਾਂ ਲੋੜਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਤਬਦੀਲੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਦੁਬਾਰਾ ਜਾਂਚਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਿੱਟਾ

• ਸਿਸਟਮ ਦਾ ਬਣਾਇਆ ਪ੍ਰੋਟੋਟਾਈਪ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦੀ ਪਾਲਣਾ ਲਈ ਮੌਜੂਦਾ ਮਾਡਲਾਂ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਸਮੇਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਕਮੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਪ੍ਰਸਤਾਵਿਤ ਟੈਸਟਿੰਗ ਤਕਨਾਲੋਜੀ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਗਤੀਸ਼ੀਲ ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਗਤੀਸ਼ੀਲ ਮਾਡਲਾਂ ਲਈ ਵੀ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ SimInTech ਵਾਤਾਵਰਣ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਬੈਚ ਡੇਟਾ ਸੰਗਠਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਤੁਹਾਨੂੰ ਮਾਡਲ ਵਿਕਾਸ ਦੇ ਸਮਾਨਾਂਤਰ ਲੋੜਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੇ ਪੈਕੇਜ ਬਣਾਉਣ, ਜਾਂ ਮਾਡਲ ਵਿਕਾਸ ਲਈ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਜੋਂ ਇਹਨਾਂ ਪੈਕੇਜਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
• ਤਕਨਾਲੋਜੀ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਲਾਗਤਾਂ ਤੋਂ ਬਿਨਾਂ ਮੌਜੂਦਾ ਲੋੜਾਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਅੰਤ ਤੱਕ ਪੜ੍ਹਨ ਵਾਲਿਆਂ ਲਈ, ਪ੍ਰੋਟੋਟਾਈਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਦਿਖਾਉਣ ਵਾਲੇ ਵੀਡੀਓ ਦਾ ਲਿੰਕ।

ਸਰੋਤ: www.habr.com