ಡೈನಾಮಿಕ್ ಸಿಮ್ಯುಲೇಶನ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ 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 ಕೆಜಿ / ಗಂಗಿಂತ ಕಡಿಮೆಯಿಲ್ಲ.
6. ಸಲಕರಣೆ ವಿಭಾಗಗಳಲ್ಲಿನ ಗಾಳಿಯ ಉಷ್ಣತೆಯು 60ºС ಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.
7. ತಂಪಾಗಿಸುವ ಗಾಳಿಯಲ್ಲಿ ಉತ್ತಮವಾದ ಉಚಿತ ತೇವಾಂಶದ ಪ್ರಮಾಣವು ಒಣ ಗಾಳಿಯ 2 ಗ್ರಾಂ / ಕೆಜಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.

ಈ ಸೀಮಿತ ಅವಶ್ಯಕತೆಗಳ ನಡುವೆಯೂ ಸಹ, ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸಬೇಕಾದ ಕನಿಷ್ಠ ಎರಡು ವರ್ಗಗಳಿವೆ:

• ಸಿಸ್ಟಮ್ನ ಆಪರೇಟಿಂಗ್ ಷರತ್ತುಗಳಿಗೆ ಅಗತ್ಯತೆಗಳು (ಷರತ್ತುಗಳು 1-3);
• ಸಿಸ್ಟಮ್ಗೆ ಪ್ಯಾರಾಮೆಟ್ರಿಕ್ ಅವಶ್ಯಕತೆಗಳು (ಷರತ್ತುಗಳು 3-7).

ಸಿಸ್ಟಮ್ ಆಪರೇಟಿಂಗ್ ಷರತ್ತುಗಳ ಅವಶ್ಯಕತೆಗಳು
ಮಾಡೆಲಿಂಗ್ ಸಮಯದಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ವ್ಯವಸ್ಥೆಗೆ ಬಾಹ್ಯ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಗಡಿ ಪರಿಸ್ಥಿತಿಗಳು ಅಥವಾ ಸಾಮಾನ್ಯ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಪರಿಣಾಮವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.
ಡೈನಾಮಿಕ್ ಸಿಮ್ಯುಲೇಶನ್‌ನಲ್ಲಿ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಆಪರೇಟಿಂಗ್ ಷರತ್ತುಗಳನ್ನು ಸಿಮ್ಯುಲೇಶನ್ ಪ್ರಕ್ರಿಯೆಯು ಒಳಗೊಂಡಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.

ಪ್ಯಾರಾಮೆಟ್ರಿಕ್ ಸಿಸ್ಟಮ್ ಅಗತ್ಯತೆಗಳು
ಈ ಅವಶ್ಯಕತೆಗಳು ಸಿಸ್ಟಮ್ ಸ್ವತಃ ಒದಗಿಸಿದ ನಿಯತಾಂಕಗಳಾಗಿವೆ. ಮಾಡೆಲಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಾವು ಈ ನಿಯತಾಂಕಗಳನ್ನು ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶಗಳಾಗಿ ಪಡೆಯಬಹುದು ಮತ್ತು ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಲೆಕ್ಕಾಚಾರದಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಅವಶ್ಯಕತೆಗಳ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಕೋಡಿಂಗ್

ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗುವಂತೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾನದಂಡಗಳು ಪ್ರತಿ ಅವಶ್ಯಕತೆಗೆ ಗುರುತಿಸುವಿಕೆಯನ್ನು ನಿಯೋಜಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತವೆ. ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ನಿಯೋಜಿಸುವಾಗ, ಏಕೀಕೃತ ಕೋಡಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ.

ಆವಶ್ಯಕತೆಯ ಸಂಕೇತವು ಕೇವಲ ಅವಶ್ಯಕತೆಯ ಕ್ರಮಸಂಖ್ಯೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಒಂದು ಸಂಖ್ಯೆಯಾಗಿರಬಹುದು ಅಥವಾ ಇದು ಅವಶ್ಯಕತೆಯ ಪ್ರಕಾರದ ಕೋಡ್, ಸಿಸ್ಟಮ್ ಅಥವಾ ಯುನಿಟ್‌ಗೆ ಅದು ಅನ್ವಯಿಸುವ ಕೋಡ್, ಪ್ಯಾರಾಮೀಟರ್ ಕೋಡ್, ಸ್ಥಳ ಕೋಡ್ ಮತ್ತು ಇಂಜಿನಿಯರ್ ಇನ್ನೇನು ಊಹಿಸಬಹುದು. (ಎನ್ಕೋಡಿಂಗ್ ಬಳಕೆಗಾಗಿ ಲೇಖನವನ್ನು ನೋಡಿ)

