ການກວດສອບອັດຕະໂນມັດຂອງຄວາມຕ້ອງການສະເພາະດ້ານວິຊາການໃນລະຫວ່າງການສ້າງແບບຈໍາລອງແບບເຄື່ອນໄຫວ

ສືບຕໍ່ຫົວຂໍ້ "ຫຼັກຖານຂອງເຈົ້າແມ່ນຫຍັງ?", ໃຫ້ເບິ່ງບັນຫາຂອງການສ້າງແບບຈໍາລອງທາງຄະນິດສາດຈາກອີກດ້ານຫນຶ່ງ. ຫຼັງ​ຈາກ​ເຮົາ​ໝັ້ນ​ໃຈ​ວ່າ​ຕົວ​ແບບ​ນັ້ນ​ສອດ​ຄ່ອງ​ກັບ​ຄວາມ​ຈິງ​ຂອງ​ຊີວິດ​ໃນ​ບ້ານ​ເຮືອນ, ເຮົາ​ສາມາດ​ຕອບ​ຄຳ​ຖາມ​ຕົ້ນ​ຕໍ​ວ່າ: “ເຮົາ​ມີ​ຫຍັງ​ຢູ່​ທີ່​ນີ້?” ເມື່ອສ້າງແບບຈໍາລອງຂອງວັດຖຸດ້ານວິຊາການ, ພວກເຮົາມັກຈະຕ້ອງການໃຫ້ແນ່ໃຈວ່າວັດຖຸນີ້ຈະຕອບສະຫນອງຄວາມຄາດຫວັງຂອງພວກເຮົາ. ສໍາລັບຈຸດປະສົງນີ້, ການຄິດໄລ່ແບບເຄື່ອນໄຫວຂອງຂະບວນການແມ່ນດໍາເນີນແລະຜົນໄດ້ຮັບແມ່ນປຽບທຽບກັບຄວາມຕ້ອງການ. ນີ້ແມ່ນຄູ່ແຝດດິຈິຕອນ, ຕົ້ນແບບສະເໝືອນ, ແລະອື່ນໆ. guys ຄົນອັບເດດ: ພຽງເລັກນ້ອຍຜູ້ທີ່, ໃນຂັ້ນຕອນຂອງການອອກແບບ, ແກ້ໄຂບັນຫາຂອງວິທີການເພື່ອເຮັດໃຫ້ແນ່ໃຈວ່າພວກເຮົາໄດ້ຮັບສິ່ງທີ່ພວກເຮົາວາງແຜນໄວ້.

ພວກເຮົາສາມາດເຮັດແນວໃດເພື່ອໃຫ້ແນ່ໃຈວ່າລະບົບຂອງພວກເຮົາແມ່ນສິ່ງທີ່ພວກເຮົາອອກແບບ, ການອອກແບບຂອງພວກເຮົາຈະບິນຫຼືລອຍ? ແລະຖ້າມັນບິນ, ສູງເທົ່າໃດ? ແລະຖ້າມັນລອຍ, ເລິກເທົ່າໃດ?

ບົດຄວາມນີ້ປຶກສາຫາລືກ່ຽວກັບອັດຕະໂນມັດຂອງການກວດສອບການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງອາຄານດ້ານວິຊາການໃນເວລາທີ່ສ້າງແບບເຄື່ອນໄຫວຂອງລະບົບດ້ານວິຊາການ. ຕົວຢ່າງ, ໃຫ້ເບິ່ງອົງປະກອບຂອງສະເພາະດ້ານວິຊາການສໍາລັບລະບົບເຮັດຄວາມເຢັນທາງອາກາດຂອງເຮືອບິນ.

ພວກ​ເຮົາ​ພິ​ຈາ​ລະ​ນາ​ຂໍ້​ກໍາ​ນົດ​ເຫຼົ່າ​ນັ້ນ​ທີ່​ສາ​ມາດ​ສະ​ແດງ​ອອກ​ເປັນ​ຈໍາ​ນວນ​ແລະ​ການ​ກວດ​ສອບ​ທາງ​ຄະ​ນິດ​ສາດ​ໂດຍ​ອີງ​ໃສ່​ຮູບ​ແບບ​ການ​ຄິດ​ໄລ່​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​. ມັນເປັນທີ່ຊັດເຈນວ່ານີ້ແມ່ນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງຂໍ້ກໍານົດທົ່ວໄປສໍາລັບລະບົບດ້ານວິຊາການໃດກໍ່ຕາມ, ແຕ່ວ່າມັນແມ່ນຢູ່ໃນການກວດສອບພວກເຂົາວ່າພວກເຮົາໃຊ້ເວລາ, ເສັ້ນປະສາດແລະເງິນໃນການສ້າງແບບເຄື່ອນໄຫວຂອງວັດຖຸ.

ໃນເວລາທີ່ອະທິບາຍຄວາມຕ້ອງການດ້ານວິຊາການໃນຮູບແບບຂອງເອກະສານ, ຫຼາຍປະເພດຂອງຄວາມຕ້ອງການທີ່ແຕກຕ່າງກັນສາມາດຈໍາແນກໄດ້, ແຕ່ລະຄົນຮຽກຮ້ອງໃຫ້ມີວິທີການທີ່ແຕກຕ່າງກັນສໍາລັບການສ້າງຕັ້ງຂອງການກວດສອບອັດຕະໂນມັດຂອງການປະຕິບັດຕາມຄວາມຕ້ອງການ.

