มาตรฐาน ARINC 653 ฉบับแรกได้รับการเผยแพร่เมื่อวันที่ 10 ตุลาคม พ.ศ. 2539

เอกสารเสริมฉบับที่ 1 ได้รับการตีพิมพ์ในเดือนมกราคม พ.ศ. 2540 และได้แนะนำแนวคิดของ APEX และการแบ่งพาร์ติชันตามเวลาและพื้นที่

ภาคผนวก 2 ได้รับการตีพิมพ์เป็น 3 ส่วน ระหว่างเดือนมีนาคม พ.ศ. 2549 ถึงมกราคม พ.ศ. 2550: ^{[ 3 ]}

• ส่วนที่ 1 (บริการที่จำเป็น): การจัดการพาร์ติชัน ARINC 653, การกำหนดค่าการเริ่มต้นแบบเย็นและการเริ่มต้นแบบอุ่น, การจัดการข้อผิดพลาดของซอฟต์แวร์แอปพลิเคชัน, การปฏิบัติตามมาตรฐาน ARINC 653, การเชื่อมโยงภาษา AdaและC ;
• ส่วนที่ 2 (บริการเสริม): การเข้าถึง ระบบไฟล์ , การบันทึกข้อมูล , จุดเชื่อมต่อบริการ, ...
• ส่วนที่ 3 (ข้อกำหนดการทดสอบความสอดคล้อง)

• ส่วนที่ 0 - บทนำสู่ ARINC 653 (ปัจจุบันอยู่ที่การแก้ไขครั้งที่ 3 เผยแพร่เมื่อเดือนพฤศจิกายน 2021) ^{[ 4 ]}

• ส่วนที่ 1 - บริการที่จำเป็น (ปัจจุบันอยู่ในภาคผนวก 6 ซึ่งเผยแพร่ในเดือนธันวาคม 2024) ^{[ 5 ]}
• ส่วนที่ 2 - บริการเพิ่มเติม (ปัจจุบันอยู่ที่ภาคผนวก 5 ซึ่งเผยแพร่ในเดือนธันวาคม 2024) ^{[ 6 ]}
• ส่วนที่ 3A - ข้อกำหนดการทดสอบความสอดคล้องสำหรับบริการที่จำเป็น (ปัจจุบันอยู่ที่การแก้ไขครั้งที่ 2 เผยแพร่เมื่อเดือนพฤศจิกายน 2021) ^{[ 7 ]}
• ส่วนที่ 3B - ข้อกำหนดการทดสอบความสอดคล้องสำหรับบริการขยาย (ปัจจุบันอยู่ที่การแก้ไข c1 เผยแพร่เมื่อกรกฎาคม 2562) ^{[ 8 ]}
• ส่วนที่ 4 - บริการชุดย่อย (ปัจจุบันอยู่ที่เวอร์ชัน 0 เผยแพร่เมื่อเดือนมิถุนายน 2555) ^{[ 9 ]}
• ส่วนที่ 5 - ความสามารถที่แนะนำของซอฟต์แวร์หลัก (ปัจจุบันอยู่ที่การแก้ไขครั้งที่ 1 เผยแพร่เมื่อเดือนสิงหาคม 2562) ^{[ 10 ]}

แพลตฟอร์ม ARINC 653 ประกอบด้วย:

• แพลตฟอร์มฮาร์ดแวร์ที่ช่วยให้สามารถประมวลผลแบบเรียลไทม์และบริการที่กำหนดได้อย่างแม่นยำ
• ชั้นนามธรรมที่จัดการตัวจับเวลาและข้อจำกัดในการแบ่งพื้นที่ของแพลตฟอร์ม ( หน่วยความจำ , CPU , อินพุต/เอาต์พุต )
• การใช้งานสำหรับบริการ ARINC 653 (APEX API)
• ส่วนติดต่อผู้ใช้เพื่อให้สามารถกำหนดค่าแพลตฟอร์มและขอบเขตการใช้งานได้
• เครื่องมือวัดต่างๆ

การเริ่มต้นพาร์ติชัน ARINC 653 จะสร้างทรัพยากรที่พาร์ติชันนั้นใช้ การสร้างทรัพยากร (PROCESS, EVENT, SEMAPHORE...) ทำได้โดยการเรียกใช้บริการ API ที่ชื่อCREATE_xxxx

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

API อนุญาตให้ตัวจัดการข้อผิดพลาดหยุดกระบวนการที่ทำงานผิดพลาด ( STOP_SELF ) ในกรณีนั้นตัวจัดตารางเวลา ของ RTOS จะดึงกระบวนการถัดไปที่มีลำดับความสำคัญสูงสุดขึ้นมา

มาตรฐาน ARINC 653 ไม่ได้ระบุว่าตัวจัดตารางเวลาควรทำงานอย่างไรหากตัวจัดการข้อผิดพลาดไม่หยุดกระบวนการที่ผิดพลาด ในบางกรณี (ตามทฤษฎี) อาจนำไปสู่การวนลูปไม่สิ้นสุดระหว่างกระบวนการที่ผิดพลาดและตัวจัดการข้อผิดพลาด

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

แต่ละพาร์ติชั่นสามารถอยู่ในโหมดการเปิดใช้งานได้หลายโหมด:

• COLD_START และ WARM_START: จะดำเนินการเฉพาะกระบวนการเริ่มต้นเท่านั้น
• ปกติ: กระบวนการเริ่มต้นจะหยุดลง และกระบวนการพาร์ติชันอื่นๆ จะถูกเรียกโดยตัวจัดตารางเวลาของระบบปฏิบัติการ แบบเรียลไทม์ (RTOS) โดยขึ้นอยู่กับลำดับความสำคัญของกระบวนการเหล่านั้น
• สถานะว่าง: ไม่มีกระบวนการใดถูกเรียกใช้งาน อย่างไรก็ตาม ในทางทฤษฎีแล้ว การใช้งานอาจยังคงเรียกใช้กระบวนการที่ซ่อนไว้ซึ่งมีลำดับความสำคัญต่ำที่สุด เช่น เพื่อเริ่มต้นลูปที่ไม่สิ้นสุด

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

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

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

มาตรฐาน ARINC 653 P1-5 ได้รับการปรับปรุงเพื่อรองรับ สถาปัตยกรรมโปรเซสเซอร์ แบบมัลติคอร์ส่วนที่ 4.2.1 "การปฏิบัติตามข้อกำหนดการใช้งานมัลติคอร์ของระบบปฏิบัติการ" ระบุว่าระบบปฏิบัติการที่ออกแบบมาสำหรับการประมวลผลแบบมัลติคอร์ควรสนับสนุนสองกรณีดังนี้:

• การใช้งานหลายคอร์โดยพาร์ติชันเดียว (ซึ่งกระบวนการต่างๆ ของพาร์ติชันนั้นใช้หลายคอร์)
• การใช้งานหลายคอร์โดยหลายพาร์ติชัน

เอกสารแสดงจุดยืนCAST-32Aกำหนดชุดข้อกำหนดและแนวทางที่ควรปฏิบัติตามเพื่อรับรองและใช้งานโปรเซสเซอร์มัลติคอร์ในการบินพลเรือนโดย FAA และคาดว่าจะถูกแทนที่ด้วยหนังสือเวียนแนะนำ AC 20-193 หน่วยงานการบินของสหภาพยุโรป EASA ได้เผยแพร่ AMC 20-193 ในเดือนมกราคม 2022 ^{[ 11 ]}