อะไรคือ RTOS(ระบบปฎิบัติการตามเวลาจริง)

RTOS มาจากสองคำ RT กับ OS

(Real time) Real time เวลาจริง หรือเวลาตามความเป็นจริง ระบบที่ตอบสนองต่อการตอบรับสัญญาณหรือคำสั่งงานภายนอกที่มีกำหนดขอบเขตของเวลาที่จำกัดแน่นอน

(OS )operating system โปรแกรมระบบที่จัดสรรการเข้าถึงระหว่าง hardware กับ application โดยมีคุณสมบัติทั่วไปดังนี้

• Multitasking

• synchronization

• Interrupt และ event handing

• Input/Output

• Inter-task communication

• Timer และ Clock memory management

ทั้งหมดนี้เพื่อตอบสนองตามความต้องการทั้งหมดที่ใช้ใน application program

ดังนั้น RTOS คือระบบปฎิบัติการที่สนับสนุนการทำงานของ application ตามเวลาจริง ที่สามารถกำหนดขอบเขตของจุดสิ้นสุดเวลาและทรัพยากรของระบบ

ทำไมต้องเป็น application ที่ทำงานตามเวลาจริง

RTOS ไม่ได้ต้องการ application ตามเวลาจริงทั้งหมดในระบบ Embedded system Embedded system ในหม้อหุ้งข้าว อิเล็กทรอนิค ไม่ได้ต้องการ RTOS แต่เป็นเพราะความต้องการการใช้งานที่ซับซ้อนของ application ที่เกี่ยวกับงานต่างๆ ที่ต้องการเวลาที่แน่นอน จึงต้องมี RTOS นำไปใช้ในงาน อาทิเช่น ควบคุมเครื่องจักร เครื่องบิน ยานอวกาศ ฯลฯ

embedded system มีการพัฒนาระบบ hardware ที่ซับซ้อนในทุกรุ่น มีคุณสมบัติที่ถูกใส่เข้าไปมากขึ้น application program ที่รันใน embedded system จึงต้องมีการเพิ่มความซับซ้อนมากขึ้นตาม hardware RTOS เป็นระบบปฎิบัติการเวลาจริงถูกออกแบบและอธิบายการใช้งานได้ตามรูปภาพด้านล่าง

 

การแบ่งกลุ่มของ RTOS

RTOS แบ่งออกได้สามชนิดคือ

 

Hard-real time

ระบบที่กำหนดเวลาการตอบสนอง การตอบสนองหากเกินกว่าหรือเท่ากับเวลาที่กำหนดไว้ระบบจะเสียหาย

 

Firm-real time

ระบบที่กำหนดเวลาการตอบสนอง หากการตอบสนองเกินกว่าเวลาที่กำหนด ระบบไม่สามารถยอมรับ คุณภาพระบบลดลง

 

Soft-real time

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

 

ความเข้าใจผิดเกี่ยวกับ RTOS

RTOS ต้องเร็ว

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

 

กล่าวว่า RTOSใช้ CPU เกินขีดจำกัด

RTOSโดยปกติมีความต้องการใช้ CPU 1%-4% ของCPU time

 

RTOS ทั้งหมดเหมือนกัน

RTOS ถูกออกแบบในสามชนิดของ ระบบปฎิบัติการเวลาจริง hard firm soft อาจจะมีเพิ่มเติมในส่วนของชนิดของ hardware 8 bit 16 bit 32bit MPU

 

คุณสมบัติของ RTOS

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

 

multitasking และ Preemptibility (ทำได้หลายงานและมีการขัดจำหวะได้)

RTOSต้องทำงานหลายๆงานพร้อมกันและสามารถขัดจังหวะใน real-time application การจัดการต้องมีการขัดจังหวะงานที่ทำอยู่ได้ เมื่องานนั้นมีภาระที่ต้องทำให้เร็วที่สุด

 

Task priority (ลำดับความสำคัญของงาน)

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

 

Reliable　และ Sufficient Inter Task Communication Mechanism (ความเชื่อถือได้ของความสามารถเพียงพอสำหรับการติดต่อสื่อสารกันระหว่างงาน)

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

 

Priority Inheritance (การสืบทอดความสำคัญของงาน)

เพื่อใช้งานได้ตามระดับความสำคัญของงาน RTOS ต้องมีจำนวนระดับความสำคัญที่เพียงพอกับการจัดการงาน

 

Predefine short Latencies (การกำหนดสถานะเมื่อเกิดความล่าช้า)

RTOS ต้องมีความแม่นยำของกำหนดเวลาสั้นๆที่ใช้ใน system call มีพฤติกรรมดังนี้

 

Task switching Latency

เวลาที่ต้องบันทึกสถานะงานปัจจุบันก่อนไปทำงานอื่น

 

