การตรวจสอบข้อกำหนดข้อกำหนดทางเทคนิคโดยอัตโนมัติระหว่างการสร้างแบบจำลองแบบไดนามิก

ดำเนินเรื่องต่อ “หลักฐานของคุณคืออะไร”มาดูปัญหาการสร้างแบบจำลองทางคณิตศาสตร์จากอีกด้านหนึ่งกัน หลังจากที่เรามั่นใจว่าแบบจำลองนั้นสอดคล้องกับความจริงของชีวิต เราก็สามารถตอบคำถามหลักได้: “เรามีอะไรอยู่ที่นี่กันแน่” เมื่อสร้างแบบจำลองของวัตถุทางเทคนิค เรามักจะต้องการให้แน่ใจว่าวัตถุนี้จะตรงตามความคาดหวังของเรา เพื่อจุดประสงค์นี้ การคำนวณแบบไดนามิกของกระบวนการจะดำเนินการและผลลัพธ์จะถูกเปรียบเทียบกับข้อกำหนด นี่คือแฝดดิจิทัล ต้นแบบเสมือน ฯลฯ หนุ่มน้อยทันสมัยที่ในขั้นตอนการออกแบบ แก้ปัญหาว่าจะให้แน่ใจว่าเราได้สิ่งที่เราวางแผนไว้อย่างไร

เราจะแน่ใจได้อย่างไรว่าระบบของเราตรงกับที่เราออกแบบ การออกแบบของเราจะลอยหรือลอยได้? แล้วถ้ามันบินได้สูงขนาดไหนล่ะ? แล้วถ้าลอยได้ลึกขนาดไหนครับ?

บทความนี้กล่าวถึงระบบอัตโนมัติในการตรวจสอบการปฏิบัติตามข้อกำหนดของอาคารทางเทคนิคเมื่อสร้างแบบจำลองแบบไดนามิกของระบบทางเทคนิค ตัวอย่างเช่น ลองดูที่องค์ประกอบของข้อกำหนดทางเทคนิคสำหรับระบบระบายความร้อนด้วยอากาศของเครื่องบิน

เราพิจารณาข้อกำหนดเหล่านั้นที่สามารถแสดงเป็นตัวเลขและตรวจสอบได้ทางคณิตศาสตร์โดยอิงตามแบบจำลองการคำนวณเฉพาะ เห็นได้ชัดว่านี่เป็นเพียงส่วนหนึ่งของข้อกำหนดทั่วไปสำหรับระบบทางเทคนิคใดๆ แต่เป็นการตรวจสอบว่าเราใช้เวลา ความพยายาม และเงินในการสร้างแบบจำลองไดนามิกของวัตถุ

เมื่ออธิบายข้อกำหนดทางเทคนิคในรูปแบบของเอกสารสามารถแยกแยะข้อกำหนดที่แตกต่างกันได้หลายประเภทซึ่งแต่ละประเภทต้องใช้แนวทางที่แตกต่างกันสำหรับการสร้างการตรวจสอบการปฏิบัติตามข้อกำหนดโดยอัตโนมัติ

ตัวอย่างเช่น ลองพิจารณาข้อกำหนดเล็กๆ น้อยๆ แต่สมจริงนี้:

1. อุณหภูมิอากาศบรรยากาศทางเข้าระบบบำบัดน้ำ:
   ในลานจอดรถ - จากลบ 35 ถึง 35 ºС
   ในเที่ยวบิน - จากลบ 35 ถึง 39 ºС
2. ความดันสถิตของอากาศในชั้นบรรยากาศในการบินอยู่ที่ 700 ถึง 1013 GPa (จาก 526 ถึง 760 มม. ปรอท)
3. ความกดอากาศทั้งหมดที่ทางเข้าช่องรับอากาศ SVO ในเที่ยวบินอยู่ที่ 754 ถึง 1200 GPa (จาก 566 ถึง 1050 มม. ปรอท)
4. อุณหภูมิอากาศเย็น:
   ในลานจอดรถ - ไม่เกิน 27 ºСสำหรับบล็อกทางเทคนิค - ไม่เกิน 29 ºС
   ในการบิน - ไม่เกิน 25 ºС สำหรับบล็อกทางเทคนิค - ไม่เกิน 27 ºС
5. การไหลของอากาศเย็น:
   เมื่อจอด - อย่างน้อย 708 กก./ชม.
   ในเที่ยวบิน - ไม่น้อยกว่า 660 กก./ชม.
6. อุณหภูมิอากาศในช่องเครื่องมือไม่เกิน 60 ºС
7. ปริมาณความชื้นอิสระละเอียดในอากาศเย็นคือไม่เกิน 2 กรัม/กิโลกรัมของอากาศแห้ง