ಕೋಡಿಂಗ್ ಅವಶ್ಯಕತೆಗಳ ಸರಳ ಉದಾಹರಣೆಯನ್ನು ಟೇಬಲ್ 1 ಒದಗಿಸುತ್ತದೆ.

1. ಅವಶ್ಯಕತೆಗಳ ಮೂಲದ ಕೋಡ್ R- ಅವಶ್ಯಕತೆಗಳು TK;
2. ಕೋಡ್ ಪ್ರಕಾರದ ಅವಶ್ಯಕತೆಗಳು ಇ - ಅವಶ್ಯಕತೆಗಳು - ಪರಿಸರ ನಿಯತಾಂಕಗಳು ಅಥವಾ ಆಪರೇಟಿಂಗ್ ಷರತ್ತುಗಳು
   ಎಸ್ - ಸಿಸ್ಟಮ್ ಒದಗಿಸಿದ ಅವಶ್ಯಕತೆಗಳು;
3. ವಿಮಾನ ಸ್ಥಿತಿ ಕೋಡ್ 0 - ಯಾವುದಾದರೂ, G - ನಿಲುಗಡೆ, F - ವಿಮಾನದಲ್ಲಿ;
4. ಭೌತಿಕ ಪ್ಯಾರಾಮೀಟರ್ ಟೈಪ್ ಕೋಡ್ ಟಿ - ತಾಪಮಾನ, ಪಿ - ಒತ್ತಡ, ಜಿ - ಹರಿವಿನ ಪ್ರಮಾಣ, ಆರ್ದ್ರತೆ ಎಚ್;
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. ಪರಿಶೀಲನಾ ಯೋಜನೆಯ ವಿನ್ಯಾಸದ ಉದಾಹರಣೆ.

ನಿಯಂತ್ರಣ ಕ್ರಮಾವಳಿಗಳಂತೆಯೇ, ಅಗತ್ಯತೆಗಳನ್ನು ಹಾಳೆಗಳ ಗುಂಪಾಗಿ ರಚಿಸಬಹುದು. SimInTech, Simulink, AmeSim ನಂತಹ ರಚನಾತ್ಮಕ ಮಾಡೆಲಿಂಗ್ ಪರಿಸರದಲ್ಲಿ ಅಲ್ಗಾರಿದಮ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅನುಕೂಲಕ್ಕಾಗಿ, ಉಪಮಾಡೆಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಬಹು-ಹಂತದ ರಚನೆಗಳನ್ನು ರಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ನಿಯಂತ್ರಣ ಅಲ್ಗಾರಿದಮ್‌ಗಳಿಗಾಗಿ ಮಾಡಿದಂತೆ, ಅವಶ್ಯಕತೆಗಳ ಒಂದು ಶ್ರೇಣಿಯೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸರಳೀಕರಿಸಲು ವಿವಿಧ ಅವಶ್ಯಕತೆಗಳನ್ನು ಗುಂಪುಗಳಾಗಿ ಗುಂಪು ಮಾಡಲು ಈ ಸಂಸ್ಥೆಯು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ (ಚಿತ್ರ 2 ನೋಡಿ).

ಚಿತ್ರ 2. ಅಗತ್ಯತೆಗಳ ಪರಿಶೀಲನೆ ಮಾದರಿಯ ಕ್ರಮಾನುಗತ ರಚನೆ.

ಉದಾಹರಣೆಗೆ, ಪರಿಗಣನೆಯಲ್ಲಿರುವ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡು ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ: ಪರಿಸರದ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ನೇರವಾಗಿ ವ್ಯವಸ್ಥೆಗೆ ಅಗತ್ಯತೆಗಳು. ಆದ್ದರಿಂದ, ಎರಡು ಹಂತದ ಡೇಟಾ ರಚನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ಎರಡು ಗುಂಪುಗಳು, ಪ್ರತಿಯೊಂದೂ ಅಲ್ಗಾರಿದಮ್ನ ಎಲೆಯಾಗಿದೆ.