Interrupt latency

เวลาของงานที่ถูกขัดจังหวะครั้งหลังสุด ถึงการเริ่มขัดจังหวะ

 

Interrupt dispatch latency

เวลาจากการรันท้ายสุดของการขัดจังหวะถึงก่อนที่จะไปงานถัดไป

 

Control of Memory Management

เพื่อให้แน่ใจว่าสามารถทำนายพฤติกรรมของการขัดจังหวะได้ RTOS ควรมีการล็อคงานที่ทำอยู่ code และ data ที่อยู่ใน memory จริง

 

RTOS Architecture

สถาปัตยกรรมของ RTOS ขึ้นอยู่กับเรานำไปใช้งาน RTOS ที่ต้องสามารถปรับให้เข้ากับความแตกต่างของการนำไปใช้งาน ยกตัวอย่าง application ง่ายๆ RTOS ประกอบด้วย Kernel ความซับซ้อนของ library ที่รวมใน kernel ขึ้นอยู่กับการนำไปใช้งานต่างๆ ยกตัวอย่างเช่น network protocol stack

และส่วนประกอบอื่นๆ ตามภาพ

 

 

ระบบปฎิบัติการประกอบด้วยสองส่วน kernel space (kernel mode )และ User space (User mode)

kernel เป็นส่วนที่เล็กที่สุดและเป็นศูนย์กลางของระบบปฎิบัติการมี service ในการจัดการ memory และ device และยังช่วยในการจัดการการเชื่อมต่อระหว่าง software และทรัพยากร hardware อาจจะมี service เพิ่มเติมของ program ในการจัดการเรื่อง multi-tasking ขึ้นอยู่กับการสถาปัตยกรรม hardware

มีสามรูปแบบ

Monolithic kernel

Service พื้นฐานของระบบทั้งหมดทุกอย่างอยู่ใน kernel space อาทิเช่นmemory management ,interrupt handling และ I/O communication file system และอื่น monolithic kernel มีประสิทธิภาพในส่วนการจัดการข้อความติดต่อการระหว่าง hardwareได้เร็ว ทำให้มีความสามารถในการรันได้เร็วกว่า micro kernel นำไปใช้ใน Linux และ Window

Microkernel

รันโดยระบบพื้นฐานของการติดต่อการด้วย process ส่งข้อความเพื่อควบคุม I/O file system และ network อยู่ใน user space ในรูปแบบของ daemon server ดังนั้น micro kernel จึงเล็กในเรื่องของการเข้าถึง hardware และมีความเสถียรมากกว่า monolithic kernel ไม่ผลกระทบหาก server ล้มเหลว ยกตัวอย่าง เมื่อใช้ file system ใน server ถูกนำไปใช้ใน AmigaOS และ QNX

Exokernel

เป็นรูปแบบผสมระหว่าง micro กับ monolithic kernel ให้ application ควบคุม hardware รันเฉพาะ service เท่านั้นที่ปกป้องทรัพยากรเท่านั้น เช่นการ สิทธิ์การเป็นเจ้าของ การปัองการใช้ การเข้าถึง ทรัยากรและอื่น และยกเลิกการจัดการของ applicationโดยใช้ Lowel level libraryสำหรับระบบปฎิบัติการ (libOSes)

 

โดยปกติ RTOS จะหลีกเลี่ยงการใช้ Kernel ที่มีขนาดใหญ่อย่าง monolithic program kernel จะใช้ micro kernel แทนที่เพราะสามารถตั้งค่าตามรูปแบบที่ต้องการ การใช้แบบนี้จะมีผลดีเพราะสามารถตั้งค่าในแต่ละ embedded application ที่ต้องการได้

kernel ของ RTOS จะมีส่วนประกอบต่างๆ ที่ใช้เกี่ยวกับ application กับ hardwareเจ็ดอย่างหลัก ตามรูป

Task management (การจัดการงาน)

ตัวจัดการงาน ให้ Programmer สามารถออกแบบ software ตามจำนวนของการแยกของ chunk (Heap memory management )เพื่อจัดการจุดมุ่งหมายและจุดเส้นตายของงาน service นี้ใช้ในตัวจัดการงาน (scheduler)

Task object

เพื่อให้งาน Real-time applicationทำงานได้ application ถูกแบ่งเป็นส่วนเล็กๆ scheduler และลำดับของหน่วย program ที่เรียกว่า task ในรูปแบบของ real-time มีพื้นฐานการรัน มีรูปแบบเวลาที่สำคัญสามแบบ

release time: เวลาก่อนงานเริ่ม

deadline time: เวลาที่งานต้องสมบูรณ์

execution time เวลาที่รันงานรัน

ใน task object มีการกำหนดดังนี้

task control block โครงสร้างข้อมูลของงานที่อยู่ภายใน RAM เข้าถึงโดย RTOS