แม้จะอยู่ภายในชุดข้อกำหนดที่จำกัดนี้ ยังมีอย่างน้อยสองหมวดหมู่ที่ต้องได้รับการจัดการที่แตกต่างกันในระบบ:

• ข้อกำหนดสำหรับสภาพการทำงานของระบบ (ข้อ 1-3)
• ข้อกำหนดพารามิเตอร์สำหรับระบบ (ข้อ 3-7)

ข้อกำหนดเงื่อนไขการทำงานของระบบ
เงื่อนไขภายนอกสำหรับระบบที่กำลังพัฒนาระหว่างการสร้างแบบจำลองสามารถระบุเป็นเงื่อนไขขอบเขตหรือเป็นผลจากการทำงานของระบบทั่วไปได้
ในการจำลองแบบไดนามิก จำเป็นเพื่อให้แน่ใจว่ากระบวนการจำลองครอบคลุมสภาวะการทำงานที่ระบุ

ข้อกำหนดของระบบพาราเมตริก
ข้อกำหนดเหล่านี้เป็นพารามิเตอร์ที่ระบบจัดเตรียมไว้ให้ ในระหว่างกระบวนการสร้างแบบจำลอง เราสามารถรับพารามิเตอร์เหล่านี้เป็นผลลัพธ์การคำนวณ และตรวจสอบให้แน่ใจว่าเป็นไปตามข้อกำหนดในการคำนวณเฉพาะแต่ละรายการ

การระบุข้อกำหนดและการเข้ารหัส

เพื่อความสะดวกในการทำงานกับข้อกำหนด มาตรฐานที่มีอยู่แนะนำให้กำหนดตัวระบุให้กับข้อกำหนดแต่ละข้อ เมื่อกำหนดตัวระบุ แนะนำให้ใช้ระบบการเข้ารหัสแบบครบวงจร

รหัสข้อกำหนดอาจเป็นเพียงตัวเลขที่แสดงถึงหมายเลขคำสั่งซื้อของข้อกำหนด หรืออาจประกอบด้วยรหัสสำหรับประเภทของข้อกำหนด รหัสสำหรับระบบหรือหน่วยที่ใช้งาน รหัสพารามิเตอร์ รหัสสถานที่ และ สิ่งอื่นใดที่วิศวกรสามารถจินตนาการได้ (ดูบทความสำหรับการใช้การเข้ารหัส)

ตารางที่ 1 แสดงตัวอย่างง่ายๆ ของการเข้ารหัสข้อกำหนด

1. รหัสแหล่งที่มาของข้อกำหนด R-requirements 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 ตัวอย่างการออกแบบโครงการตรวจสอบ

เช่นเดียวกับอัลกอริธึมการควบคุม สามารถเขียนข้อกำหนดเป็นชุดแผ่นงานได้ เพื่อความสะดวกในการทำงานกับอัลกอริธึมในสภาพแวดล้อมการสร้างแบบจำลองโครงสร้างเช่น SimInTech, Simulink, AmeSim จะใช้ความสามารถในการสร้างโครงสร้างหลายระดับในรูปแบบของโมเดลย่อย องค์กรนี้ทำให้สามารถจัดกลุ่มข้อกำหนดต่างๆ ออกเป็นชุดเพื่อลดความซับซ้อนในการทำงานกับอาร์เรย์ของข้อกำหนด เช่นเดียวกับที่ทำกับอัลกอริธึมการควบคุม (ดูรูปที่ 2)

รูปที่ 2 โครงสร้างลำดับชั้นของแบบจำลองการตรวจสอบข้อกำหนด

ตัวอย่างเช่น ในกรณีที่อยู่ระหว่างการพิจารณา จะมีการแบ่งกลุ่มออกเป็นสองกลุ่ม: ข้อกำหนดสำหรับสภาพแวดล้อมและข้อกำหนดโดยตรงสำหรับระบบ ดังนั้นจึงมีการใช้โครงสร้างข้อมูลสองระดับ: สองกลุ่มซึ่งแต่ละกลุ่มเป็นใบไม้ของอัลกอริทึม

ในการเชื่อมต่อข้อมูลกับแบบจำลอง จะใช้โครงร่างมาตรฐานสำหรับการสร้างฐานข้อมูลสัญญาณ ซึ่งจัดเก็บข้อมูลสำหรับการแลกเปลี่ยนระหว่างส่วนต่างๆ ของโครงการ

