ในการพัฒนาระบบฝังตัวที่สามารถทำงานแบบเรียลไทม์ได้ หนึ่งในคำถามแรกและสำคัญที่สุดคือ แอปพลิเคชันควรทำงานภายใต้ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) หรือควรพัฒนาระบบแบบ bare-metal การเขียนโปรแกรมแบบ bare-metal โดยทั่วไปหมายถึงการเขียนแอปพลิเคชันลงบนฮาร์ดแวร์โดยตรงโดยไม่ต้องใช้ส่วนต่อประสานการเขียนโปรแกรมภายนอก เช่น ระบบปฏิบัติการ แอปพลิเคชันในที่นี้จะเข้าถึงรีจิสเตอร์ฮาร์ดแวร์ของไมโครคอนโทรลเลอร์โดยตรง ในกรณีนี้จะใช้แนวทางต่างๆ เช่น ลูปไม่สิ้นสุด ซึ่งจะทำงานต่างๆ ด้วยเวลาการประมวลผลคงที่ การทำงานตามลำดับนี้จะหยุดชะงักก็ต่อเมื่อเกิดเหตุการณ์ขัดจังหวะเท่านั้น ดังนั้นแนวทางการพัฒนาแบบ bare-metal สำหรับระบบฝังตัวนี้จึงเรียกอีกอย่างว่า super-loop

สร้างเองหรือซื้อ - การพัฒนาบนฮาร์ดแวร์โดยตรงเทียบกับระบบปฏิบัติการแบบเรียลไทม์ (RTOS)

ในการพัฒนาระบบฝังตัวที่สามารถทำงานแบบเรียลไทม์ได้ หนึ่งในคำถามแรกและสำคัญที่สุดคือ แอปพลิเคชันควรทำงานภายใต้ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) หรือควรพัฒนาระบบแบบ bare-metal การเขียนโปรแกรมแบบ bare-metal โดยทั่วไปหมายถึงการเขียนแอปพลิเคชันลงบนฮาร์ดแวร์โดยตรงโดยไม่ต้องใช้ส่วนต่อประสานการเขียนโปรแกรมภายนอก เช่น ระบบปฏิบัติการ แอปพลิเคชันในที่นี้จะเข้าถึงรีจิสเตอร์ฮาร์ดแวร์ของไมโครคอนโทรลเลอร์โดยตรง ในกรณีนี้จะใช้แนวทางต่างๆ เช่น ลูปไม่สิ้นสุด ซึ่งจะทำงานต่างๆ ด้วยเวลาการประมวลผลคงที่ การทำงานตามลำดับนี้จะหยุดชะงักก็ต่อเมื่อเกิดเหตุการณ์ขัดจังหวะเท่านั้น ดังนั้นแนวทางการพัฒนาแบบ bare-metal สำหรับระบบฝังตัวนี้จึงเรียกอีกอย่างว่า super-loop

ตรงกันข้ามกับการเขียนโปรแกรมแบบ bare-metal ระบบฝังตัวที่ใช้ RTOS จะใช้เคอร์เนลของระบบปฏิบัติการร่วมกับตัวจัดตารางเวลาหรือไดรเวอร์อุปกรณ์ระหว่างฮาร์ดแวร์และโค้ดแอปพลิเคชัน ข้อดีคือทำให้สามารถทำงานแบบมัลติเธรดได้ ซึ่งมีความสำคัญอย่างยิ่งหากแทนที่จะทำงานเพียงไม่กี่อย่างที่กำหนดไว้อย่างชัดเจนและสามารถกำหนดทรัพยากรได้อย่างดี แต่ต้องทำงานหลายอย่างบนฮาร์ดแวร์ โดยที่แต่ละงานสามารถจัดลำดับความสำคัญได้อย่างสะดวก และสามารถรวมประสิทธิภาพของคอร์ CPU หลายตัวเข้าด้วยกัน กล่าวอีกนัยหนึ่ง ระบบปฏิบัติการแบบเรียลไทม์พร้อมตัวจัดตารางเวลาช่วยให้กระบวนการต่างๆ สามารถทำงานพร้อมกันได้ และที่สำคัญที่สุดคือมีความยืดหยุ่นและจัดลำดับความสำคัญได้ และรับผิดชอบต่อการทำงานโดยรวมของระบบ

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

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

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