ಮಾದರಿಗೆ ಡೇಟಾವನ್ನು ಸಂಪರ್ಕಿಸಲು, ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಪ್ರಮಾಣಿತ ಯೋಜನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಯೋಜನೆಯ ಭಾಗಗಳ ನಡುವೆ ವಿನಿಮಯಕ್ಕಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ರಚಿಸುವಾಗ ಮತ್ತು ಪರೀಕ್ಷಿಸುವಾಗ, ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯಿಂದ ಬಳಸಲಾಗುವ ಸಂವೇದಕಗಳ ವಾಚನಗೋಷ್ಠಿಗಳು (ನೈಜ ಸಿಸ್ಟಮ್ ಸಂವೇದಕಗಳ ಸಾದೃಶ್ಯಗಳು) ಈ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.
ಪರೀಕ್ಷಾ ಯೋಜನೆಗಾಗಿ, ಡೈನಾಮಿಕ್ ಮಾದರಿಯಲ್ಲಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾದ ಯಾವುದೇ ನಿಯತಾಂಕಗಳನ್ನು ಅದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಹೀಗಾಗಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡೈನಾಮಿಕ್ ಮಾದರಿಯನ್ನು ಯಾವುದೇ ಗಣಿತದ ಮಾದರಿ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಪ್ರೋಗ್ರಾಂ ರೂಪದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಬಾಹ್ಯ ಪರಿಸರಕ್ಕೆ ಮಾಡೆಲಿಂಗ್ ಡೇಟಾವನ್ನು ನೀಡಲು ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಉಪಸ್ಥಿತಿಯು ಏಕೈಕ ಅವಶ್ಯಕತೆಯಾಗಿದೆ.

ಚಿತ್ರ 3. ಪರಿಶೀಲನಾ ಯೋಜನೆಯನ್ನು ಸಂಕೀರ್ಣ ಮಾದರಿಗೆ ಸಂಪರ್ಕಿಸಲಾಗುತ್ತಿದೆ.

ಮೂಲಭೂತ ಅವಶ್ಯಕತೆಗಳ ಪರಿಶೀಲನಾ ಹಾಳೆಯ ಉದಾಹರಣೆಯನ್ನು ಚಿತ್ರ 4 ರಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ. ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಲೆಕ್ಕಾಚಾರದ ರೇಖಾಚಿತ್ರವಾಗಿದ್ದು, ಅಗತ್ಯತೆಗಳ ಪರಿಶೀಲನೆ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಸಚಿತ್ರವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗುತ್ತದೆ.

ಚಿತ್ರ 4. ಅವಶ್ಯಕತೆಗಳ ಚೆಕ್ ಶೀಟ್.

ಚೆಕ್ ಶೀಟ್‌ನ ಮುಖ್ಯ ಭಾಗಗಳನ್ನು ಚಿತ್ರ 5 ರಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. ನಿಯಂತ್ರಣ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ವಿನ್ಯಾಸ ರೇಖಾಚಿತ್ರಗಳಂತೆಯೇ ಚೆಕ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ಬಲಭಾಗದಲ್ಲಿ ಡೇಟಾಬೇಸ್ನಿಂದ ಸಂಕೇತಗಳನ್ನು ಓದಲು ಒಂದು ಬ್ಲಾಕ್ ಇದೆ. ಸಿಮ್ಯುಲೇಶನ್ ಸಮಯದಲ್ಲಿ ಈ ಬ್ಲಾಕ್ ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ.

ಸ್ವೀಕರಿಸಿದ ಸಂಕೇತಗಳನ್ನು ಅವಶ್ಯಕತೆಗಳ ಪರಿಶೀಲನಾ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಮಾನದ ಸ್ಥಾನವನ್ನು ನಿರ್ಧರಿಸಲು ಎತ್ತರದ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ (ಅದು ನಿಲುಗಡೆ ಅಥವಾ ಹಾರಾಟದಲ್ಲಿದೆ). ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನೀವು ಇತರ ಸಂಕೇತಗಳನ್ನು ಮತ್ತು ಮಾದರಿಯ ಲೆಕ್ಕಾಚಾರದ ನಿಯತಾಂಕಗಳನ್ನು ಬಳಸಬಹುದು.