เมื่อสร้างและทดสอบซอฟต์แวร์ การอ่านเซ็นเซอร์ (แอนะล็อกของเซ็นเซอร์ระบบจริง) ที่ใช้โดยระบบควบคุมจะถูกวางไว้ในฐานข้อมูลนี้
สำหรับโปรเจ็กต์ทดสอบ พารามิเตอร์ใดๆ ที่คำนวณในโมเดลไดนามิกสามารถจัดเก็บไว้ในฐานข้อมูลเดียวกันได้ และใช้เพื่อตรวจสอบว่าเป็นไปตามข้อกำหนดหรือไม่

ในกรณีนี้ โมเดลไดนามิกสามารถดำเนินการได้ในระบบการสร้างแบบจำลองทางคณิตศาสตร์ใดๆ หรือแม้แต่ในรูปแบบของโปรแกรมที่ปฏิบัติการได้ ข้อกำหนดเพียงอย่างเดียวคือการมีอินเทอร์เฟซซอฟต์แวร์สำหรับการออกข้อมูลการสร้างแบบจำลองไปยังสภาพแวดล้อมภายนอก

รูปที่ 3 การเชื่อมต่อโครงการตรวจสอบกับโมเดลที่ซับซ้อน

ตัวอย่างของเอกสารการตรวจสอบข้อกำหนดขั้นพื้นฐานแสดงในรูปที่ 4 จากมุมมองของนักพัฒนา มันเป็นแผนภาพการคำนวณทั่วไปซึ่งมีการนำเสนออัลกอริทึมการตรวจสอบข้อกำหนดเป็นกราฟิก

รูปที่ 4 เอกสารตรวจสอบข้อกำหนด

ส่วนหลักของใบตรวจสอบอธิบายไว้ในรูปที่ 5 อัลกอริธึมตรวจสอบมีรูปแบบคล้ายกับไดอะแกรมการออกแบบอัลกอริธึมควบคุม ทางด้านขวามีช่องสำหรับอ่านสัญญาณจากฐานข้อมูล บล็อกนี้เข้าถึงฐานข้อมูลสัญญาณระหว่างการจำลอง

สัญญาณที่ได้รับจะถูกวิเคราะห์เพื่อคำนวณเงื่อนไขการตรวจสอบข้อกำหนด ในกรณีนี้ การวิเคราะห์ระดับความสูงจะดำเนินการเพื่อระบุตำแหน่งของเครื่องบิน (ไม่ว่าจะจอดอยู่หรือกำลังบิน) เพื่อจุดประสงค์นี้ คุณสามารถใช้สัญญาณอื่นและพารามิเตอร์ที่คำนวณได้ของโมเดล

เงื่อนไขการตรวจสอบและพารามิเตอร์ที่ได้รับการตรวจสอบจะถูกโอนไปยังบล็อกการตรวจสอบมาตรฐาน ซึ่งพารามิเตอร์เหล่านี้ได้รับการวิเคราะห์เพื่อให้เป็นไปตามข้อกำหนดที่ระบุ ผลลัพธ์จะถูกบันทึกไว้ในฐานข้อมูลสัญญาณในลักษณะที่สามารถใช้เพื่อสร้างรายการตรวจสอบได้โดยอัตโนมัติ

รูปที่ 5 โครงสร้างของแผ่นคำนวณการตรวจสอบข้อกำหนด

พารามิเตอร์ที่จะทดสอบไม่จำเป็นต้องใช้สัญญาณที่มีอยู่ในฐานข้อมูล ซึ่งควบคุมโดยพารามิเตอร์ที่คำนวณในระหว่างกระบวนการจำลอง ไม่มีสิ่งใดขัดขวางเราจากการคำนวณเพิ่มเติมภายในกรอบข้อกำหนดร่าง เช่นเดียวกับที่เราคำนวณเงื่อนไขการตรวจสอบ

ตัวอย่างเช่น ข้อกำหนดนี้:

จำนวนการเปิดใช้งานระบบแก้ไขระหว่างการบินไปยังเป้าหมายไม่ควรเกิน 5 และเวลาทำงานรวมของระบบแก้ไขไม่ควรเกิน 30 วินาที

ในกรณีนี้ อัลกอริธึมสำหรับการตอบโต้จำนวนการเริ่มต้นและเวลาการทำงานทั้งหมดจะถูกเพิ่มลงในไดอะแกรมการออกแบบของข้อกำหนด

บล็อกการตรวจสอบข้อกำหนดทั่วไป