การชั่งน้ำหนักว่าการเขียนโปรแกรมโดยตรงบนฮาร์ดแวร์ (bare metal programming) นั้นเหมาะสมหรือไม่เหมาะสมนั้นไม่ใช่เรื่องง่ายเสมอไป แม้ว่าจะมีผู้สนับสนุนและผู้คัดค้านที่ยืนยันในแนวทางใดแนวทางหนึ่งอย่างชัดเจนก็ตาม แต่ยังมีแง่มุมอื่นๆ (ที่ไม่ใช่ด้านเทคนิค) ที่ควรพิจารณาด้วย นอกเหนือจากที่กล่าวมาแล้ว เช่น ความพยายามในการเขียนโปรแกรมโดยตรงสำหรับฮาร์ดแวร์นั้นๆ และความรับผิดชอบต่อแอปพลิเคชันโดยไม่มีข้อแม้ใดๆ ทั้งในแง่บวกและแง่ลบ การเขียนโปรแกรมโดยตรงบนฮาร์ดแวร์อาจกลายเป็นความเสี่ยงของโครงการได้ หากพนักงานขาดงานเป็นเวลานานโดยแจ้งล่วงหน้าเพียงเล็กน้อย การหาคนมาแทนอย่างรวดเร็วนั้นไม่ใช่เรื่องง่ายสำหรับโปรแกรมเมอร์ที่ใช้ภาษา C, Rust หรือ Python แต่เป็นเรื่องสำคัญอย่างยิ่งเมื่อต้องการทักษะการเขียนโค้ดภาษาแอสเซมบลี โดยเฉพาะอย่างยิ่งในโครงการที่มีความคืบหน้าไปมากและต้องการความเชี่ยวชาญเชิงลึก ในด้านเทคนิค มักมีการพิจารณาเรื่องความน่าเชื่อถือเข้ามาเกี่ยวข้อง แน่นอนว่าเมื่อความซับซ้อนเพิ่มขึ้น โอกาสที่จะเกิดข้อผิดพลาดก็เพิ่มขึ้นตามไปด้วย และในกรณีที่ดีที่สุด แอปพลิเคชันของบุคคลที่สามที่สามารถตรวจสอบได้ 100 เปอร์เซ็นต์ก็อาจได้รับการตรวจสอบ แต่ข้อผิดพลาดก็อาจเกิดขึ้นได้ในการเขียนโปรแกรมโดยตรงบนฮาร์ดแวร์เช่นกัน ข้อดีของระบบแอคทูเอเตอร์คือ ฟังก์ชันการทำงานบางอย่างได้รับการทดสอบภาคสนามและเป็นไปตามมาตรฐานความปลอดภัยที่เข้มงวด เช่น DO-178C ในด้านการบิน หรือ ISO 26262 ซึ่งทำให้มั่นใจได้ในระดับหนึ่งเกี่ยวกับฟังก์ชันการทำงาน

ระบบเครือข่ายและความปลอดภัย

ในปัจจุบัน เมื่อระดับการเชื่อมต่อเครือข่ายเพิ่มขึ้น โมดูลย่อยของแอปพลิเคชันหรือระบบฝังตัวก็ได้รับความสนใจมากขึ้นเรื่อยๆ ไม่ว่าจะเป็นด้วยเหตุผลด้านการบำรุงรักษาหรือการตรวจสอบประสิทธิภาพของระบบจากระยะไกล ดังนั้นความสามารถในการเปลี่ยนแปลงของแอปพลิเคชันที่มีอยู่จึงมีบทบาทมากขึ้นเรื่อยๆ แน่นอนว่ามีโมดูลบางส่วนที่จะไม่เชื่อมต่อเครือข่ายในอนาคต เช่น เพราะไม่ต้องการให้เสี่ยงต่ออันตรายด้านความปลอดภัยทางไอที ​​แต่พูดตามตรงก็ต้องยอมรับว่าในอนาคตโมดูลเหล่านั้นมักจะไม่ตรงตามความต้องการอีกต่อไป ทำให้จำเป็นต้องแก้ไขระบบหรือโค้ด ซึ่งอาจนำไปสู่ความยากลำบาก เพราะในกรณีของสถาปัตยกรรมฝังตัวแบบ bare-metal นั้น เวลาและเวลาตอบสนองถูกกำหนดโดยโครงสร้างของโค้ดและจะต้องเปลี่ยนแปลงเมื่อมีการเปลี่ยนแปลงหรือเพิ่มฟังก์ชันการทำงาน ส่งผลให้ความพยายามและระยะเวลาในการแก้ไขเพิ่มขึ้น ในทางตรงกันข้าม ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) มักจะให้ความยืดหยุ่นสูงในระบบเครือข่ายและมักมาพร้อมกับฟังก์ชันความปลอดภัยที่สร้างไว้ล่วงหน้า ต้องกล่าวด้วยว่าประเด็นเรื่องความปลอดภัยจะยิ่งมีความสำคัญมากขึ้น และทั้งผู้ใช้และโปรแกรมเมอร์จะต้องเผชิญกับคำถามที่ว่าพวกเขาต้องการระบบแบบเชื่อมต่อเครือข่ายหรือแบบไม่เชื่อมต่อเครือข่าย สำหรับกรณีแรก ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) เช่น PikeOS จาก SYSGO มีส่วนประกอบที่ได้รับการรับรองล่วงหน้าและรองรับแนวคิดด้านความปลอดภัยใหม่ๆ เช่น แนวทางความไว้วางใจเป็นศูนย์ (zero trust)

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