ಪರಿಶೀಲಿಸಲಾದ ಪರಿಶೀಲನಾ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ನಿಯತಾಂಕಗಳನ್ನು ಪ್ರಮಾಣಿತ ಪರಿಶೀಲನಾ ಬ್ಲಾಕ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಅವಶ್ಯಕತೆಗಳ ಅನುಸರಣೆಗಾಗಿ ಈ ನಿಯತಾಂಕಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ. ಫಲಿತಾಂಶಗಳನ್ನು ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರಿಶೀಲನಾಪಟ್ಟಿಯನ್ನು ರಚಿಸಲು ಬಳಸಬಹುದು.

ಚಿತ್ರ 5. ಅವಶ್ಯಕತೆಗಳ ಪರಿಶೀಲನೆ ಲೆಕ್ಕಾಚಾರದ ಹಾಳೆಯ ರಚನೆ.

ಪರೀಕ್ಷಿಸಬೇಕಾದ ನಿಯತಾಂಕಗಳು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಸಂಕೇತಗಳನ್ನು ಅಗತ್ಯವಾಗಿ ಬಳಸುವುದಿಲ್ಲ, ಸಿಮ್ಯುಲೇಶನ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾದ ನಿಯತಾಂಕಗಳಿಂದ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ. ಕರಡು ಅಗತ್ಯತೆಗಳ ಚೌಕಟ್ಟಿನೊಳಗೆ ಹೆಚ್ಚುವರಿ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಕೈಗೊಳ್ಳುವುದರಿಂದ ಯಾವುದೂ ನಮ್ಮನ್ನು ತಡೆಯುವುದಿಲ್ಲ, ನಾವು ಪರಿಶೀಲನಾ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ.

ಉದಾಹರಣೆಗೆ, ಈ ಅವಶ್ಯಕತೆ:

ಗುರಿಗೆ ಹಾರಾಟದ ಸಮಯದಲ್ಲಿ ತಿದ್ದುಪಡಿ ವ್ಯವಸ್ಥೆಯ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳ ಸಂಖ್ಯೆ 5 ಮೀರಬಾರದು ಮತ್ತು ತಿದ್ದುಪಡಿ ವ್ಯವಸ್ಥೆಯ ಒಟ್ಟು ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯವು 30 ಸೆಕೆಂಡುಗಳನ್ನು ಮೀರಬಾರದು.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರಾರಂಭಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಒಟ್ಟು ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯವನ್ನು ಎದುರಿಸಲು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅವಶ್ಯಕತೆಗಳ ವಿನ್ಯಾಸ ರೇಖಾಚಿತ್ರಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.

ವಿಶಿಷ್ಟ ಅವಶ್ಯಕತೆಗಳ ಪರಿಶೀಲನೆ ಬ್ಲಾಕ್.

ಪ್ರತಿ ಪ್ರಮಾಣಿತ ಅವಶ್ಯಕತೆಗಳ ಚೆಕ್ ಬಾಕ್ಸ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರದ ಅವಶ್ಯಕತೆಯ ನೆರವೇರಿಕೆಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಪರಿಸರದ ಅವಶ್ಯಕತೆಗಳು ನಿಲುಗಡೆ ಮಾಡುವಾಗ ಮತ್ತು ಹಾರಾಟದಲ್ಲಿ ಸುತ್ತುವರಿದ ಕಾರ್ಯಾಚರಣೆಯ ತಾಪಮಾನಗಳ ವ್ಯಾಪ್ತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಈ ಬ್ಲಾಕ್ ಮಾದರಿಯಲ್ಲಿನ ಗಾಳಿಯ ಉಷ್ಣತೆಯನ್ನು ಪ್ಯಾರಾಮೀಟರ್ ಆಗಿ ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಈ ಪ್ಯಾರಾಮೀಟರ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ತಾಪಮಾನ ಶ್ರೇಣಿಯನ್ನು ಆವರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು./p>

ಬ್ಲಾಕ್ ಎರಡು ಇನ್‌ಪುಟ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಪ್ಯಾರಮ್ ಮತ್ತು ಷರತ್ತು.

ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದರೊಂದಿಗೆ ಮೊದಲನೆಯದನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, "ಬಾಹ್ಯ ತಾಪಮಾನ".

ಬೂಲಿಯನ್ ವೇರಿಯೇಬಲ್ ಅನ್ನು ಎರಡನೇ ಪೋರ್ಟ್‌ಗೆ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ - ಚೆಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಸ್ಥಿತಿ.