ສໍາລັບຕົວຢ່າງ, ພິຈາລະນາຊຸດຂໍ້ກໍາຫນົດຂະຫນາດນ້ອຍແຕ່ຈິງນີ້:

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 g / kg ຂອງອາກາດແຫ້ງ.

ເຖິງແມ່ນວ່າຢູ່ໃນຂໍ້ກໍານົດທີ່ຈໍາກັດນີ້, ມີຢ່າງຫນ້ອຍສອງປະເພດທີ່ຕ້ອງໄດ້ຮັບການປະຕິບັດທີ່ແຕກຕ່າງກັນໃນລະບົບ:

• ຂໍ້ກໍານົດສໍາລັບເງື່ອນໄຂການດໍາເນີນງານຂອງລະບົບ (ຂໍ້ 1-3);
• ຂໍ້ກໍານົດ parametric ສໍາລັບລະບົບ (ຂໍ້ 3-7).

ເງື່ອນໄຂການເຮັດວຽກຂອງລະບົບ
ເງື່ອນໄຂພາຍນອກສໍາລັບລະບົບທີ່ຖືກພັດທະນາໃນລະຫວ່າງການສ້າງແບບຈໍາລອງສາມາດຖືກກໍານົດເປັນເງື່ອນໄຂຊາຍແດນຫຼືເປັນຜົນມາຈາກການດໍາເນີນງານຂອງລະບົບທົ່ວໄປ.
ໃນການຈໍາລອງແບບເຄື່ອນໄຫວ, ມັນຈໍາເປັນຕ້ອງຮັບປະກັນວ່າເງື່ອນໄຂການດໍາເນີນງານທີ່ລະບຸໄວ້ແມ່ນກວມເອົາຂະບວນການຈໍາລອງ.

ຄວາມຕ້ອງການລະບົບ Parametric
ຄວາມຕ້ອງການເຫຼົ່ານີ້ແມ່ນຕົວກໍານົດການສະຫນອງໃຫ້ໂດຍລະບົບຕົວມັນເອງ. ໃນລະຫວ່າງຂະບວນການສ້າງແບບຈໍາລອງ, ພວກເຮົາສາມາດໄດ້ຮັບຕົວກໍານົດການເຫຼົ່ານີ້ເປັນຜົນການຄິດໄລ່ແລະໃຫ້ແນ່ໃຈວ່າຄວາມຕ້ອງການແມ່ນບັນລຸໄດ້ໃນແຕ່ລະການຄິດໄລ່ສະເພາະ.

ການກໍານົດຄວາມຕ້ອງການແລະການເຂົ້າລະຫັດ

ເພື່ອຄວາມສະດວກໃນການເຮັດວຽກກັບຄວາມຕ້ອງການ, ມາດຕະຖານທີ່ມີຢູ່ແລ້ວແນະນໍາໃຫ້ກໍານົດຕົວລະບຸກັບແຕ່ລະຄວາມຕ້ອງການ. ເມື່ອກໍານົດຕົວກໍານົດ, ມັນເປັນຄວາມປາຖະຫນາສູງທີ່ຈະໃຊ້ລະບົບການເຂົ້າລະຫັດແບບປະສົມປະສານ.

ລະຫັດຄວາມຕ້ອງການສາມາດເປັນຕົວເລກທີ່ສະແດງເຖິງຕົວເລກຄໍາສັ່ງຂອງຄວາມຕ້ອງການ, ຫຼືມັນສາມາດມີລະຫັດສໍາລັບປະເພດຂອງຄວາມຕ້ອງການ, ລະຫັດສໍາລັບລະບົບຫຼືຫນ່ວຍງານທີ່ມັນໃຊ້, ລະຫັດພາລາມິເຕີ, ລະຫັດສະຖານທີ່, ແລະ. ສິ່ງອື່ນໃດທີ່ວິສະວະກອນສາມາດຈິນຕະນາການໄດ້. (ເບິ່ງ​ບົດ​ຄວາມ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ການ​ເຂົ້າ​ລະ​ຫັດ​)

ຕາຕະລາງ 1 ສະຫນອງຕົວຢ່າງງ່າຍດາຍຂອງລະຫັດຂໍ້ກໍານົດ.

1. ລະຫັດແຫຼ່ງທີ່ມາຂອງຄວາມຕ້ອງການ R-requirements TK;
2. ລະຫັດປະເພດຂອງຂໍ້ກໍານົດ E - ຄວາມຕ້ອງການ - ຕົວກໍານົດການສະພາບແວດລ້ອມ, ຫຼືເງື່ອນໄຂການດໍາເນີນງານ
   S - ຄວາມຕ້ອງການສະຫນອງໃຫ້ໂດຍລະບົບ;
3. ລະຫັດສະຖານະເຮືອບິນ 0 – ໃດ, G – ຈອດ, F – ໃນການບິນ;
4. ລະຫັດປະເພດຕົວກໍານົດການທາງດ້ານຮ່າງກາຍ T – ອຸນຫະພູມ, P – ຄວາມກົດດັນ, G – ອັດຕາການໄຫຼ, ຄວາມຊຸ່ມຊື່ນ H;
5. ເລກລໍາດັບຂອງຄວາມຕ້ອງການ.

ID ຄວາມຕ້ອງການ	ລາຍ​ລະ​ອຽດ	Parameter
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 g / kg ຂອງອາກາດແຫ້ງ

ການອອກແບບລະບົບການກວດສອບຄວາມຕ້ອງການ.

