จะทำการดัดแปลงซอฟต์แวร์ให้เป็นแบบเรียลไทม์ได้อย่างไร? [ปิด]

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

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

คำถามเต็ม: เราได้นำซอฟต์แวร์มัลติโพรเซสเซอร์ข้ามแพลตฟอร์มที่ซับซ้อนมาพร้อมกับการสื่อสารระหว่างกระบวนการสำหรับ Linux, Windows, Android และ QNX ภาษาการเขียนโปรแกรมคือ C ++ เราใช้ Boost และ planty ของ libs อื่น ๆ ซอฟต์แวร์ของเราทำงานได้ดีและรวดเร็ว แต่ก็ยังเป็นเครื่องต้นแบบอยู่ เพื่อจุดประสงค์ในการผลิตเราต้องดำเนินการตามเวลาจริงคุณสมบัติบางอย่างของเราต้องเป็นแบบเรียลไทม์และแข็งแกร่งมากเพราะมันมีความสำคัญและความปลอดภัยของคนที่ใช้ซอฟต์แวร์ของเราอาจขึ้นอยู่กับคุณสมบัติเหล่านั้น พวกมันทำงานได้อย่างรวดเร็ว - มากถึงหลายร้อยมิลลิวินาที แต่ฉันไม่แน่ใจว่าระบบของเราเป็นแบบเรียลไทม์เนื่องจากความจริงข้อนี้ (ฉันพูดถูก)

ดังนั้นจึงมีคำถามหลัก: วิธีการปรับเปลี่ยนซอฟต์แวร์ของเราเป็นเรียลไทม์? ฉัน googled มาก แต่ก็ยังไม่รู้จะทำยังไง

ข้อมูลเพิ่มเติมเกี่ยวกับแพลตฟอร์มของเรา: Linux และ Windows ปัจจุบันเราใช้เพื่อการทดสอบเท่านั้น Android - เรายังไม่ได้ตัดสินใจว่าต้องการหรือไม่ QNX - เป็นระบบปฏิบัติการเป้าหมายของเราสำหรับการผลิต ฉันเดาว่าคำตอบสำหรับคำถามต่อไปของฉันคือ "ไม่" :) แต่เป็นไปได้หรือไม่ที่จะรวมซอฟต์แวร์ข้ามเวลาแบบเรียลไทม์ (สำหรับ OS แบบเรียลไทม์ (RTOS) เช่นเดียวกับ OS ทั่วไป (GPOS))

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

ฟาสต์ไม่ได้หมายถึงเรียลไทม์และเรียลไทม์ไม่ได้แปลว่ารวดเร็ว

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

ตัวอย่างเช่นลองนึกถึงเครื่องเล่นวิดีโอ หากเฟรมวิดีโอไม่แสดงในอัตราที่เหมาะสมผู้ใช้จะไม่พอใจ ยิ่งถ้าภาพและเสียงไม่ตรงกัน

ตัวอย่างนี้แสดงว่าแอปพลิเคชันแบบเรียลไทม์บางตัวสามารถนำไปใช้กับระบบปฏิบัติการที่ใช้งานทั่วไปในปัจจุบัน

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

ตามที่@mouvicielได้กล่าวไปแล้วเรียลไทม์และฟาสต์เป็นคุณสมบัติสองอย่างที่เป็นอิสระแม้ว่าจะถึงกำหนดเวลาแบบเรียลไทม์จำนวนมากแสดงว่าต้องการการตอบสนองที่รวดเร็ว

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

แหล่งทั่วไปของความไม่แน่นอนสามารถพบได้ใน

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

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

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

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

• ความถี่ในการป้อนข้อมูลการโพลและระยะเวลานี้
• เวลาแฝงสัญญาณอินเทอร์รัปต์อินพุต
• เวลาสลับบริบทระบบปฏิบัติการเมื่อคุณมีเหตุการณ์อินพุต
• การจัดลำดับความสำคัญของระบบปฏิบัติการของงาน
• หลีกเลี่ยงการใช้การจัดสรรแบบไดนามิกหรือหน่วยความจำเสมือนในโปรแกรมเพื่อหลีกเลี่ยงความล่าช้าในการตอบสนองที่ไม่แน่นอนหรือเหตุการณ์ OOM
• หลีกเลี่ยงการใช้การรวบรวมขยะ
• หลีกเลี่ยงการใช้ O (n) หรืออัลกอริทึมที่แย่กว่าด้วย N หรือที่คาดเดาไม่ได้สูง (โหลดเพลย์ลิสต์ขนาดใหญ่มากเข้าไปในระบบความบันเทิงในรถของคุณชะลอการตอบสนองการเบรกหรือไม่)
• พิจารณาความล่าช้าของดิสก์หรือเครือข่าย (เช่นการใช้ CAN บัสในรถยนต์)
• แฝงการควบคุมผลลัพธ์

ในสภาพแวดล้อมแบบนี้มักจะมีการพิจารณาเป็นพิเศษสำหรับความน่าเชื่อถือเช่นมาตรฐาน MISRA C