ಎರಡನೇ ಇನ್‌ಪುಟ್‌ನಲ್ಲಿ TRUE (1) ಅನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ನಂತರ ಬ್ಲಾಕ್ ಅಗತ್ಯ ಪರಿಶೀಲನೆ ಲೆಕ್ಕಾಚಾರವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಎರಡನೇ ಇನ್‌ಪುಟ್ FALSE (0) ಅನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಪರೀಕ್ಷಾ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಲಾಗುವುದಿಲ್ಲ. ಲೆಕ್ಕಾಚಾರದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಮಾದರಿಯ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಚೆಕ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಅಥವಾ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಈ ಇನ್‌ಪುಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಸಿಮ್ಯುಲೇಶನ್ ಸಮಯದಲ್ಲಿ ವಿಮಾನವು ನೆಲದ ಮೇಲೆ ಇದ್ದರೆ, ನಂತರ ಹಾರಾಟಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿಯಾಗಿ - ವಿಮಾನವು ಹಾರಾಟದಲ್ಲಿದ್ದರೆ, ನಂತರ ಸ್ಟ್ಯಾಂಡ್ನಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ.

ಮಾದರಿಯನ್ನು ಹೊಂದಿಸುವಾಗ ಈ ಇನ್ಪುಟ್ ಅನ್ನು ಸಹ ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ ಲೆಕ್ಕಾಚಾರದ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ. ಮಾದರಿಯನ್ನು ಅಗತ್ಯವಿರುವ ಸ್ಥಿತಿಗೆ ತಂದಾಗ, ಚೆಕ್ ಬ್ಲಾಕ್ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಸಿಸ್ಟಮ್ ಅಗತ್ಯವಿರುವ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಅನ್ನು ತಲುಪಿದ ತಕ್ಷಣ, ಚೆಕ್ ಬ್ಲಾಕ್ಗಳನ್ನು ಆನ್ ಮಾಡಲಾಗುತ್ತದೆ.

ಈ ಬ್ಲಾಕ್ನ ನಿಯತಾಂಕಗಳು:

• ಗಡಿ ಪರಿಸ್ಥಿತಿಗಳು: ಮೇಲಿನ (UpLimit) ಮತ್ತು ಕೆಳಗಿನ (DownLimit) ವ್ಯಾಪ್ತಿಯ ಮಿತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು;
• ಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಗಡಿ ಶ್ರೇಣಿಗಳಲ್ಲಿ (ಟೈಮ್‌ಇಂಟರ್ವಾಲ್) ಅಗತ್ಯವಿರುವ ಸಿಸ್ಟಮ್ ಎಕ್ಸ್ಪೋಸರ್ ಸಮಯ;
• ವಿನಂತಿ ID ReqName;
• ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರುವ ಅನುಮತಿ Out_range ಎಂಬುದು ಬೂಲಿಯನ್ ವೇರಿಯೇಬಲ್ ಆಗಿದ್ದು ಅದು ಪರಿಶೀಲಿಸಿದ ಶ್ರೇಣಿಯನ್ನು ಮೀರಿದ ಮೌಲ್ಯವು ಅವಶ್ಯಕತೆಯ ಉಲ್ಲಂಘನೆಯಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪರೀಕ್ಷಾ ಮೌಲ್ಯದ ಔಟ್‌ಪುಟ್ ಸಿಸ್ಟಮ್ ಕೆಲವು ಅಂಚುಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅದರ ಕಾರ್ಯ ವ್ಯಾಪ್ತಿಯ ಹೊರಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಬಹುದು ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಔಟ್‌ಪುಟ್ ಎಂದರೆ ಸಿಸ್ಟಮ್‌ಗೆ ಸೆಟ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಇರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಚಿತ್ರ 6. ರೇಖಾಚಿತ್ರ ಮತ್ತು ಅದರ ನಿಯತಾಂಕಗಳಲ್ಲಿ ವಿಶಿಷ್ಟವಾದ ಆಸ್ತಿ ಚೆಕ್ ಬ್ಲಾಕ್.

ಈ ಬ್ಲಾಕ್ನ ಲೆಕ್ಕಾಚಾರದ ಪರಿಣಾಮವಾಗಿ, ಫಲಿತಾಂಶದ ವೇರಿಯಬಲ್ ಔಟ್ಪುಟ್ನಲ್ಲಿ ರೂಪುಗೊಳ್ಳುತ್ತದೆ, ಅದು ಈ ಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

• 0 - rNone, ಮೌಲ್ಯವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ;
• 1 - rDone, ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲಾಗಿದೆ;
• 2 - rFault, ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲಾಗಿಲ್ಲ.