ສໍາລັບຄວາມຕ້ອງການການອອກແບບແຕ່ລະຄົນມີສູດການຄິດໄລ່ສໍາລັບການປະເມີນການຕອບໂຕ້ຂອງຕົວກໍານົດການການອອກແບບແລະຕົວກໍານົດການລະບຸໄວ້ໃນຂໍ້ກໍານົດ. ໂດຍແລະຂະຫນາດໃຫຍ່, ລະບົບການຄວບຄຸມໃດໆສະເຫມີປະກອບດ້ວຍສູດການຄິດໄລ່ສໍາລັບການກວດສອບຄວາມຕ້ອງການໂດຍຄ່າເລີ່ມຕົ້ນ. ແລະເຖິງແມ່ນວ່າຜູ້ຄວບຄຸມໃດໆປະກອບດ້ວຍພວກມັນ. ຖ້າອຸນຫະພູມເກີນຂອບເຂດຈໍາກັດ, ເຄື່ອງປັບອາກາດຈະເປີດ. ດັ່ງນັ້ນ, ຂັ້ນຕອນທໍາອິດຂອງລະບຽບການໃດຫນຶ່ງແມ່ນການກວດສອບວ່າຕົວກໍານົດການຕອບສະຫນອງຄວາມຕ້ອງການ.

ແລະນັບຕັ້ງແຕ່ການກວດສອບເປັນສູດການຄິດໄລ່, ຫຼັງຈາກນັ້ນພວກເຮົາສາມາດນໍາໃຊ້ເຄື່ອງມືແລະເຄື່ອງມືດຽວກັນທີ່ພວກເຮົາໃຊ້ເພື່ອສ້າງໂປຼແກຼມຄວບຄຸມ. ຕົວຢ່າງ, ສະພາບແວດລ້ອມ SimInTech ຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດໂຄງການທີ່ມີສ່ວນຕ່າງໆຂອງຕົວແບບ, ປະຕິບັດໃນຮູບແບບໂຄງການແຍກຕ່າງຫາກ (ຮູບແບບວັດຖຸ, ຮູບແບບລະບົບການຄວບຄຸມ, ຮູບແບບສະພາບແວດລ້ອມ, ແລະອື່ນໆ).

ໂຄງການກວດສອບຄວາມຕ້ອງການໃນກໍລະນີນີ້ກາຍເປັນໂຄງການ algorithm ດຽວກັນແລະເຊື່ອມຕໍ່ກັບຊຸດແບບຈໍາລອງ. ແລະໃນແບບຈໍາລອງແບບໄດນາມິກມັນປະຕິບັດການວິເຄາະສໍາລັບການປະຕິບັດຕາມຄວາມຕ້ອງການຂອງຂໍ້ກໍານົດດ້ານວິຊາການ.

ຕົວຢ່າງທີ່ເປັນໄປໄດ້ຂອງການອອກແບບລະບົບແມ່ນສະແດງຢູ່ໃນຮູບທີ 1.

ຮູບທີ 1. ຕົວຢ່າງການອອກແບບໂຄງການກວດສອບ.

ຄືກັນກັບວິທີການຄວບຄຸມ, ຄວາມຕ້ອງການສາມາດຖືກແຕ້ມເປັນຊຸດຂອງແຜ່ນ. ເພື່ອຄວາມສະດວກໃນການເຮັດວຽກກັບ algorithms ໃນສະພາບແວດລ້ອມການສ້າງແບບຈໍາລອງໂຄງສ້າງເຊັ່ນ: SimInTech, Simulink, AmeSim, ຄວາມສາມາດໃນການສ້າງໂຄງສ້າງຫຼາຍລະດັບໃນຮູບແບບຂອງ submodels ແມ່ນຖືກນໍາໃຊ້. ອົງການຈັດຕັ້ງນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຈັດກຸ່ມຄວາມຕ້ອງການຕ່າງໆເຂົ້າໄປໃນຊຸດເພື່ອເຮັດໃຫ້ການເຮັດວຽກທີ່ງ່າຍດາຍກັບ array ຂອງຄວາມຕ້ອງການ, ດັ່ງທີ່ເຮັດສໍາລັບສູດການຄິດໄລ່ການຄວບຄຸມ (ເບິ່ງຮູບ 2).

ຮູບທີ 2. ໂຄງສ້າງແບບລຳດັບຂອງຮູບແບບການຢັ້ງຢືນຄວາມຕ້ອງການ.

ຕົວຢ່າງ, ໃນກໍລະນີທີ່ຢູ່ພາຍໃຕ້ການພິຈາລະນາ, ສອງກຸ່ມໄດ້ຖືກຈໍາແນກ: ຄວາມຕ້ອງການສໍາລັບສະພາບແວດລ້ອມແລະຄວາມຕ້ອງການໂດຍກົງສໍາລັບລະບົບ. ດັ່ງນັ້ນ, ໂຄງສ້າງຂໍ້ມູນສອງລະດັບແມ່ນໃຊ້: ສອງກຸ່ມ, ແຕ່ລະໃບຂອງສູດການຄິດໄລ່.

ເພື່ອເຊື່ອມຕໍ່ຂໍ້ມູນກັບຕົວແບບ, ໂຄງການມາດຕະຖານສໍາລັບການສ້າງຖານຂໍ້ມູນສັນຍານຖືກນໍາໃຊ້, ເຊິ່ງເກັບຮັກສາຂໍ້ມູນສໍາລັບການແລກປ່ຽນລະຫວ່າງພາກສ່ວນຂອງໂຄງການ.