โครงสร้างของ TCB

 

task stack ข้อมูลที่อยู่ในโปรแกรม RAM เข้าถึงโดย stack pointer

task routine คือ program code ที่อยู่ใน ROM

การรันงานใน CPU จะมีแค่หนึ่งงาน เมื่อ cpu กำลังทำงานอยู่แล้วเปลี่ยนไปทำงานอื่นจะมีการบันทึกสถานะถ้างานนั้นยังทำไม่เสร็จและเรียกคืนรายละเอียดทั้งหมดเพื่อทำงานต่อ เรืยกว่า context switchingแต่ละงานที่รันมีสี่สถานะ

• running CPU กำลังรันงานนั้นอยู่

• ready รองานการขัดจังหวะจากงานที่ลำดับสำคัญสูงกว่ารันอยู่

• dormant งานสร้างขึ้นรอไว้แต่ไม่เปิดใช้งาน

• blocked งานที่หยุดรอการกระตุ้นจากการ event ภายนอก

  

  Scheduler(ตัวจัดการงาน)

  การจัดตารางงานจะบันทึกสถานะของแต่ละงานเพื่อเลือกนำงานที่พร้อมรันเข้าใช้ใน CPU schedulerจะช่วยให้การใช้ CPU มีประโยชน์สุงสุด ในหลายรูปแบบการทำงาน multi-tasking ที่การสูญเสียเวลาการรอน้อยที่สุด โดยปกติ scheduler มีสองรูปแบบ

  Non-preemptive คือจัดการงานแบบ multi-tasking โดยเรียงคิวเข้าทำงาน งานใหม่ที่มีความสำคัญมากต้องรองานปัจจุบันให้เสร็จก่อนจึงรันต่อไป

   

  
  

   

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

   

  

    

Task Synchronization (การประสานข้อมูลของงาน)

การประสานข้อมูลมีความสำคัญในใช้ทรัพยากรร่วมกัน อย่างเช่น device หรือ buffer การให้ task หลายๆ ถูกรัน ยกตัวอย่าง Task A ต้องผลจาก Task B ดังนั้น Task A สามารถรันจนกระทั้ง Task B ทำให้ผลให้ A ประสานข้อมูลมีสองรูปแบบ

Event object 

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

 

การใช้ข้อมูลร่วมกันหลังการกระตุ้นอาจไม่ดีพอ task A ยังไม่ประมวลผลเสร็จ task B เข้าประมวลซ้ำทำให้ข้อมูลเสียหายได้ RTOS จึงมี service semaphore ที่เป็นการรองรับข้อมูลที่ใช้ร่วมกันอีกแบบ

semaphore คือการเข้าถึงทรัพยากรด้วยการนับรอคิว การนับเป็นการบอกว่าทรัพยากรสามารถเข้าถึงได้ตามการรอคิวของ semaphore semaphore เป็น function ที่ใช้เป็น key ในการเข้าถึง resource ที่ต้องการ มีวิธีการนับ semaphore สามรูปแบบ

binary semaphore (ค่าsemaphore =0 หรือ 1 ให้เข้าถึงได้และไม่ได้)

counting semaphore (ค่า semaphore=0 หรือมากกว่า สามารถได้รับและปล่อยให้เข้าถึงได้หลายๆ ครั้ง)

mutually exclusion Semaphore ( ค่าsemaphore =0 หรือ 1 , ล็อคคือ 0 และมากกว่า 0 คือล็อคแบบวนซ้ำ)

 

 

Intertask communication (การติดต่อสื่อสารระหว่างงาน)

 

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

• Message queues
• Pipes
• Remote procedural call (RPC)

 

message queues เป็น object ที่ใช้ติดต่อสื่อสารระหว่างงานที่มีการส่งรับรับข้อความถูกวางใน shared memory งาน และ ISRs จะส่งและรับข้อความผ่านคิวใน kernel งานจะมองหาข้อความจากคิวที่ว่างและระยะเวลาจนกระทั่งได้รับข้อความ การส่งข้อความและรับมีรูปแบบคิวดังต่อไปนี้

1 First in First Out (FIFO) ข้อมูลมาก่อนเข้าก่่อน ข้อมูลมาก่อนออกก่อน

2 last in Fist out (LIFO) ข้อมูลมาที่หลังเข้าก่อน ข้อมูลมาก่อนออกก่อน

3 Priority sequence (PRI) ตามลำดับความสำคัญ

โดยปกติ การเปรียบเทียบข้อความ เรียกว่า queue control block(QCB) มีรายละเอียดข้อมูล คือ ชื่อ , ID เฉพาะ,memory buffer,ขนาดความยาวมากที่สุดต่อข้อความ บางทีหนึ่งงานหรือรอมากกว่าหนึ่งงาน message queue จะมีขนาดของคิวเท่ากับ 1 หรือที่รู้จักกันว่าเป็น mailbox

 