ಬ್ಲಾಕ್ ಚಿತ್ರವು ಒಳಗೊಂಡಿದೆ:

• ಗುರುತಿಸುವ ಪಠ್ಯ;
• ಅಳತೆ ಮಿತಿಗಳ ನಿಯತಾಂಕಗಳ ಡಿಜಿಟಲ್ ಪ್ರದರ್ಶನಗಳು;
• ಪ್ಯಾರಾಮೀಟರ್ ಸ್ಥಿತಿಯ ಬಣ್ಣ ಗುರುತಿಸುವಿಕೆ.

ಬ್ಲಾಕ್ ಒಳಗೆ ಬದಲಿಗೆ ಸಂಕೀರ್ಣ ತಾರ್ಕಿಕ ನಿರ್ಣಯ ಸರ್ಕ್ಯೂಟ್ ಇರಬಹುದು.

ಉದಾಹರಣೆಗೆ, ಚಿತ್ರ 6 ರಲ್ಲಿ ತೋರಿಸಿರುವ ಘಟಕದ ಕಾರ್ಯಾಚರಣಾ ತಾಪಮಾನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು, ಆಂತರಿಕ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಚಿತ್ರ 7 ರಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ.

ಚಿತ್ರ 7. ತಾಪಮಾನ ಶ್ರೇಣಿಯ ನಿರ್ಣಯ ಘಟಕದ ಆಂತರಿಕ ರೇಖಾಚಿತ್ರ.

ಸರ್ಕ್ಯೂಟ್ ಬ್ಲಾಕ್ನ ಒಳಗೆ, ಬ್ಲಾಕ್ ನಿಯತಾಂಕಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಅವಶ್ಯಕತೆಗಳ ಅನುಸರಣೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವುದರ ಜೊತೆಗೆ, ಬ್ಲಾಕ್‌ನ ಆಂತರಿಕ ರೇಖಾಚಿತ್ರವು ಸಿಮ್ಯುಲೇಶನ್ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಅಗತ್ಯವಾದ ಗ್ರಾಫ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಲೆಕ್ಕಾಚಾರದ ಸಮಯದಲ್ಲಿ ವೀಕ್ಷಿಸಲು ಮತ್ತು ಲೆಕ್ಕಾಚಾರದ ನಂತರ ಫಲಿತಾಂಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಈ ಗ್ರಾಫ್ ಅನ್ನು ಬಳಸಬಹುದು.

ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶಗಳನ್ನು ಬ್ಲಾಕ್‌ನ ಔಟ್‌ಪುಟ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ವರದಿ ಫೈಲ್‌ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ಸಂಪೂರ್ಣ ಯೋಜನೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ರಚಿಸಲಾಗುತ್ತದೆ. (ಚಿತ್ರ 8 ನೋಡಿ)

ಸಿಮ್ಯುಲೇಶನ್ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ರಚಿಸಲಾದ ವರದಿಯ ಉದಾಹರಣೆಯೆಂದರೆ ಕೊಟ್ಟಿರುವ ಸ್ವರೂಪದ ಪ್ರಕಾರ ರಚಿಸಲಾದ html ಫೈಲ್. ನಿರ್ದಿಷ್ಟ ಸಂಸ್ಥೆಯು ಸ್ವೀಕರಿಸಿದ ಸ್ವರೂಪಕ್ಕೆ ಸ್ವರೂಪವನ್ನು ನಿರಂಕುಶವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಸರ್ಕ್ಯೂಟ್ ಬ್ಲಾಕ್ನ ಒಳಗೆ, ಬ್ಲಾಕ್ ನಿಯತಾಂಕಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಅವಶ್ಯಕತೆಗಳ ಅನುಸರಣೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವುದರ ಜೊತೆಗೆ, ಬ್ಲಾಕ್‌ನ ಆಂತರಿಕ ರೇಖಾಚಿತ್ರವು ಸಿಮ್ಯುಲೇಶನ್ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಅಗತ್ಯವಾದ ಗ್ರಾಫ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಲೆಕ್ಕಾಚಾರದ ಸಮಯದಲ್ಲಿ ವೀಕ್ಷಿಸಲು ಮತ್ತು ಲೆಕ್ಕಾಚಾರದ ನಂತರ ಫಲಿತಾಂಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಈ ಗ್ರಾಫ್ ಅನ್ನು ಬಳಸಬಹುದು.

ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶಗಳನ್ನು ಬ್ಲಾಕ್‌ನ ಔಟ್‌ಪುಟ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ವರದಿ ಫೈಲ್‌ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ಸಂಪೂರ್ಣ ಯೋಜನೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ರಚಿಸಲಾಗುತ್ತದೆ. (ಚಿತ್ರ 8 ನೋಡಿ)