ເມື່ອສ້າງແລະທົດສອບຊອບແວ, ການອ່ານຂອງເຊັນເຊີ (ການປຽບທຽບຂອງເຊັນເຊີລະບົບທີ່ແທ້ຈິງ) ທີ່ຖືກນໍາໃຊ້ໂດຍລະບົບການຄວບຄຸມແມ່ນຖືກຈັດໃສ່ໃນຖານຂໍ້ມູນນີ້.
ສໍາລັບໂຄງການທົດສອບ, ຕົວກໍານົດການໃດໆທີ່ຄິດໄລ່ໃນຮູບແບບແບບເຄື່ອນໄຫວສາມາດຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນດຽວກັນແລະດັ່ງນັ້ນຈຶ່ງຖືກນໍາໃຊ້ເພື່ອກວດເບິ່ງວ່າຄວາມຕ້ອງການແມ່ນບັນລຸໄດ້.

ໃນກໍລະນີນີ້, ຕົວແບບແບບເຄື່ອນໄຫວຕົວມັນເອງສາມາດຖືກປະຕິບັດຢູ່ໃນລະບົບການສ້າງແບບຈໍາລອງທາງຄະນິດສາດຫຼືແມ້ກະທັ້ງໃນຮູບແບບຂອງໂຄງການທີ່ສາມາດປະຕິບັດໄດ້. ຄວາມຕ້ອງການພຽງແຕ່ມີການໂຕ້ຕອບຊອບແວສໍາລັບການອອກຂໍ້ມູນການສ້າງແບບຈໍາລອງກັບສະພາບແວດລ້ອມພາຍນອກ.

ຮູບ 3. ການເຊື່ອມຕໍ່ໂຄງການກວດສອບກັບຕົວແບບສະລັບສັບຊ້ອນ.

ຕົວຢ່າງຂອງເອກະສານການຢັ້ງຢືນຄວາມຕ້ອງການພື້ນຖານແມ່ນສະແດງຢູ່ໃນຮູບທີ 4. ຈາກທັດສະນະຂອງຜູ້ພັດທະນາ, ມັນເປັນແຜນວາດການຄິດໄລ່ແບບທໍາມະດາທີ່ລະບົບການກວດສອບຄວາມຕ້ອງການຖືກນໍາສະເຫນີເປັນຮູບແຕ້ມ.

ຮູບທີ 4. ເອກະສານກວດກາຄວາມຕ້ອງການ.

ພາກສ່ວນຫຼັກຂອງໃບກວດກາແມ່ນໄດ້ອະທິບາຍໄວ້ໃນຮູບທີ 5. ຂັ້ນຕອນການກວດກາແມ່ນຖືກສ້າງຂື້ນຄືກັນກັບແຜນວາດການອອກແບບຂອງລະບົບການຄວບຄຸມ. ຢູ່ເບື້ອງຂວາມີຕັນສໍາລັບການອ່ານສັນຍານຈາກຖານຂໍ້ມູນ. ຕັນນີ້ເຂົ້າເຖິງຖານຂໍ້ມູນສັນຍານໃນລະຫວ່າງການຈໍາລອງ.

ສັນຍານທີ່ໄດ້ຮັບໄດ້ຖືກວິເຄາະເພື່ອຄິດໄລ່ເງື່ອນໄຂການກວດສອບຄວາມຕ້ອງການ. ໃນກໍລະນີນີ້, ການວິເຄາະລະດັບຄວາມສູງແມ່ນປະຕິບັດເພື່ອກໍານົດຕໍາແຫນ່ງຂອງເຮືອບິນ (ບໍ່ວ່າຈະເປັນບ່ອນຈອດລົດຫຼືຢູ່ໃນການບິນ). ສໍາລັບຈຸດປະສົງນີ້, ທ່ານສາມາດນໍາໃຊ້ສັນຍານອື່ນໆແລະຕົວກໍານົດການຄິດໄລ່ຂອງຕົວແບບ.

ເງື່ອນໄຂການກວດສອບແລະພາລາມິເຕີທີ່ຖືກກວດສອບຖືກໂອນໄປຫາບລັອກການກວດສອບມາດຕະຖານ, ເຊິ່ງຕົວກໍານົດການເຫຼົ່ານີ້ຖືກວິເຄາະເພື່ອປະຕິບັດຕາມຂໍ້ກໍານົດທີ່ກໍານົດໄວ້. ຜົນໄດ້ຮັບຖືກບັນທຶກໄວ້ໃນຖານຂໍ້ມູນສັນຍານໃນລັກສະນະທີ່ພວກເຂົາສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງລາຍການກວດສອບອັດຕະໂນມັດ.

ຮູບທີ 5. ໂຄງສ້າງຂອງເອກະສານການຄິດໄລ່ການຢັ້ງຢືນຄວາມຕ້ອງການ.

ຕົວກໍານົດການທີ່ຈະທົດສອບບໍ່ຈໍາເປັນຕ້ອງໃຊ້ສັນຍານທີ່ມີຢູ່ໃນຖານຂໍ້ມູນ, ເຊິ່ງຖືກຄວບຄຸມໂດຍພາລາມິເຕີທີ່ຄິດໄລ່ໃນລະຫວ່າງຂະບວນການຈໍາລອງ. ບໍ່ມີຫຍັງກີດຂວາງພວກເຮົາຈາກການປະຕິບັດການຄິດໄລ່ເພີ່ມເຕີມໃນກອບຂອງຂໍ້ກໍານົດຮ່າງ, ຄືກັນກັບພວກເຮົາຄິດໄລ່ເງື່ອນໄຂການກວດສອບ.