กล่องกาเครื่องหมายความต้องการมาตรฐานแต่ละกล่องได้รับการออกแบบมาเพื่อคำนวณการปฏิบัติตามข้อกำหนดบางประเภท ตัวอย่างเช่น ข้อกำหนดด้านสิ่งแวดล้อมรวมถึงช่วงอุณหภูมิการทำงานโดยรอบเมื่อจอดและอยู่บนเครื่องบิน บล็อกนี้จะต้องได้รับอุณหภูมิอากาศในแบบจำลองเป็นพารามิเตอร์และตรวจสอบว่าพารามิเตอร์นี้ครอบคลุมช่วงอุณหภูมิที่ระบุหรือไม่/p>

บล็อกประกอบด้วยพอร์ตอินพุตสองพอร์ต พารามิเตอร์ และเงื่อนไข

อันแรกจะถูกป้อนพร้อมกับพารามิเตอร์ที่กำลังตรวจสอบ ในกรณีนี้คือ "อุณหภูมิภายนอก"

ตัวแปรบูลีนจะถูกส่งไปยังพอร์ตที่สอง - เงื่อนไขสำหรับการดำเนินการตรวจสอบ

หากได้รับ TRUE (1) ที่อินพุตที่สอง บล็อกจะดำเนินการคำนวณการตรวจสอบข้อกำหนด

หากอินพุตที่สองได้รับ FALSE (0) แสดงว่าไม่ตรงตามเงื่อนไขการทดสอบ นี่เป็นสิ่งจำเป็นเพื่อให้สามารถพิจารณาเงื่อนไขการคำนวณได้ ในกรณีของเรา อินพุตนี้ใช้เพื่อเปิดหรือปิดใช้งานการตรวจสอบ โดยขึ้นอยู่กับสถานะของโมเดล หากเครื่องบินอยู่ภาคพื้นดินระหว่างการจำลอง ข้อกำหนดที่เกี่ยวข้องกับการบินจะไม่ได้รับการตรวจสอบ และในทางกลับกัน หากเครื่องบินกำลังบิน ข้อกำหนดที่เกี่ยวข้องกับการปฏิบัติการที่จุดจอดจะไม่ได้รับการตรวจสอบ

อินพุตนี้ยังสามารถนำมาใช้เมื่อตั้งค่าแบบจำลอง เช่น ในขั้นเริ่มต้นของการคำนวณ เมื่อโมเดลเข้าสู่สถานะที่ต้องการ บล็อกตรวจสอบจะถูกปิดใช้งาน แต่ทันทีที่ระบบเข้าสู่โหมดการทำงานที่ต้องการ บล็อกตรวจสอบจะเปิดขึ้น

พารามิเตอร์ของบล็อกนี้คือ:

• เงื่อนไขขอบเขต: ขีดจำกัดช่วงบน (UpLimit) และล่าง (DownLimit) ที่ต้องตรวจสอบ
• เวลาเปิดรับแสงของระบบที่ต้องการในช่วงขอบเขต (TimeInterval) ในหน่วยวินาที
• ขอ ID ReqName;
• การอนุญาตให้เกินช่วง Out_range เป็นตัวแปรบูลีนที่กำหนดว่าค่าที่เกินช่วงที่เลือกถือเป็นการละเมิดข้อกำหนดหรือไม่

ในบางกรณี ผลลัพธ์ของค่าทดสอบบ่งชี้ว่าระบบมีระยะขอบและอาจทำงานอยู่นอกช่วงการทำงาน ในกรณีอื่นๆ เอาต์พุตหมายความว่าระบบไม่สามารถรักษาค่าที่ตั้งไว้ให้อยู่ภายในช่วงได้

รูปที่ 6 บล็อกตรวจสอบคุณสมบัติทั่วไปในไดอะแกรมและพารามิเตอร์

จากผลการคำนวณของบล็อกนี้ ตัวแปร Result จะถูกสร้างขึ้นที่เอาต์พุต ซึ่งรับค่าต่อไปนี้:

• 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
• การใช้การจัดระเบียบข้อมูลแบบแบตช์ช่วยให้คุณสร้างแพ็คเกจการตรวจสอบข้อกำหนดควบคู่ไปกับการพัฒนาโมเดล หรือแม้แต่ใช้แพ็คเกจเหล่านี้เป็นข้อกำหนดทางเทคนิคสำหรับการพัฒนาโมเดล
• เทคโนโลยีนี้สามารถบูรณาการเข้ากับระบบการจัดการความต้องการที่มีอยู่ได้โดยไม่มีค่าใช้จ่ายจำนวนมาก

สำหรับผู้ที่อ่านจนจบ ลิงก์ไปยังวิดีโอที่แสดงวิธีการทำงานของต้นแบบ

ที่มา: will.com