ಸಿಮ್ಯುಲೇಶನ್ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ರಚಿಸಲಾದ ವರದಿಯ ಉದಾಹರಣೆಯೆಂದರೆ ಕೊಟ್ಟಿರುವ ಸ್ವರೂಪದ ಪ್ರಕಾರ ರಚಿಸಲಾದ html ಫೈಲ್. ನಿರ್ದಿಷ್ಟ ಸಂಸ್ಥೆಯು ಸ್ವೀಕರಿಸಿದ ಸ್ವರೂಪಕ್ಕೆ ಸ್ವರೂಪವನ್ನು ನಿರಂಕುಶವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಚಿತ್ರ 8. ಸಿಮ್ಯುಲೇಶನ್ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ವರದಿ ಫೈಲ್‌ನ ಉದಾಹರಣೆ.

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ವರದಿ ಫಾರ್ಮ್ ಅನ್ನು ನೇರವಾಗಿ ಪ್ರಾಜೆಕ್ಟ್ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಟೇಬಲ್‌ನಲ್ಲಿನ ಸ್ವರೂಪವನ್ನು ಜಾಗತಿಕ ಪ್ರಾಜೆಕ್ಟ್ ಸಿಗ್ನಲ್‌ಗಳಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, SimInTech ಸ್ವತಃ ವರದಿಯನ್ನು ಹೊಂದಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಫೈಲ್‌ಗೆ ಫಲಿತಾಂಶಗಳನ್ನು ಬರೆಯುವ ಬ್ಲಾಕ್ ವರದಿ ಫೈಲ್‌ಗೆ ಬರೆಯಲು ಈ ಸಾಲುಗಳನ್ನು ಬಳಸುತ್ತದೆ.

ಚಿತ್ರ 9. ಜಾಗತಿಕ ಪ್ರಾಜೆಕ್ಟ್ ಸಿಗ್ನಲ್‌ಗಳಲ್ಲಿ ವರದಿ ಸ್ವರೂಪವನ್ನು ಹೊಂದಿಸುವುದು

ಅವಶ್ಯಕತೆಗಳಿಗಾಗಿ ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುವುದು.

ಆಸ್ತಿ ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು, ಪ್ರತಿ ವಿಶಿಷ್ಟ ಬ್ಲಾಕ್ಗೆ ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಪ್ರಮಾಣಿತ ರಚನೆಯನ್ನು ರಚಿಸಲಾಗಿದೆ. (ಚಿತ್ರ 10 ನೋಡಿ)

ಚಿತ್ರ 10. ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅವಶ್ಯಕತೆ ಚೆಕ್ ಬ್ಲಾಕ್‌ನ ರಚನೆಯ ಉದಾಹರಣೆ.

ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ ಒದಗಿಸುತ್ತದೆ:

• ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಅಗತ್ಯತೆಗಳ ನಿಯತಾಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು.
• ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಪ್ರಸ್ತುತ ಮಾಡೆಲಿಂಗ್ ಫಲಿತಾಂಶಗಳಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯೋಜನೆಯ ಅಗತ್ಯತೆಗಳ ಅನುಕೂಲಕರ ವೀಕ್ಷಣೆ.
• ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಬ್ಲಾಕ್ ಅಥವಾ ಬ್ಲಾಕ್‌ಗಳ ಗುಂಪನ್ನು ಹೊಂದಿಸುವುದು. ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ರೇಖಾಚಿತ್ರದಲ್ಲಿನ ಬ್ಲಾಕ್ ಆಸ್ತಿ ಮೌಲ್ಯಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ.
• ಅಗತ್ಯ ನಿರ್ವಹಣೆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಪಠ್ಯ ವಿವರಣೆಗಳು, ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಐಟಂಗಳು ಅಥವಾ ಗುರುತಿಸುವಿಕೆಗಳಿಗೆ ಲಿಂಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು.