ສໍາລັບຕົວຢ່າງ, ຄວາມຕ້ອງການນີ້:

ຈໍານວນການກະຕຸ້ນຂອງລະບົບການແກ້ໄຂໃນລະຫວ່າງການບິນໄປຫາເປົ້າຫມາຍບໍ່ຄວນເກີນ 5, ແລະເວລາປະຕິບັດງານທັງຫມົດຂອງລະບົບການແກ້ໄຂບໍ່ຄວນເກີນ 30 ວິນາທີ.

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ສູດ​ການ​ຄິດ​ໄລ່​ສໍາ​ລັບ​ການ​ຕ້ານ​ຈໍາ​ນວນ​ຂອງ​ການ​ເລີ່ມ​ຕົ້ນ​ແລະ​ການ​ໃຊ້​ເວ​ລາ​ປະ​ຕິ​ບັດ​ທັງ​ຫມົດ​ແມ່ນ​ເພີ່ມ​ໃສ່​ແຜນ​ວາດ​ການ​ອອກ​ແບບ​ຂອງ​ຄວາມ​ຕ້ອງ​ການ​.

ບລັອກການຢືນຢັນຄວາມຕ້ອງການປົກກະຕິ.

ກ່ອງກາໝາຍມາດຕະຖານແຕ່ລະອັນຖືກອອກແບບເພື່ອຄິດໄລ່ການຕອບສະໜອງຄວາມຕ້ອງການຂອງປະເພດໃດນຶ່ງ. ຕົວຢ່າງເຊັ່ນ, ຄວາມຕ້ອງການດ້ານສິ່ງແວດລ້ອມປະກອບມີລະດັບອຸນຫະພູມຂອງການດໍາເນີນງານສະພາບແວດລ້ອມໃນເວລາທີ່ຈອດລົດແລະຢູ່ໃນການບິນ. ຕັນ​ນີ້​ຕ້ອງ​ໄດ້​ຮັບ​ອຸນ​ຫະ​ພູມ​ອາ​ກາດ​ໃນ​ຕົວ​ແບບ​ເປັນ​ພາ​ລາ​ມິ​ເຕີ​ແລະ​ກໍາ​ນົດ​ວ່າ​ຕົວ​ກໍາ​ນົດ​ການ​ນີ້​ກວມ​ເອົາ​ລະ​ດັບ​ອຸນ​ຫະ​ພູມ​ທີ່​ກໍາ​ນົດ​ໄວ້./p>

ບລັອກປະກອບມີສອງພອດຂາເຂົ້າ, param ແລະເງື່ອນໄຂ.

ອັນທໍາອິດແມ່ນປ້ອນກັບພາລາມິເຕີທີ່ຖືກກວດສອບ. ໃນກໍລະນີດັ່ງກ່າວນີ້, "ອຸນຫະພູມພາຍນອກ".

ຕົວແປ Boolean ໄດ້ຖືກສະຫນອງໃຫ້ແກ່ພອດທີສອງ - ເງື່ອນໄຂສໍາລັບການປະຕິບັດການກວດສອບ.

ຖ້າໄດ້ຮັບ TRUE (1) ຢູ່ທີ່ວັດສະດຸປ້ອນທີສອງ, ຫຼັງຈາກນັ້ນ, ບລັອກຈະດໍາເນີນການຄິດໄລ່ການຢືນຢັນຄວາມຕ້ອງການ.

ຖ້າການປ້ອນຂໍ້ມູນທີສອງໄດ້ຮັບ FALSE (0), ຫຼັງຈາກນັ້ນ, ເງື່ອນໄຂການທົດສອບບໍ່ໄດ້ບັນລຸໄດ້. ນີ້ແມ່ນມີຄວາມຈໍາເປັນເພື່ອໃຫ້ເງື່ອນໄຂການຄິດໄລ່ສາມາດຖືກພິຈາລະນາ. ໃນກໍລະນີຂອງພວກເຮົາ, ວັດສະດຸປ້ອນນີ້ຖືກນໍາໃຊ້ເພື່ອເປີດຫຼືປິດການກວດສອບໂດຍຂຶ້ນກັບສະຖານະຂອງຕົວແບບ. ຖ້າເຮືອບິນຢູ່ເທິງພື້ນດິນໃນລະຫວ່າງການຈໍາລອງ, ຫຼັງຈາກນັ້ນ, ຂໍ້ກໍານົດທີ່ກ່ຽວຂ້ອງກັບການບິນບໍ່ໄດ້ຖືກກວດສອບ, ແລະໃນທາງກັບກັນ - ຖ້າເຮືອບິນຢູ່ໃນການບິນ, ຫຼັງຈາກນັ້ນ, ຂໍ້ກໍານົດທີ່ກ່ຽວຂ້ອງກັບການດໍາເນີນງານຢູ່ທີ່ຂາຕັ້ງບໍ່ໄດ້ຖືກກວດສອບ.