นามธรรมช่วยให้เกิดการบูรณาการ

ข้อได้เปรียบที่สำคัญของระบบปฏิบัติการแบบเรียลไทม์ (RTOS) คือระบบนิเวศที่มีอยู่มากมายในกรณีส่วนใหญ่ ระบบปฏิบัติการแบบเรียลไทม์หลายระบบมีมิดเดิลแวร์ที่ใช้งานง่าย เช่น ระบบไฟล์ USB หรือ TCP/IP ซึ่งสามารถผสานรวมได้อย่างง่ายดาย เช่นเดียวกับไดรเวอร์อุปกรณ์หรือส่วนประกอบอื่นๆ จากผู้พัฒนาภายนอก การใช้ RTOS จะเปลี่ยนส่วนประกอบเหล่านี้ให้เป็นส่วนประกอบแบบเสียบแล้วใช้งานได้ทันทีในซอฟต์แวร์ และสามารถเร่งความเร็วในการพัฒนาซอฟต์แวร์ได้อย่างมาก ดังนั้น การตัดสินใจใช้ซอฟต์แวร์จากผู้พัฒนาภายนอกจึงเป็นตัวบ่งชี้สำคัญว่าควรเลือกใช้ RTOS มากกว่าตัวจัดตารางเวลาแบบ bare-metal

การพยายามออกแบบระบบ bare-metal โดยใช้ middleware แบบนั้นจะใช้เวลานานมากและมีโอกาสเกิดข้อผิดพลาดสูง นอกจากนี้ RTOS ยังทำให้การพัฒนาโค้ดที่พกพาได้และนำกลับมาใช้ใหม่ได้ง่ายขึ้นมาก เนื่องจากโซลูชันที่ใช้ RTOS มักจะส่งผลให้เฟิร์มแวร์มีงานที่กำหนดไว้อย่างชัดเจนและเหมาะสมสำหรับการนำไปใช้ซ้ำ ยิ่งไปกว่านั้น การสร้างนามธรรมระหว่างฮาร์ดแวร์และแอปพลิเคชันโดยระบบปฏิบัติการทำให้การเปลี่ยนแปลงฮาร์ดแวร์หรือการรวมโมดูลของบุคคลที่สามทำได้ง่ายขึ้นมาก นอกจากนี้ RTOS ยังเป็นตัวเลือกเดียวหากคุณต้องการใช้โปรเซสเซอร์ที่ทันสมัยและทรงพลังที่มี MMU เนื่องจาก bare metal ไม่รองรับการกำหนดแอดเดรสเสมือน

ความปลอดภัย การรักษาความปลอดภัย และการรับรอง

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