Pipes เป็น object เป็นสื่อสารแบบท่อไม่มีโครงสร้างของข้อมูล แลกเปลี่ยนกันระหว่าง task , pipes สามารถเปิด ปิด เขียน อ่าน เป็นท่่อสตรีมข้อมูล ไม่มีโครงสร้างข้อมูลเหมือน message queue อ่านผ่าน pipe เป็นแบบ FIFO การไหลของข้อมูลไม่สามารถจัดการลำดับความสำคัญได้

 

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

 

Memory management (การจัดการหน่วยความจำ)

โดยปกติ RTOS ออกแบบใช้ความจำที่น้อยตามความจำเป็นของ user application จะมี memory สองชนิดที่มีการจัดการใน RTOSคือ Heap และ stack

ในงาน multi-tasking จะจองหน่วยความจำแต่ละงานต้องการเก็บ context ของตัวเอง (สถานะของตัวเอง) เรียกว่า TCB task control block ดังที่กล่าวมาแล้วในหัวข้อ task management ใช้เก็บข้อมูล เช่น ค่าregister program counter ฯลฯ สำหรับ context switching กลุ่มของ memory นี้เรียกว่า kernel stack กระบวนการจัดการ memory เหล่านี้เรียกว่า stack management

เมื่อโปรแกรมเริ่มรันสมบูรณ์ program code program data และ system stack โหลดลงใน physical memory ของ MPU หรือ MCU ที่เหลือเป็น heap memoryเพื่อให้ kernel ได้จองหน่วยความจำของข้อมูลที่จะใช้ในงาน แบ่งขนาดตายตัวเป็น block สามารถเลือกใช้ได้ เมื่อสิ้นสุดงาน memory ส่วนนี้จะถูกปล่อยคืนสู่่ระบบ กระบวนการนี้เรียกว่า heap management

 

Timer management (การจัดการเวลา)

ในระบบ embedded system งานที่ผู้ใช้ บ่อยครั้งการจัดการงานจะทำ หลังจากกำหนดช่วงเวลาแล้ว การจัดการงาน ต้องการขัดจังหวะเป็นช่วงๆ เพื่อรักษาช่วงเวลาที่กำหนดเลยไปและจุดสิ้นสุนเวลา RTOS กำหนดหน่วย timer ที่เกี่ยวกับหน่วยเวลา มีหน่วยเป็น tick และ “absolute time” เป็นเวลาของปฏิทินในแต่ละ ชนิด timer task delay service หรือ อาจเรียกว่า task alert service จะมีการกลไกส่งสัญญาณเพื่อบอกสถานะของ event Timer service อื่นก็จะหาจุดเวลาที่พบกันของงานภายใต้ จุดสิ้นสุดเวลาที่กำหนด เพื่อพิจารณาความเป็น real-time

 

Interrupt และ event handing (จัดการงานเมื่อมีการขัดจังหวะ)

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

• กำหนดงานเกี่ยวกับการจัดการขัดจังหวะที่มีเข้ามา
• สร้างและลบเส้นทางของการขัดจังหวะ (ISR)
• อ้างอิงใหม่เกี่ยวกับสถานะของเส้นทางการขัดจังหวะ(ISR)
• เปิดและปิดใช้งานของการขัดจังหวะ
• เปลี่ยนแปลงแล้วอ้างอิงใหม่เกี่ยวกับ interrupt mask (mask bit เพื่อไม่รับการขัดจังหวะได้ )

เพื่อให้แน่ใจว่า

ความสมบูรณ์ของข้อมูลที่ประมวลผลอยู่หลังจากเกิดการขัดจังหวะ

ความล่าช้าสั้นที่สุดของการปิดใช้งานการขัดจังหวะในกรณีที่ RTOSต้องทำงานที่สำคัญที่สุดก่อน

การขัดจังวะที่เป็นไปได้เร็วที่ใช้ทดสอบ ประสิทธิภาพ preemptive ของ RTOS

ระยะเวลาการขัดจังหวะที่สั้นที่สุดที่เป็นไปได้และใช้ CPUต่ำสุด

 

Device I/O management (การจัดการอุปกรณ์ input และ output)

RTOS kernelมีเครื่องมือที่ไว้จัดการ device I/O serviceเป็น รูปแบบframework ให้ใช้ตาม application programmer ‘s interface -API

เพื่อการจัดการระบบอุปกรณ์ hardware จำนวนมาก อย่างไรก็ตาม driver API ทั้งหมดส่วนที่เป็นตัวจัดการสูงสุดจะเป็นไปตามรูปมาตราฐานตาม RTOS กำหนด