ການປ້ອນຂໍ້ມູນນີ້ຍັງສາມາດຖືກໃຊ້ໃນເວລາຕັ້ງຕົວແບບ, ຕົວຢ່າງໃນຂັ້ນຕອນການຄິດໄລ່ເບື້ອງຕົ້ນ. ເມື່ອຕົວແບບຖືກນໍາເຂົ້າໄປໃນສະຖານະທີ່ກໍານົດໄວ້, ຕັນການກວດສອບຖືກປິດການໃຊ້ງານ, ແຕ່ທັນທີທີ່ລະບົບມາຮອດໂຫມດປະຕິບັດການທີ່ກໍານົດໄວ້, ຕັນການກວດສອບຈະເປີດ.

ຕົວກໍານົດການຂອງຕັນນີ້ແມ່ນ:

• ເງື່ອນໄຂເຂດແດນ: ເທິງ (UpLimit) ແລະຕ່ໍາ (DownLimit) ຂອບເຂດຈໍາກັດທີ່ຕ້ອງໄດ້ຮັບການກວດສອບ;
• ທີ່​ຕ້ອງ​ການ​ເວ​ລາ exposure ລະ​ບົບ​ຢູ່​ໃນ​ຂອບ​ເຂດ​ເຂດ​ແດນ (TimeInterval​) ໃນ​ວິ​ນາ​ທີ​;
• ຂໍ ID ReqName;
• ການອະນຸຍາດໃຫ້ເກີນຂອບເຂດ Out_range ແມ່ນຕົວແປ Boolean ທີ່ກຳນົດວ່າຄ່າທີ່ເກີນຂອບເຂດທີ່ໝາຍໄວ້ນັ້ນແມ່ນການລະເມີດຄວາມຕ້ອງການຫຼືບໍ່.

ໃນບາງກໍລະນີ, ຜົນຜະລິດມູນຄ່າການທົດສອບຊີ້ໃຫ້ເຫັນວ່າລະບົບມີຂອບບາງແລະອາດຈະດໍາເນີນການຢູ່ນອກຂອບເຂດການດໍາເນີນງານຂອງມັນ. ໃນກໍລະນີອື່ນໆ, ຜົນຜະລິດຫມາຍຄວາມວ່າລະບົບບໍ່ສາມາດຮັກສາຈຸດທີ່ກໍານົດໄວ້ພາຍໃນຂອບເຂດ.

ຮູບທີ 6. ບລັອກການກວດສອບຊັບສິນແບບປົກກະຕິໃນແຜນວາດ ແລະພາລາມິເຕີຂອງມັນ.

ເປັນຜົນມາຈາກການຄິດໄລ່ຂອງຕັນນີ້, ຕົວແປຜົນໄດ້ຮັບຖືກສ້າງຕັ້ງຂຶ້ນຢູ່ທີ່ຜົນຜະລິດ, ເຊິ່ງໃຊ້ເວລາຄ່າດັ່ງຕໍ່ໄປນີ້:

• 0 – rNone, ຄ່າບໍ່ໄດ້ກໍານົດ;
• 1 - ສໍາເລັດ, ຄວາມຕ້ອງການແມ່ນບັນລຸໄດ້;
• 2 – ຜິດ​ພາດ​, ຄວາມ​ຕ້ອງ​ການ​ແມ່ນ​ບໍ່​ໄດ້​ຕອບ​ສະ​ຫນອງ​.

ຮູບບລັອກປະກອບມີ:

• ຂໍ້ຄວາມຕົວລະບຸ;
• ການສະແດງດິຈິຕອນຂອງຕົວກໍານົດການຈໍາກັດການວັດແທກ;
• ຕົວລະບຸສີຂອງສະຖານະພາລາມິເຕີ.

ພາຍໃນທ່ອນໄມ້ອາດມີວົງຈອນ inference ຢ່າງສົມເຫດສົມຜົນທີ່ສັບສົນຫຼາຍ.

ຕົວຢ່າງ, ເພື່ອກວດເບິ່ງລະດັບອຸນຫະພູມການດໍາເນີນງານຂອງຫນ່ວຍງານທີ່ສະແດງຢູ່ໃນຮູບທີ 6, ວົງຈອນພາຍໃນແມ່ນສະແດງຢູ່ໃນຮູບ 7.

ຮູບທີ 7. ແຜນວາດພາຍໃນຂອງຫົວໜ່ວຍກໍານົດຂອບເຂດອຸນຫະພູມ.

ພາຍໃນຕັນວົງຈອນ, ຄຸນສົມບັດທີ່ລະບຸໄວ້ໃນຕົວກໍານົດການຕັນແມ່ນຖືກນໍາໃຊ້.
ນອກເຫນືອຈາກການວິເຄາະການປະຕິບັດຕາມຄວາມຕ້ອງການ, ແຜນວາດພາຍໃນຂອງບລັອກປະກອບດ້ວຍກາຟທີ່ຈໍາເປັນສໍາລັບການສະແດງຜົນການຈໍາລອງ. ເສັ້ນສະແດງນີ້ສາມາດຖືກນໍາໃຊ້ທັງສໍາລັບການເບິ່ງໃນລະຫວ່າງການຄິດໄລ່ແລະສໍາລັບການວິເຄາະຜົນໄດ້ຮັບຫຼັງຈາກການຄິດໄລ່.

ຜົນໄດ້ຮັບການຄິດໄລ່ແມ່ນຖືກສົ່ງໄປຫາຜົນຜະລິດຂອງຕັນແລະຖືກບັນທຶກພ້ອມໆກັນຢູ່ໃນເອກະສານລາຍງານທົ່ວໄປ, ເຊິ່ງຖືກສ້າງຂຶ້ນໂດຍອີງໃສ່ຜົນໄດ້ຮັບສໍາລັບໂຄງການທັງຫມົດ. (ເບິ່ງຮູບທີ 8)