ಅವಶ್ಯಕತೆಗಳಿಗಾಗಿ ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ ರಚನೆಗಳನ್ನು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅವಶ್ಯಕತೆಗಳ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಅವಶ್ಯಕತೆಗಳ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಸಾಮಾನ್ಯ ರೇಖಾಚಿತ್ರವನ್ನು ಚಿತ್ರ 11 ರಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ.

ಚಿತ್ರ 11. ಅವಶ್ಯಕತೆಗಳ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ರೇಖಾಚಿತ್ರ.

SimInTech ಪರೀಕ್ಷಾ ಯೋಜನೆ ಮತ್ತು ಅವಶ್ಯಕತೆ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಅನುಕ್ರಮವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:

1. ಉಲ್ಲೇಖದ ನಿಯಮಗಳನ್ನು ಅವಶ್ಯಕತೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.
2. ತಾಂತ್ರಿಕ ಪ್ರಕ್ರಿಯೆಗಳ ಗಣಿತದ ಮಾದರಿಯ ಮೂಲಕ ಪರಿಶೀಲಿಸಬಹುದಾದ ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಅವಶ್ಯಕತೆಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ.
3. ಆಯ್ದ ಅವಶ್ಯಕತೆಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರಮಾಣಿತ ಬ್ಲಾಕ್ಗಳ ರಚನೆಯಲ್ಲಿ SimInTech ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಗರಿಷ್ಠ ಮತ್ತು ಕನಿಷ್ಠ ತಾಪಮಾನ).
4. ಲೆಕ್ಕಾಚಾರದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ರಚನೆಯ ಡೇಟಾವನ್ನು ಬ್ಲಾಕ್ ವಿನ್ಯಾಸ ರೇಖಾಚಿತ್ರಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಸಿಗ್ನಲ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
5. ಲೆಕ್ಕಾಚಾರವು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳನ್ನು ಅಗತ್ಯ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.

ವಿನ್ಯಾಸ ಮತ್ತು/ಅಥವಾ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಾಗ ಮತ್ತು ಬದಲಾವಣೆಗಳ ಪರಿಣಾಮವನ್ನು ಮರುಪರೀಕ್ಷೆ ಮಾಡಬೇಕಾದಾಗ ವಿನ್ಯಾಸ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ 3 ರಿಂದ 5 ರ ಅಗತ್ಯತೆಗಳ ಹಂತಗಳನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು.

ತೀರ್ಮಾನಗಳು.

• ಸಿಸ್ಟಮ್ನ ರಚಿಸಿದ ಮೂಲಮಾದರಿಯು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಅಗತ್ಯತೆಗಳ ಅನುಸರಣೆಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾದರಿಗಳ ವಿಶ್ಲೇಷಣೆಯ ಸಮಯದಲ್ಲಿ ಗಮನಾರ್ಹವಾದ ಕಡಿತವನ್ನು ಒದಗಿಸುತ್ತದೆ.
• ಪ್ರಸ್ತಾವಿತ ಪರೀಕ್ಷಾ ತಂತ್ರಜ್ಞಾನವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೈನಾಮಿಕ್ ಮಾದರಿಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು SimInTech ಪರಿಸರದಲ್ಲಿ ನಿರ್ವಹಿಸದಂತಹ ಯಾವುದೇ ಕ್ರಿಯಾತ್ಮಕ ಮಾದರಿಗಳಿಗೆ ಸಹ ಬಳಸಬಹುದು.
• ಬ್ಯಾಚ್ ಡೇಟಾ ಸಂಘಟನೆಯನ್ನು ಬಳಸುವುದರಿಂದ ಮಾದರಿ ಅಭಿವೃದ್ಧಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಅವಶ್ಯಕತೆಗಳ ಪರಿಶೀಲನೆ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅಥವಾ ಮಾದರಿ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಈ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳಾಗಿಯೂ ಸಹ ಬಳಸಿ.
• ಗಮನಾರ್ಹ ವೆಚ್ಚಗಳಿಲ್ಲದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅವಶ್ಯಕತೆಗಳ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ತಂತ್ರಜ್ಞಾನವನ್ನು ಸಂಯೋಜಿಸಬಹುದು.

ಕೊನೆಯವರೆಗೂ ಓದುವವರಿಗೆ, ಮೂಲಮಾದರಿಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ವೀಡಿಯೊಗೆ ಲಿಂಕ್ ಮಾಡಿ.

ಮೂಲ: www.habr.com