เนื่องจากระบบที่สำคัญมักประกอบด้วยส่วนประกอบที่ไม่สำคัญมากนัก เช่น สแต็กการสื่อสาร นอกเหนือจากฟังก์ชันหลัก การแยก RTOS ที่ใช้เคอร์เนลและไฮเปอร์ไวเซอร์จึงมักเป็นสิ่งที่แนะนำ ด้วยระบบปฏิบัติการแบบเรียลไทม์ดังกล่าว การแยกแอปพลิเคชันที่สำคัญและไม่สำคัญอย่างเข้มงวดสามารถทำได้ผ่านการแบ่งส่วนทรัพยากรและเวลา ทำให้ระบบที่มีความสำคัญผสมกันสามารถใช้งานบนฮาร์ดแวร์เพียงเครื่องเดียวได้ ข้อกังวลที่เข้าใจได้ว่าอาจเกิดการรบกวนที่ส่งผลกระทบต่อความปลอดภัยนั้นได้รับการแก้ไขด้วยแนวทางปฏิบัติที่ได้รับการพิสูจน์แล้วโดยอิงตามมาตรฐานความปลอดภัยที่เข้มงวด ซึ่งยืนยันถึงระดับความน่าเชื่อถือที่สูงมากสำหรับระบบดังกล่าวบนพื้นฐานนี้ แต่ละพาร์ติชันสามารถรองรับระบบปฏิบัติการแขกที่แตกต่างกันได้ ทำให้แอปพลิเคชันที่ไม่สำคัญมากนักสามารถทำงานบน Linux แบบฝังตัว เช่น ELinOS ในขณะที่แอปพลิเคชันที่สำคัญทำงานบน ARINC (ด้านอวกาศ) AUTOSAR (ด้านยานยนต์) หรือ RTOS ดั้งเดิม ด้วย PikeOS ของ SYSGO ยังสามารถใช้งานพาร์ติชัน POSIX เพื่อจัดการงานที่มีความสำคัญปานกลางซึ่ง Linux อาจมีความเสี่ยงมากเกินไป

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

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

ด้วยระบบการแบ่งพาร์ติชัน PikeOS ยังมีเส้นทางการย้ายระบบจากระบบแบบ bare metal ไปสู่ระบบ RTOS ที่ค่อนข้างง่าย โดยเริ่มจากการติดตั้งแอปพลิเคชัน bare-metal ที่มีอยู่ลงในพาร์ติชันของตนเอง จากนั้นใช้การเรียก API เพื่อสื่อสารกับเคอร์เนล และผ่านเคอร์เนลไปยังแอปพลิเคชันอื่นๆ

ระบบสื่อสารจำเป็นต้องใช้ระบบปฏิบัติการแบบเรียลไทม์ (RTOS)

ท้ายที่สุดแล้ว การตัดสินใจว่าจะใช้ฮาร์ดแวร์จริงหรือระบบปฏิบัติการแบบเรียลไทม์ (RTOS) นั้นเป็นการตัดสินใจแบบคลาสสิกระหว่างการสร้างเองหรือซื้อสำเร็จรูป แง่มุมทางเศรษฐกิจมีบทบาทสำคัญ เช่นเดียวกับทิศทางการพัฒนาของระบบฝังตัว โดยเฉพาะอย่างยิ่งในส่วนของการเชื่อมต่อเครือข่าย การพัฒนาระบบขนาดเล็กและเรียบง่ายบนฮาร์ดแวร์จริงนั้นสมเหตุสมผล แต่ RTOS มีข้อได้เปรียบทางเศรษฐกิจในแง่ของผลตอบแทนจากการลงทุน (ROI) และต้นทุนรวมในการเป็นเจ้าของ (TCO) ที่ต่ำกว่า รวมถึงข้อได้เปรียบทางเทคโนโลยี (ในแง่ของการพัฒนาในอนาคตที่คาดการณ์ได้) นอกจากนี้ การนำโค้ดที่มีอยู่แล้วและเอกสารรับรอง (ถ้ามี) มาใช้ซ้ำ หมายความว่าความพร้อมสู่ตลาดมักจะรวดเร็ว ด้วยเหตุผลเดียวกันนี้ ฟังก์ชันใหม่ๆ ก็สามารถบูรณาการได้อย่างรวดเร็ว ประหยัด และปลอดภัยในการใช้งานด้วย RTOS โดยเฉพาะอย่างยิ่ง RTOS ที่ใช้ไฮเปอร์ไวเซอร์ นอกจากนี้ ระบบที่ใช้ RTOS ยังพร้อมสำหรับการพัฒนาในอนาคตในแง่ของความปลอดภัยด้านไอที ซึ่งหากปราศจากความปลอดภัยในการใช้งานแล้ว ก็ไม่สามารถรับประกันได้อีกต่อไปในสภาพแวดล้อมเครือข่ายในปัจจุบัน

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