ຕົວຢ່າງຂອງບົດລາຍງານທີ່ສ້າງຂຶ້ນໂດຍອີງໃສ່ຜົນການຈໍາລອງແມ່ນໄຟລ໌ html ທີ່ສ້າງຂຶ້ນຕາມຮູບແບບທີ່ກໍານົດ. ຮູບແບບດັ່ງກ່າວສາມາດຖືກປັບຕັ້ງໃຫ້ຖືກຕ້ອງກັບຮູບແບບທີ່ຍອມຮັບໂດຍອົງການສະເພາະ.

ພາຍໃນຕັນວົງຈອນ, ຄຸນສົມບັດທີ່ລະບຸໄວ້ໃນຕົວກໍານົດການຕັນແມ່ນຖືກນໍາໃຊ້.
ນອກເຫນືອຈາກການວິເຄາະການປະຕິບັດຕາມຄວາມຕ້ອງການ, ແຜນວາດພາຍໃນຂອງບລັອກປະກອບດ້ວຍກາຟທີ່ຈໍາເປັນສໍາລັບການສະແດງຜົນການຈໍາລອງ. ເສັ້ນສະແດງນີ້ສາມາດຖືກນໍາໃຊ້ທັງສໍາລັບການເບິ່ງໃນລະຫວ່າງການຄິດໄລ່ແລະສໍາລັບການວິເຄາະຜົນໄດ້ຮັບຫຼັງຈາກການຄິດໄລ່.

ຜົນໄດ້ຮັບການຄິດໄລ່ແມ່ນຖືກສົ່ງໄປຫາຜົນຜະລິດຂອງຕັນແລະຖືກບັນທຶກພ້ອມໆກັນຢູ່ໃນເອກະສານລາຍງານທົ່ວໄປ, ເຊິ່ງຖືກສ້າງຂຶ້ນໂດຍອີງໃສ່ຜົນໄດ້ຮັບສໍາລັບໂຄງການທັງຫມົດ. (ເບິ່ງຮູບທີ 8)

ຕົວຢ່າງຂອງບົດລາຍງານທີ່ສ້າງຂຶ້ນໂດຍອີງໃສ່ຜົນການຈໍາລອງແມ່ນໄຟລ໌ html ທີ່ສ້າງຂຶ້ນຕາມຮູບແບບທີ່ກໍານົດ. ຮູບແບບດັ່ງກ່າວສາມາດຖືກປັບຕັ້ງໃຫ້ຖືກຕ້ອງກັບຮູບແບບທີ່ຍອມຮັບໂດຍອົງການສະເພາະ.

ຮູບ 8. ຕົວຢ່າງຂອງເອກະສານລາຍງານໂດຍອີງໃສ່ຜົນການຈໍາລອງ.

ໃນຕົວຢ່າງນີ້, ແບບຟອມບົດລາຍງານຖືກຕັ້ງຄ່າໂດຍກົງໃນຄຸນສົມບັດຂອງໂຄງການ, ແລະຮູບແບບໃນຕາຕະລາງແມ່ນຖືກກໍານົດເປັນສັນຍານໂຄງການທົ່ວໂລກ. ໃນກໍລະນີນີ້, SimInTech ຕົວຂອງມັນເອງແກ້ໄຂບັນຫາຂອງການຕັ້ງຄ່າບົດລາຍງານ, ແລະຕັນສໍາລັບການຂຽນຜົນໄດ້ຮັບໄປຫາເອກະສານໃຊ້ເສັ້ນເຫຼົ່ານີ້ເພື່ອຂຽນໃສ່ເອກະສານລາຍງານ.

ຮູບ 9. ການກໍານົດຮູບແບບບົດລາຍງານໃນສັນຍານໂຄງການທົ່ວໂລກ

ການນໍາໃຊ້ຖານຂໍ້ມູນສັນຍານສໍາລັບຄວາມຕ້ອງການ.

ເພື່ອອັດຕະໂນມັດການເຮັດວຽກກັບການຕັ້ງຄ່າຊັບສິນ, ໂຄງສ້າງມາດຕະຖານຖືກສ້າງຂື້ນໃນຖານຂໍ້ມູນສັນຍານສໍາລັບແຕ່ລະຕັນປົກກະຕິ. (ເບິ່ງຮູບທີ 10)

ຮູບທີ 10. ຕົວຢ່າງຂອງໂຄງສ້າງຂອງຕັນການກວດສອບຄວາມຕ້ອງການໃນຖານຂໍ້ມູນສັນຍານ.

ຖານຂໍ້ມູນສັນຍານໃຫ້:

• ການເກັບຮັກສາຕົວກໍານົດການຄວາມຕ້ອງການຂອງລະບົບທີ່ຈໍາເປັນທັງຫມົດ.
• ການເບິ່ງທີ່ສະດວກສະບາຍຂອງຄວາມຕ້ອງການໂຄງການທີ່ມີຢູ່ແລ້ວຈາກຕົວກໍານົດການທີ່ລະບຸແລະຜົນໄດ້ຮັບຂອງການສ້າງແບບຈໍາລອງໃນປະຈຸບັນ.
• ການຕັ້ງຄ່າຫນຶ່ງບລັອກຫຼືກຸ່ມຂອງບລັອກໂດຍໃຊ້ພາສາການຂຽນໂປລແກລມສະຄິບ. ການປ່ຽນແປງໃນຖານຂໍ້ມູນສັນຍານນໍາໄປສູ່ການປ່ຽນແປງມູນຄ່າຊັບສິນຂອງຕັນໃນແຜນວາດ.
• ການເກັບຮັກສາຄໍາອະທິບາຍຂໍ້ຄວາມ, ການເຊື່ອມຕໍ່ກັບລາຍການສະເພາະດ້ານວິຊາການຫຼືຕົວລະບຸໃນລະບົບການຄຸ້ມຄອງຄວາມຕ້ອງການ.

ໂຄງສ້າງຖານຂໍ້ມູນສັນຍານສໍາລັບຄວາມຕ້ອງການສາມາດຖືກຕັ້ງຄ່າໄດ້ງ່າຍເພື່ອເຮັດວຽກກັບລະບົບການຄຸ້ມຄອງຄວາມຕ້ອງການຂອງພາກສ່ວນທີສາມ.

ຮູບທີ 11. ແຜນຜັງປະຕິສໍາພັນກັບລະບົບການຈັດການຄວາມຕ້ອງການ.

ລໍາດັບຂອງການໂຕ້ຕອບລະຫວ່າງໂຄງການທົດສອບ SimInTech ແລະລະບົບການຄວບຄຸມຄວາມຕ້ອງການແມ່ນດັ່ງຕໍ່ໄປນີ້:

1. ເງື່ອນໄຂການອ້າງອີງຖືກແບ່ງອອກເປັນຂໍ້ກໍານົດ.
2. ຂໍ້ກໍານົດຂອງຂໍ້ກໍານົດດ້ານວິຊາການແມ່ນຖືກກໍານົດທີ່ສາມາດກວດສອບໄດ້ໂດຍການສ້າງແບບຈໍາລອງທາງຄະນິດສາດຂອງຂະບວນການດ້ານວິຊາການ.
3. ຄຸນລັກສະນະຂອງຄວາມຕ້ອງການທີ່ເລືອກຈະຖືກໂອນໄປຫາຖານຂໍ້ມູນສັນຍານ SimInTech ໃນໂຄງສ້າງຂອງຕັນມາດຕະຖານ (ຕົວຢ່າງ, ອຸນຫະພູມສູງສຸດແລະຕ່ໍາສຸດ).
4. ໃນລະຫວ່າງຂະບວນການຄິດໄລ່, ຂໍ້ມູນໂຄງສ້າງຖືກໂອນໄປຫາແຜນຜັງການອອກແບບຕັນ, ການວິເຄາະແມ່ນປະຕິບັດແລະຜົນໄດ້ຮັບຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນສັນຍານ.
5. ເມື່ອການຄິດໄລ່ສໍາເລັດ, ຜົນໄດ້ຮັບການວິເຄາະຈະຖືກໂອນໄປຫາລະບົບການຄຸ້ມຄອງຄວາມຕ້ອງການ.

ຂໍ້ກໍານົດຂັ້ນຕອນ 3 ຫາ 5 ອາດຈະຊ້ໍາກັນໃນລະຫວ່າງຂະບວນການອອກແບບເມື່ອມີການປ່ຽນແປງການອອກແບບແລະ / ຫຼືຄວາມຕ້ອງການເກີດຂຶ້ນແລະຜົນກະທົບຂອງການປ່ຽນແປງຕ້ອງໄດ້ຮັບການທົດສອບໃຫມ່.

ຂໍ້ສະຫຼຸບ.

• ຕົ້ນແບບທີ່ສ້າງຂື້ນຂອງລະບົບສະຫນອງການຫຼຸດຜ່ອນຄວາມສໍາຄັນຂອງເວລາຂອງການວິເຄາະແບບຈໍາລອງທີ່ມີຢູ່ແລ້ວສໍາລັບການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງຂໍ້ກໍານົດດ້ານວິຊາການ.
• ເທກໂນໂລຍີການທົດສອບທີ່ສະເຫນີໃຊ້ແບບເຄື່ອນໄຫວທີ່ມີຢູ່ກ່ອນແລ້ວແລະສາມາດນໍາໃຊ້ໄດ້ເຖິງແມ່ນວ່າສໍາລັບແບບເຄື່ອນໄຫວໃດໆ, ລວມທັງສິ່ງທີ່ບໍ່ໄດ້ປະຕິບັດໃນສະພາບແວດລ້ອມ SimInTech.
• ການນໍາໃຊ້ອົງການຈັດຕັ້ງຂໍ້ມູນ batch ຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດການຢັ້ງຢືນຄວາມຕ້ອງການໃນຂະຫນານກັບການພັດທະນາແບບຈໍາລອງ, ຫຼືແມ້ກະທັ້ງການນໍາໃຊ້ຊຸດເຫຼົ່ານີ້ເປັນຂໍ້ກໍານົດດ້ານວິຊາການສໍາລັບການພັດທະນາຕົວແບບ.
• ເທກໂນໂລຍີສາມາດປະສົມປະສານກັບລະບົບການຄຸ້ມຄອງຄວາມຕ້ອງການທີ່ມີຢູ່ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍທີ່ສໍາຄັນ.

ສໍາລັບຜູ້ທີ່ອ່ານຈົນຈົບ, ເຊື່ອມຕໍ່ກັບວິດີໂອສະແດງໃຫ້ເຫັນວິທີການຕົ້ນແບບເຮັດວຽກ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com