რეალურ დროში ოპერაციული სისტემის შექმნის ისტორია. რეალურ დროში ოპერაციული სისტემები (RTOS)

(რეალურ დროში ოპერაციული სისტემები - RTOS) ეხება პროგრამულ უზრუნველყოფას და განკუთვნილია ციფრული სისტემების მომსახურებისთვის იმ შემთხვევებში, როდესაც:

● სისტემამ უნდა უზრუნველყოს არა მხოლოდ მიღებული ინფორმაციის დამუშავების შედეგი, არამედ შედეგის მიღების დრო. RTOS საჭირო შედეგის მიღებასთან ერთად საჭიროა განსაზღვრული დროის პარამეტრების განსახორციელებლად: მოვლენებსა და პასუხებს შორის დროის ინტერვალები ან გარე მონაცემების მიღებისა და შედეგების გაცემის განსაზღვრული სიხშირე;

● სისტემას შეუძლია შეასრულოს რამდენიმე დავალება ერთდროულად. Ტიპიური მრავალფუნქციურიოპერაციული სისტემა თითოეულ ამოცანას (პროგრამას) ერთსა და იმავე დროს უთმობს, რაც მომხმარებელს აძლევს შთაბეჭდილებას, რომ ყველა პროგრამა ერთდროულად მუშაობს. რეალურ დროში ოპერაციული სისტემა არის მრავალფუნქციური ოპერაციული სისტემის განსაკუთრებული შემთხვევა, რომელიც ოპტიმიზირებულია კონტროლის პროცესების განსახორციელებლად. ის სწრაფად რეაგირებს გარე მოვლენებზე და გაძლევთ საშუალებას მოახდინოთ რამდენიმე პროცესორის მუშაობის სიმულაცია, რომელთაგან თითოეული აკონტროლებს ერთ მოწყობილობას. ამიტომ, ერთი პროცესორის გამოყენებით რთული სისტემის გასაკონტროლებლად, მიზანშეწონილია გამოიყენოთ RTOS, რომელსაც შეუძლია კოორდინაცია გაუწიოს სხვადასხვა ამოცანების შესრულებას. RTOS-ის მაგალითია ლიფტის მართვის სისტემა.

RTOS-ის მუშაობის პრინციპი

მოთხოვნის მიღებისას მოწმდება შეყვანილი მონაცემები პრობლემის გადასაჭრელად. თუ ისინი იმყოფებიან, დავალების შესრულება იწყება. თუ საჭირო შეყვანის მონაცემები აკლია, RTOS გადადის შემდეგ დავალებაზე (თუ არსებობს მისი შესრულების მოთხოვნა). შეფერხებები გამოიყენება შეყვანის მონაცემების მისაღებად და შესაბამისი დავალების გასაშვებად. ამოცანა, როგორც წესი, იწყება მისი მოლოდინში დასრულებული დავალების რიგიდან შესასრულებელ დავალებების რიგში გადატანით.

თითოეულ დავალებას აქვს შეტყობინებების შეყვანის რიგი, რომლის დამუშავება მას შეუძლია მხოლოდ გამოყოფილი დროის ინტერვალის დროს ან შეფერხების მოთხოვნის მიღებისას. თუ პასუხს ძალიან დიდი დრო სჭირდება, დავალება კვლავ განთავსდება შესრულების რიგში და კონტროლი გადადის შემდეგ დავალებაზე.

სისტემის რესურსები (დისკის დისკები, ტაიმერები, I/O მოწყობილობები და ა.შ.) ჩვეულებრივ ხელმისაწვდომია მხოლოდ გარკვეული ამოცანებისთვის. ეს საშუალებას გაძლევთ მოაწყოთ რესურსების მოთხოვნის რიგი ისე, რომ თავიდან აიცილოთ ერთ რესურსზე ერთდროული წვდომა რამდენიმე დავალების მიერ.

მოთხოვნები RTOS-ისთვის.

თანამედროვე PB OS უნდა აკმაყოფილებდეს შემდეგ მოთხოვნებს:

● მოკლე რეაგირების დრო (შედეგების მიღება);

● მოქნილი პრიორიტეტის მექანიზმით მრავალფუნქციური რეჟიმის განხორციელება;

● მეხსიერების მცირე რაოდენობა (საკმარისია აპლიკაციის სისტემის რეზიდენტ მეხსიერებაში განსათავსებლად);

● სერვისის ფუნქციებისა და დამხმარე ინსტრუმენტების ხელმისაწვდომობა აპლიკაციის პროგრამების შემუშავებისთვის და რიგი სხვა.

ამჟამად, RTOS გამოიყენება მიკროკონტროლერული სისტემების შესაქმნელად, რომლებსაც აქვთ სხვადასხვა მახასიათებლები და გამოცდილია გამოყენების ისეთ სფეროებში, როგორიცაა წარმოების ავტომატიზაციის სისტემები, ინსტრუმენტული სისტემები, სატელეკომუნიკაციო აღჭურვილობა, კოსმოსური და სამხედრო აღჭურვილობა, ტრანსპორტი, უსაფრთხოების სისტემები და ა.

RTOS-ის ტიპები

არსებობს ორი ტიპის RTOS:

მძიმე რეალურ დროში სისტემები,რომლებიც იკავებენ მეხსიერების მცირე რაოდენობას და აქვთ მინიმალური რეაგირების დრო, მაგრამ აქვთ ძალიან შეზღუდული სერვისის ინსტრუმენტები. ისინი დანერგილია მოდულურ საფუძველზე, რაც საშუალებას გაძლევთ გამოიყენოთ მხოლოდ ის ინსტრუმენტები, რომლებიც საჭიროა მოცემულ აპლიკაციაში. შედეგი არის მეხსიერების მოთხოვნების მნიშვნელოვანი შემცირება და რეაგირების დრო მოცემული განაცხადისთვის;

● რეალურ დროში რბილ სისტემებს, რომლებიც საჭიროებენ მეტ მეხსიერებას, აქვთ უფრო გრძელი რეაგირების დრო, მაგრამ აკმაყოფილებენ მომხმარებლის მოთხოვნების ფართო სპექტრს დავალების მომსახურების რეჟიმისა და მოწოდებული სერვისის დონის თვალსაზრისით. რეალურ დროში რბილი სისტემების ინტერფეისის ხელსაწყოები იძლევა მაღალეფექტური გამართვის ან ინტეგრირებული განვითარების გარემოს გამოყენებას.

რბილი რეალურ დროში სისტემა.

მოდით განვიხილოთ ამ ტიპის სისტემა Microwave Systems-ის OS-9 სისტემის მაგალითის გამოყენებით. OS-9 იყენებს IBM კომპიუტერებს, რომლებიც მუშაობენ Windows, ან Sun, HP, IBM RS/6000 სამუშაო სადგურებზე UNIX-ის ტიპის ოპერაციული სისტემებით, როგორც ხელსაწყო კომპიუტერი. მახასიათებლები OS-9:

● მოდულარულობა, რომელიც იძლევა სამიზნე RTOS-ის კონფიგურაციის შესაძლებლობას გადასაჭრელი ამოცანების კლასის შესაბამისად. გამოუყენებელი მოდულების აღმოფხვრით, შეგიძლიათ შეამციროთ მეხსიერების კვალი და შეამციროთ სისტემის ღირებულება;

● სტრუქტურის მოქნილობა, სისტემის რეკონფიგურაციის უზრუნველყოფა და მისი ფუნქციონირების გაფართოება. ფუნქციური კომპონენტები OS–9:

● რეალურ დროში ბირთვი (OS –9 kernel);

● ზოგადი შეყვანის/გამოსვლის საშუალებები (I/O man);

● ფაილების მენეჯერები;

● პროგრამული უზრუნველყოფის განვითარების ინსტრუმენტები.

OS -9 ფუნქციონალური კომპონენტები შექმნილია როგორც თვითმყოფადი მოდულები, რომელთა ამოღება ან დამატება შესაძლებელია მარტივი ბრძანებების გამოყენებით, რომლებიც არ საჭიროებს ხელახლა კომპილაციას ან ხელახლა დაკავშირებას. მოდულების კომბინაციით შეგიძლიათ შექმნათ სამიზნე ოპერაციული სისტემები სხვადასხვა ფუნქციონირებით.

მოდით შევხედოთ ზემოთ ჩამოთვლილ ფუნქციურ კომპონენტებს.

რეალურ დროში ბირთვი

სისტემა შეიცავს ორი ტიპის ბირთვს:

● ატომური ბირთვი, რომელიც ახორციელებს მომსახურების ფუნქციების მინიმალურ რაოდენობას (დისტანციური ჩატვირთვა, ლოკალურ ქსელთან კომუნიკაცია, სლავური მიკროკონტროლერების კონტროლი). ბირთვი გამოიყენება სხვადასხვა აღჭურვილობაში ჩაშენებულ სისტემებში, აქვს მცირე მოცულობა (24 KB) და უზრუნველყოფს რეაგირების მინიმალურ დროს (3 μs საათის სიხშირეზე 25 MHz);

● სტანდარტული ბირთვი, რომელიც უზრუნველყოფს სერვისის ფუნქციების ფართო სპექტრს და აპლიკაციის პროგრამის შემუშავებას, რომლის განხორციელებისთვის საჭიროა მეხსიერების უფრო დიდი რაოდენობა (512K ბაიტი ROM და 38K ბაიტი ოპერატიული მეხსიერება). ბირთვის ფუნქციური მოდულების შეცვლით შესაძლებელია სხვადასხვა სირთულის და დანიშნულების სისტემების დანერგვა: კონტროლერებიდან ჩაშენებული აპარატურაში რეზიდენტი პროგრამული უზრუნველყოფით და მარტივი შეყვანის/გამოსვლის საშუალებებით დამთავრებული რთული ფუნქციონალური სამუშაო სადგურის კლასის სისტემებამდე გაფართოებული ქსელის მხარდაჭერით და მრავალფეროვნებით. მომსახურების ფუნქციები, მათ შორის მულტიმედია.

OS –9 სისტემა მომხმარებელს აძლევს შესაძლებლობას აირჩიოს ბირთვი სისტემის ფუნქციონალური დანიშნულებიდან გამომდინარე. ზოგადი შეყვანის/გამოსვლის საშუალებები. OS -9-ის ფიზიკური ინტერფეისი სხვადასხვა გარე მოწყობილობებთან უზრუნველყოფილია დიდი მძღოლების ნაკრები,შექმნილია როგორც Microwave Systems-ის, ასევე აღჭურვილობის მრავალი შემქმნელის მიერ, რომლებიც იყენებენ ამ ოპერაციულ სისტემას კონკრეტული აპლიკაციებისთვის. ფაილის მენეჯერები.ეს მოიცავს მოდულებს, რომლებიც აკონტროლებენ მონაცემთა ლოგიკურ ნაკადებს. თითოეულ მოდულს აქვს კონკრეტული ფუნქციური დანიშნულება და სპეციფიკაცია. ფაილის მენეჯერები შეიძლება დაიყოს სამ ჯგუფად:

● სტანდარტული მენეჯერები, რომლებიც შექმნილია გარე მოწყობილობებთან გაცვლის ისეთი ძირითადი ფუნქციების შესასრულებლად, როგორიცაა შემომავალი ბრძანებების რიგის ორგანიზება, ბაიტის და ბლოკის სერიული გაცვლის მართვა და მეხსიერების პირდაპირი წვდომით გაცვლა;

● ქსელისა და კომუნიკაციის მენეჯერები, რომლებიც უზრუნველყოფენ OS –9-ის მუშაობას სხვადასხვა ქსელებით და მონაცემთა გაცვლას საკომუნიკაციო არხებით ყველაზე გავრცელებული საკომუნიკაციო პროტოკოლის სტანდარტებით;

● გრაფიკული ინტერფეისი და მულტიმედიური აპლიკაციების მენეჯერები. პროგრამის განვითარების ინსტრუმენტები. OS-9 მოიცავს პროგრამულ პაკეტს (BSP) განვითარების დაფების მხარდასაჭერად, რაც საშუალებას აძლევს OS-9-ს იმუშაოს რამდენიმე SBC-თან (Single Board Computer). BSP და OS-9-ის კომბინირებული გამოყენება საშუალებას გაძლევთ დააკონფიგურიროთ სამიზნე სისტემა კონკრეტული აპლიკაციისთვის.

OS-9 სისტემა შეიცავს პროგრამირების მხარდაჭერის ინსტრუმენტებს: Ultra C/C++ შემდგენელებს, EM ACS ტექსტის რედაქტორს, სამი ტიპის (მათ შორის სიმბოლურ) გამართულს, პროგრამული პროდუქტების კონტროლისა და შეკრების ორგანიზების უტილიტას. გარდა ამისა, არსებობს (OS-9 თავსებადი) პროგრამირების მხარდაჭერის ხელსაწყოების დიდი ნაკრები, რომლებიც შემუშავებულია სხვა კომპანიების მიერ. ფასტრარომ. FasTrak გარემოს გააჩნია OS-9 და მომხმარებელს აძლევს პროგრამირებისა და გამართვის ინსტრუმენტების ყველაზე სრულ კომპლექტს. FasTrak-ის ზოგიერთი პროგრამა დაინსტალირებულია ხელსაწყოების კომპიუტერზე, ნაწილი კი დაინსტალირებულია მომხმარებლის სამიზნე სისტემაზე. FasTrak გარემო აერთიანებს ყველა ხელსაწყოს, რომელიც საჭიროა სამიზნე სისტემების დიზაინის/გამართვის მხარდასაჭერად. IBM კომპიუტერზე მუშაობისთვის FasTrak გარემოს ვერსია შეიცავს:

● ტექსტური რედაქტორი კლავიატურის ტრანსკოდირების ხელსაწყოებით, რომელიც საშუალებას აძლევს რედაქტირებას მოსახერხებელი ფორმატში;

● Ultra C/C++ შემდგენელები;

● გამართვები, რომლებიც უზრუნველყოფენ გამართვის ორ რეჟიმს: საბაჟო- აპლიკაციის პროგრამების შექმნა და სისტემური- შეფერხებების, სისტემური ზარების და წვდომის მომსახურებისთვის ბირთვირეალური დრო;

● კომპანიის ლოგიკურ ანალიზატორებთან ინტერფეისის საშუალებები.

FasTrak-ის გარემოს აქვს ფართო ფუნქციონირება, რაც მას ეფექტურ ინსტრუმენტად აქცევს სხვადასხვა მიკროკონტროლერ სისტემებისთვის პროგრამული უზრუნველყოფის შესაქმნელად.

Microware Systems აწვდის სისტემურ პაკეტებს, რომლებიც ორიენტირებულია აპლიკაციის სხვადასხვა სფეროზე:

● Wireless OS –9 - უსადენო საკომუნიკაციო მოწყობილობების განვითარებისთვის: მობილური ტელეფონები, პეიჯერები, პორტატული ციფრული ასისტენტები (PDA);

● Internet OS –9 - ინტერნეტთან წვდომის მქონე მოწყობილობების დასამუშავებლად;

● ციფრული აუდიო/ვიდეო ინტერაქტიული დეკოდერი (DAVID) OS –9 - განაწილებული ციფრული ინტერაქტიული სატელევიზიო სისტემების განვითარებისთვის.

მძიმე რეალურ დროში სისტემა

მოდით შევხედოთ ამ ტიპის სისტემის მახასიათებლებს WindRiver Systems-ის VxWorks სისტემის მაგალითის გამოყენებით, რომელიც შექმნილია მრავალი მწარმოებლის მიკროპროცესორების ოჯახებთან მუშაობისთვის. VxWorks სისტემა დაყენებულია სამიზნე სისტემაზე, რომელიც გამართულია და მუშაობს Tornado ინტეგრირებული განვითარების გარემოსთან ერთად, რომელიც მუშაობს ხელსაწყოს კომპიუტერზე. IBM კომპიუტერები, რომლებიც მუშაობენ Windows, ან SUN, HP და ა.შ. სამუშაო სადგურებზე, გამოიყენება როგორც ინსტრუმენტული კომპიუტერი. სისტემის მოკლე აღწერაVxWorks.სისტემის იერარქიული ორგანიზაციის ქვედა დონეა რეალურ დროში მიკროკერნელი, რომელიც ასრულებს ამოცანების დაგეგმვისა და მათი კომუნიკაციისა და სინქრონიზაციის ძირითად ფუნქციებს. ბირთვის მოდულების მინიმალურ კომპლექტს სჭირდება 20-40K ბაიტი მეხსიერება. ყველა სხვა ფუნქცია - მეხსიერების მართვა, შეყვანა/გამომავალი, ქსელის გაცვლა და სხვა - განხორციელებულია დამატებითი მოდულებით. გრაფიკული აპლიკაციების მხარდასაჭერად VxWorks გთავაზობთ VX-Windows გრაფიკულ ინტერფეისს.

თუ სამიზნე სისტემის მეხსიერება შეზღუდულია, შეგიძლიათ გამოიყენოთ RTGL გრაფიკული ბიბლიოთეკა, რომელიც შეიცავს ძირითად გრაფიკულ პრიმიტივებს, შრიფტებისა და ფერების კომპლექტს, ტიპიური შეყვანის მოწყობილობების დრაივერებს და გრაფიკულ კონტროლერებს. VxWorks ასევე მოიცავს სხვადასხვა ინსტრუმენტებს სხვადასხვა ქსელის პროტოკოლების მხარდასაჭერად. კვალი მოცემულიმოვლენები და მათი დაგროვება ბუფერულ მეხსიერებაში შემდგომი ანალიზისთვის ხორციელდება რეალურ დროში სპეციალური გამართვის ხელსაწყოებით და ტრასირება. სისტემურიმოვლენები - WindView დინამიური ანალიზატორი. WindView ანალიზატორი მუშაობს ლოგიკური ანალიზატორის მსგავსად, ეკრანზე აჩვენებს დავალების გადამრთველების დროის დიაგრამებს, შეტყობინებების რიგში ჩანაწერებს და სხვა პროცესებს. სტეტოსკოპის მონაცემთა მონიტორი საშუალებას გაძლევთ გაანალიზოთ მომხმარებლის და სისტემის ცვლადების დინამიური ცვლილებები, პროცედურების პროფილების ჩათვლით. VxWorks მოიცავს:

● პროგრამული პაკეტი განვითარების დაფების მხარდასაჭერად;

● VxSim სიმულატორი, რომელიც საშუალებას გაძლევთ სიმულაცია მოახდინოთ VxWorks-ის მრავალფუნქციური გარემოს და ინტერფეისის სამიზნე სისტემასთან ინსტრუმენტულ კომპიუტერზე, ასევე განავითაროთ და გამართოთ პროგრამული უზრუნველყოფა სამიზნე სისტემის დაკავშირების გარეშე.

სამიზნე სისტემების ყოვლისმომცველი გამართვისთვის, VxWorks უზრუნველყოფს ინტერფეისს მიკროსქემის ემულატორებთან და ROM ემულატორებთან. ინტეგრირებული განვითარების გარემოტორნადო . Tornado მოიცავს VxWorks 5.3 სისტემას, რომელიც მოიცავს რეალურ დროში ბირთვს და სისტემის ბიბლიოთეკებს, პროგრამირების ხელსაწყოებს, მაღალი დონის გამართვას და სხვა სისტემურ ინსტრუმენტებს. Tornado გარემოს დამატებითი ინსტრუმენტები უზრუნველყოფს გამართვის პროცესის კონტროლს, სამიზნე სისტემის მდგომარეობის ვიზუალიზაციას და სხვა სერვისის ფუნქციებს. Tomado-ს გარემოს ღია არქიტექტურა საშუალებას აძლევს მომხმარებელს დააკავშიროს საკუთარი სპეციალიზებული ხელსაწყოები და გააფართოოს სტანდარტული ხელსაწყოების შესაძლებლობები.

VxWorks რეალურ დროში ოპერაციული სისტემა, Tornado-ს ინტეგრირებულ გარემოსთან ერთად, არის მძლავრი ინსტრუმენტი სამიზნე სისტემების დასანერგად, რომლებიც მუშაობენ გამოყენებული მეხსიერების ოდენობისა და გარე მოვლენებზე რეაგირების დროის მკაცრი შეზღუდვით.

ავტომატური ან ავტომატიზირებული კომპლექსების კონტროლი, რომლებიც დიდ მოთხოვნებს აყენებენ დავალების შესრულების დროს, ხორციელდება რეალურ დროში ოპერაციული სისტემებით. ისინი უზრუნველყოფენ გარანტირებულ პასუხს გარე მოვლენებზე და მინიმალურ შეფერხებებზე.

რეალურ დროში ოპერაციული სისტემა, OS RV(ინგლისური Real-Time Operating System) - ტიპი, როგორც წესი, სპეციალური მიზნებისათვის. ამ ტერმინის სხვადასხვა განმარტება არსებობს, რომლებიც ზოგჯერ ეწინააღმდეგება ერთმანეთს:

  • ოპერაციული სისტემა, რომელშიც ნებისმიერი პროგრამის წარმატება დამოკიდებულია არა მხოლოდ მის ლოგიკურ სისწორეზე, არამედ ამ შედეგის მისაღებად საჭირო დროზე. თუ სისტემა ვერ აკმაყოფილებს დროის შეზღუდვებს, წარუმატებლობა უნდა დაფიქსირდეს.
  • POSIX 1003.1 სტანდარტი განსაზღვრავს: „ოპერაციულ სისტემებში რეალურ დროში არის ოპერაციული სისტემის შესაძლებლობა, უზრუნველყოს მომსახურების საჭირო დონე გარკვეული პერიოდის განმავლობაში“.
  • ოპერაციული სისტემა, რომელიც პასუხობს პროგნოზირებად დროს გარე მოვლენების არაპროგნოზირებად მოვლენებზე
  • მუდმივი მზადყოფნის ინტერაქტიული სისტემები. ისინი კლასიფიცირდება RT OS კატეგორიაში, მარკეტინგული მოსაზრებებიდან გამომდინარე, და თუ ინტერაქტიულ პროგრამას ეწოდება „რეალურ დროში“, ეს მხოლოდ იმას ნიშნავს, რომ მომხმარებლისგან მოთხოვნები დამუშავდება შეფერხებით, რაც შეუმჩნეველია ადამიანისთვის.
  • ზოგჯერ რეალურ დროში სისტემის კონცეფცია იდენტიფიცირებულია "სწრაფ სისტემასთან", მაგრამ ეს ყოველთვის არ არის სწორი, რადგან მნიშვნელოვანია არა RT OS-ის პასუხის დაყოვნების დრო, არამედ ის, რომ ეს დრო საკმარისია განაცხადისთვის კითხვა და რომ გარანტირებულია.
  • ბევრი სპეციალიზებული სფერო წარმოგიდგენთ „რეალური დროის“ საკუთარ კონცეფციებს. მაგალითად, ციფრული სიგნალის დამუშავების პროცესს ეწოდება რეალურ დროში, თუ ანალიზი და/ან მონაცემთა გენერაცია შეიძლება განხორციელდეს იმავე დროს, როგორც იგივე მონაცემების ანალიზი/გენერაცია ციფრული სიგნალის დამუშავების გარეშე. მაგალითად, თუ აუდიო მონაცემების დამუშავებას სჭირდება 2.01 წამი აუდიოს 2.00 წამის ანალიზს, მაშინ ეს არ არის რეალურ დროში პროცესი. თუ ამას 1,99 წამი სჭირდება, მაშინ ეს არის რეალურ დროში პროცესი.

რეალურ დროში სისტემები ხასიათდება შემდეგი მახასიათებლებით:

  • გარანტირებული რეაგირების დრო გარე მოვლენებზე (მაგალითად, ტექნიკის შეფერხებები);
  • მკაცრი პროცესის დაგეგმვის ქვესისტემა (მაღალი პრიორიტეტული ამოცანები არ უნდა ჩაანაცვლოს დაბალი პრიორიტეტით, ზოგიერთი გამონაკლისის გარდა);
  • გაზრდილი მოთხოვნები რეაქციის დროს გარე მოვლენებზე ან რეაქტიულობაზე (შეფერხების დამმუშავებლის გამოძახების შეფერხება არ აღემატება ათეულ მიკროწამს, დაყოვნება ამოცანების გადართვისას არ არის ასობით მიკროწამზე მეტი)

დავალების კლასიკური მაგალითი, სადაც საჭიროა RT OS, არის რობოტის კონტროლი, რომელიც მონაწილეობს კონვეიერის სარტყელიდან. ნაწილი მოძრაობს და რობოტს აქვს მხოლოდ მცირე დრო, როდესაც მას შეუძლია მისი აყვანა. თუ ის დააგვიანა, ნაწილი აღარ იქნება კონვეიერის სწორ მონაკვეთზე და, შესაბამისად, სამუშაო არ შესრულდება, მიუხედავად იმისა, რომ რობოტი სწორ ადგილზეა. თუ ის უფრო ადრე განლაგდება, ნაწილს არ ექნება დრო, რომ ჩამოვიდეს და გზას გადაუკეტავს.

RT OS- ის ტიპები

რეალურ დროში პროგრამების დინამიური თვისებები ჩვეულებრივ ხასიათდება სამი განმარტებით: პროგრამები "მძიმე" (მძიმე), "რბილი" (რბილი) და ინტერაქტიული ("პირობითი")რეალური დრო.

მძიმე რეალურ დროში. უზრუნველყოფს სისტემის გარანტირებულ პასუხს კონკრეტულ მოვლენაზე, მაგალითად, ტექნიკის შეფერხებაზე, საკონტროლო ბრძანების გაცემაზე და ა.შ. პასუხის დროის აბსოლუტურ მნიშვნელობას დიდი მნიშვნელობა არ აქვს. ასე რომ, თუ პროგრამამ უნდა შეასრულოს გარკვეული ბრძანება 1 მილიწამში, მაგრამ ის ამ ამოცანას უმკლავდება მხოლოდ 95% შემთხვევაში, ხოლო 5% არ აკმაყოფილებს სტანდარტს, ასეთი სისტემა არ შეიძლება დახასიათდეს, როგორც მუშაობს. მძიმე რეალურ დროში. თუ ბრძანება უნდა დამუშავდეს ერთ საათში, რაც ხდება 100% შემთხვევაში, არის მკაცრი რეალური დრო.

უმეტეს რუსულენოვან ლიტერატურაში ასეთ სისტემებს ე.წ სისტემები დეტერმინისტული დროით. პრაქტიკულ გამოყენებაში რეაქციის დრო მინიმალური უნდა იყოს.

რბილი რეალურ დროში. ამ შემთხვევაში, სისტემის პასუხის მოსალოდნელი დრო უფრო საორიენტაციო მნიშვნელობაა, ვიდრე ინსტრუქციული მნიშვნელობა. რა თქმა უნდა, ვარაუდობენ, რომ უმეტეს შემთხვევაში (80 - 90 პროცენტი) პასუხი დაეცემა მითითებულ საზღვრებს. თუმცა, სხვა ვარიანტებმა - მათ შორის სისტემის პასუხის სრული ნაკლებობამ - არ უნდა გამოიწვიოს დამღუპველი შედეგები. ჩვეულებრივ ითვლება, რომ თუ დროის სტანდარტს გადააჭარბებს სიდიდის ერთი რიგით, მაშინ ის მაინც ასატანია.

ინტერაქტიული რეალურ დროში. ეს უფრო ფსიქოლოგიური მახასიათებელია, ვიდრე ტექნიკური. განსაზღვრავს დროს, რომლის დროსაც ოპერატორს - ადამიანს შეუძლია მშვიდად, ნერვიულობის გარეშე დაელოდოს სისტემის რეაგირებას მისთვის მიცემულ მითითებებზე. მაგალითად, ჩვენ შეგვიძლია მოვიყვანოთ დღეს ძალიან პოპულარული თამაშები "რეალურ დროში სტრატეგიის" კატეგორიიდან (იხილეთ, მაგალითად, Quasar, რომელიც დაფუძნებულია Warhammer-ზე).

რეალურ დროში სისტემებში აუცილებელია გარკვეული ვადის შემოღება (ინგლისურ ლიტერატურაში - ბოლო ვადა), რომლის ვადის გასვლამდე აუცილებლად უნდა შესრულდეს დავალება (რბილი რეალურ დროში სისტემებისთვის - სასურველია). ამ ვადას იყენებს დავალების დამგეგმავი, როგორც დავალებისთვის პრიორიტეტის მინიჭებისას, როდესაც ის გაშვებულია, ასევე, შესასრულებლად დავალების არჩევისას.

ხშირად, SRV უპირობოდ ესმით ჩაშენებული ოპერაციული სისტემებისინამდვილეში, არსებობს განსხვავება რეალურ დროში სისტემებსა და ჩაშენებულ სისტემებს შორის. ჩაშენებულ სისტემას ყოველთვის არ მოეთხოვება პროგნოზირებადი ქცევა, ამ შემთხვევაში ის არ არის რეალურ დროში სისტემა. თუმცა, შესაძლო ჩაშენებულ სისტემებზე სწრაფი გადახედვაც კი მიგვანიშნებს, რომ ჩაშენებული სისტემების უმეტესობა მოითხოვს პროგნოზირებად ქცევას სულ მცირე გარკვეული ფუნქციონირებისთვის და, შესაბამისად, ეს სისტემები შეიძლება კლასიფიცირდეს რეალურ დროში სისტემებად.

ძირითადი მოთხოვნები RT OS-ისთვის

მარტინ ტიმერმანმა (ჩაშენებული სისტემების დეველოპერის Dedicated Systems Experts-ის დირექტორმა) ჩამოაყალიბა შემდეგი აუცილებელი მოთხოვნები RT OS-ისთვის:

  • ოპერაციული სისტემა უნდა იყოს მრავალფუნქციური და პრევენციული,
  • OS-ს უნდა ჰქონდეს ძაფების პრიორიტეტის კონცეფცია,
  • OS-მ უნდა უზრუნველყოს პროგნოზირებადი სინქრონიზაციის მექანიზმები,
  • OS-მ უნდა უზრუნველყოს პრიორიტეტების მემკვიდრეობის მექანიზმი,
  • ოპერაციული სისტემის ქცევა უნდა იყოს ცნობილი და პროგნოზირებადი (შეფერხების დამუშავების შეფერხება, დავალების გადართვის შეფერხება, მძღოლის შეფერხება და ა.შ.); ეს ნიშნავს, რომ სისტემის დატვირთვის ყველა სცენარში უნდა განისაზღვროს მაქსიმალური რეაგირების დრო.

RT OS არქიტექტურის მახასიათებლები

გასული 25-30 წლის განმავლობაში ოპერაციული სისტემების სტრუქტურა მონოლითურიდან მრავალშრიანი OS სტრუქტურამდე და შემდეგ კლიენტ-სერვერის არქიტექტურამდე გადაიქცა. ეს გადაწყვეტილებები, ამა თუ იმ ხარისხით, გამოიყენება რეალურ დროში ოპერაციული სისტემების შემუშავებაში.

მონოლითური არქიტექტურაწარმოადგენს სისტემას, რომელიც შედგება ურთიერთმოქმედი მოდულების ნაკრებისგან. აპლიკაციები წვდებიან სისტემას API მოდულების მეშვეობით. ერთ მოდულში ცვლილებები გავლენას ახდენს სხვა მოდულებზე. რაც უფრო მეტი მოდულია, მით უფრო რთულია ისინი ერთმანეთთან დაკავშირებული, მით უფრო ნაკლებად პროგნოზირებადია ასეთი სისტემის ქცევა ექსპლუატაციის დროს. გარდა ამისა, სირთულეები წარმოიქმნება ამ ტიპის OS-ის გამოყენებისას განაწილებულ მრავალპროცესორულ სისტემაში.

ნახ.1. RT OS-ის მონოლითური არქიტექტურა

ფენიანი არქიტექტურააღწერს სისტემას, რომელიც შედგება რამდენიმე ფუნქციური დონისგან. აპლიკაციას შეუძლია წვდომა აპარატურულ რესურსებზე როგორც ბირთვის სისტემის ზარების და სისტემის სერვისების, ასევე API ფენების მეშვეობით. სინამდვილეში, ზედა ფენების გვერდის ავლით ქვედა ფენებზე წვდომის შესაძლებლობა სემანტიკურად არასწორია, მაგრამ რეალურ დროში სისტემებისთვის ასეთი ორგანიზაცია იძლევა სისტემის პროგნოზირებადობის გაზრდას და რეაგირების დროის შემცირებას. მრავალშრიანი არქიტექტურის მინუსი არის ის, რომ ერთ ფენაში ცვლილებები გავლენას ახდენს მეზობელ ფენებზე. მრავალშრიანი არქიტექტურის თანდაყოლილი კიდევ ერთი მინუსი არის მრავალფუნქციური დავალებების ნაკლებობა. თუმცა, არა ყოველთვის და არა ყველა რეალურ დროში სისტემა მოითხოვს მრავალამოცანის მხარდაჭერას. მაგალითად, ძნელია დაასაბუთოს მრავალფუნქციური რეჟიმის საჭიროება ინდუსტრიული რობოტის ჩაშენებული ოპერაციული სისტემისთვის, რომელიც აწვდის ნაწილებს კონვეიერზე.

ნახ.2. RT OS-ის მრავალშრიანი არქიტექტურა

კლიენტ-სერვერის არქიტექტურა OS ეფუძნება ბირთვის მიერ შესრულებული ფუნქციების რაოდენობის შემცირებას (უფრო ზუსტად, მიკროკერნელი) ასეთი სისტემა. მაგალითად, ბირთვის დონეზე, მხოლოდ გრაფიკი, სინქრონიზაციის პრიმიტივები და შეტყობინებების სერვისი სრულდება. ყველა სხვა ფუნქცია გადადის მომხმარებლის დონეზე და დანერგილია სერვერების მეშვეობით. კლიენტის აპლიკაციები წვდებიან და იღებენ მათგან პასუხებს ბირთვის შეტყობინებების სერვისის მეშვეობით შეტყობინებების გაცვლით.

ნახ.3 RT OS-ის კლიენტ-სერვერის არქიტექტურა

კლიენტ-სერვერის არქიტექტურა საშუალებას იძლევა შექმნას მასშტაბური ოპერაციული სისტემები და ამარტივებს განაწილებას მრავალპროცესორულ სისტემაში. სისტემის მუშაობისას ერთი მოდულის შეცვლა არ იწვევს „თოვლის ბურთის“ ეფექტს; გარდა ამისა, მოდულის უკმარისობა ყოველთვის არ იწვევს მთლიანად სისტემის უკმარისობას. ახლა თქვენ შეგიძლიათ დინამიურად ჩატვირთოთ და გადმოტვირთოთ მოდულები. ამ მოდელის მთავარი პრობლემა მეხსიერების დაცვაა, რადგან სერვერის პროცესები დაცული უნდა იყოს. ყოველ ჯერზე, როდესაც ხდება სერვისის მოთხოვნა, სისტემა უნდა გადავიდეს აპლიკაციის კონტექსტიდან სერვერის კონტექსტზე. მეხსიერების დაცვის მხარდაჭერით, ერთი პროცესიდან მეორეზე გადართვის დრო იზრდება.

საკონტროლო კითხვები

  1. განსაზღვრეთ რეალურ დროში ოპერაციული სისტემა
  2. Რა მოხდა ბოლო ვადა?
  3. Რა არის განსხვავება "რთული"რეალურ დროში "რბილი"
  4. ჩამოაყალიბეთ RT OS-ის ძირითადი მოთხოვნები
  5. მიუთითეთ ძირითადი განსხვავებები RT OS-ის მოთხოვნებში უნივერსალური OS-სგან
  6. აღწერეთ მოდულური არქიტექტურა
  7. აღწერეთ ფენიანი არქიტექტურა
  8. აღწერეთ კლიენტ-სერვერის არქიტექტურა

ამ გვერდის მუდმივი მისამართი:

ნებისმიერი აპარატურის და პროგრამული კომპლექსის საფუძველი, მათ შორის რეალურ დროში მოქმედი, არის ოპერაციული სისტემა (OS). ოპერაციული სისტემა არის პროგრამების ერთობლიობა, რომელიც უზრუნველყოფს აპარატურულ-პროგრამული კომპლექსის (კომპიუტერული სისტემის) რესურსების მართვას და პროცესებს, რომლებიც იყენებენ ამ რესურსებს გამოთვლებში. რესურსი ამ კონტექსტში არის ნებისმიერი ლოგიკური ან ფიზიკური (და მთლიანობაში) კომპონენტი გამოთვლითი სისტემის ან ტექნიკისა და პროგრამული უზრუნველყოფის კომპლექსისა და მისი შესაძლებლობების შესახებ.

ძირითადი რესურსებია პროცესორი (დამუშავების დრო), ოპერატიული მეხსიერება და პერიფერიული მოწყობილობები.

რესურსების მართვა შემდეგი ამოცანების შესრულებაზე მოდის: რესურსებზე წვდომის გამარტივება, პროცესებს შორის მათი განაწილება.

პირველი პრობლემის გადაჭრა საშუალებას გაძლევთ „დამალოთ“ გამოთვლითი სისტემის აპარატურის მახასიათებლები და ამით მიაწოდოთ მომხმარებელს ან პროგრამისტს ვირტუალური მანქანა მნიშვნელოვნად გამარტივებული მენეჯმენტით. ამრიგად, OS მხარს უჭერს შემდეგ ინტერფეისებს: მომხმარებელი (ბრძანების ენა სისტემის ფუნქციონირების კონტროლისთვის და სერვისების ნაკრები); პროგრამული უზრუნველყოფა (სერვისების ერთობლიობა, რომელიც ათავისუფლებს პროგრამისტს რუტინული ოპერაციების კოდირებისგან) რესურსების განაწილების ფუნქცია ერთ-ერთი ყველაზე მნიშვნელოვანი ამოცანაა, რომელსაც აგვარებს ოპერაციული სისტემა, თუმცა ის არ არის თანდაყოლილი ყველა ოპერაციული სისტემისთვის, არამედ მხოლოდ მათში, რომლებიც უზრუნველყოფენ ერთდროულ მუშაობას. რამდენიმე პროგრამის (პროცესის) შესრულება.

პროცესი არის პროგრამით ან მისი ლოგიკურად სრული ნაწილის მიერ დადგენილი მოქმედებების თანმიმდევრობა, ასევე გამოთვლებში გამოყენებული მონაცემები. პროცესი არის სამუშაოს მინიმალური ერთეული, რომლისთვისაც გამოიყოფა რესურსები.

ამჟამად, არსებობს ოპერაციული სისტემების ფართო არჩევანი, რომლებიც კლასიფიცირდება შემდეგი კრიტერიუმების მიხედვით:

o მომხმარებელთა რაოდენობა, რომელსაც სისტემა ერთდროულად ემსახურება;

o პროცესების რაოდენობა, რომლებიც შეიძლება ერთდროულად აწარმოონ OS კონტროლის ქვეშ;

o სისტემაში მომხმარებლის წვდომის ტიპი;

o ტიპის აპარატურა და პროგრამული კომპლექსი.

პირველი ნიშნის მიხედვით, განასხვავებენ ერთ და მრავალ მომხმარებლის ოპერაციულ სისტემებს.

მეორე ფუნქცია ყოფს OS-ს ერთ და მრავალ დავალებად.

მესამე მახასიათებლის შესაბამისად, ოპერაციული სისტემები იყოფა:

o სისტემები სერიული დამუშავებით. ამ შემთხვევაში შესასრულებელი პროგრამებიდან ყალიბდება პაკეტი და სისტემაში წარდგენილია დასამუშავებლად. ამ შემთხვევაში მომხმარებლები უშუალოდ არ ურთიერთობენ OS-თან;

o დროის გაზიარების სისტემები, რომლებიც უზრუნველყოფენ ერთდროულ ინტერაქტიულ წვდომას რამდენიმე მომხმარებლის კომპიუტერულ სისტემაში ტერმინალის საშუალებით. ამ შემთხვევაში, სისტემის რესურსები ნაწილდება თითოეულ მომხმარებელს „თავის მხრივ“, ამა თუ იმ სერვისის დისციპლინის შესაბამისად;

o რეალურ დროში სისტემები, რომლებმაც უნდა უზრუნველყონ გარანტირებული რეაგირების დრო გარე მოვლენებზე (დაწვრილებით იხილეთ ქვემოთ).

მეოთხე ფუნქცია ყოფს ოპერაციულ სისტემას ერთ და მრავალპროცესორად, ქსელად და განაწილებულად. მრავალმომხმარებლისა და მრავალფუნქციური ოპერაციული სისტემებისთვის, ტექნიკური დისციპლინა მნიშვნელოვანი მაჩვენებელია. ამის შესაბამისად, განასხვავებენ მრავალფუნქციური მუშაობის პრევენციულ და კოორდინირებულ რეჟიმებს. პრევენციულ ორგანიზაციაში, მხოლოდ OS არის პასუხისმგებელი პროცესორის დროის ამოცანებისთვის (მაგალითად, თითოეული ამოცანისთვის პროცესორი გამოიყოფა თავის მხრივ და მკაცრად განსაზღვრული პერიოდის განმავლობაში, მაგრამ ასევე შესაძლებელია პრიორიტეტული მომსახურება). შესატყვისი ორგანიზაციის შემთხვევაში, ყოველი დავალება, კონტროლის მიღების შემდეგ, თავად განსაზღვრავს, როდის უნდა "მიცეს" პროცესორი სხვა დავალებაზე. ზოგადად, კოორდინაცია უფრო ეფექტური და საიმედოა, ვიდრე პრევენცია, მაგრამ განმსაზღვრელი ფაქტორი პროგრამების განხორციელებისას არის ის ფაქტი, რომ მოცემულმა პროგრამამ არ უნდა გამოიყენოს ექსკლუზიურად პროცესორის დრო.

რეალურ დროში სისტემა (RTS)- ეს არის სისტემა, რომლის სწორი ფუნქციონირება დამოკიდებულია არა მხოლოდ გამოთვლების ლოგიკურ სისწორეზე, არამედ იმ დროზე, რომლის დროსაც ხდება ეს გამოთვლები.

ასეთ სისტემაში მომხდარი მოვლენებისთვის მნიშვნელოვანია ამ მოვლენების დრო და მათი ლოგიკური სისწორე. სისტემა მუშაობს რეალურ დროში, თუ მისი შესრულება ადეკვატურია ფიზიკური პროცესების სიჩქარეზე მონიტორინგის ან კონტროლის ობიექტებზე (იგულისხმება პროცესები, რომლებიც პირდაპირ კავშირშია კონკრეტული რეალურ დროში სისტემის მიერ შესრულებულ ფუნქციებთან). კონტროლის სისტემამ უნდა შეაგროვოს მონაცემები, დაამუშაოს ისინი მითითებული ალგორითმების მიხედვით და გამოსცეს საკონტროლო მოქმედება დროის იმ მონაკვეთში, რომელიც უზრუნველყოფს დაკისრებული ამოცანების წარმატებით შესრულებას.

1.1 რა არის რეალურ დროში სისტემა

ბოლო დროს სულ უფრო ხშირად ვხვდებით ამოცანებს, რომლებიც საჭიროებენ რთული პროცესების ან აღჭურვილობის მართვას კომპიუტერის გამოყენებით. უფრო მეტიც, ყველა მოვლენა ამ პროცესებში ხდება მაშინ, როდესაც ისინი ხდება. კომპიუტერს შეუძლია შეასრულოს მხოლოდ სასრული რაოდენობის ოპერაციები სასრულ დროში, ამიტომ ჩნდება კითხვა: ექნება თუ არა კომპიუტერს დრო, გამოთვალოს სიტუაცია საჭირო სიჩქარით და გამოსცეს კონკრეტული საკონტროლო მოქმედებები, რომლებიც ადეკვატური იქნება დროის გარკვეულ მომენტში. ჩემი აზრით, მსგავსი პრობლემები წარმოიშვა თანამედროვე წარმოებაში ძალიან მაღალი სიჩქარის გამოყენების გამო. ცხადია, რომ ბუნებაში სიგნალები ვრცელდება სასრული სიჩქარით, მოქმედების სიჩქარეც სასრულია, ამიტომ ფუნდამენტურად შეუძლებელია კომპიუტერიდან მომენტალური მოქმედებების (გარკვეული მოვლენით გამოწვეული) მოლოდინი. ყოველივე ამის შემდეგ, რაც არ უნდა თანამედროვე (წაიკითხეთ: მძლავრი შესრულებაში, ე.ი. ბრძანებების და ოპერაციების დამუშავების მაღალი სიჩქარე) არის კომპიუტერი, მას ფიზიკურად სჭირდება წამის სულ მცირე ნაწილი ბრძანებების მცირე მარტივი ჯგუფის შესასრულებლად და ზოგჯერ ამჯერადაც. ძალიან ბევრია. ამრიგად, სისტემის რეაქციის დრო რომელიმე მოვლენაზე მკაცრად აღემატება ნულს. რეალური ამოცანები იძლევა გარკვეული შეფერხების საშუალებას მოქმედებებში და თუ სისტემას აქვს რეაქციის დრო ნაკლები ამ დასაშვებ შეფერხებაზე, მაშინ სამართლიანია მას რეალურ დროში ვუწოდოთ სისტემა. ვინაიდან ბუნებაში სხვადასხვა პროცესი ხდება სხვადასხვა სიჩქარით, ერთი და იგივე სისტემა შეიძლება მოთავსდეს მოცემულ ჩარჩოში ერთი პროცესისთვის და არ მოერგოს მეორეს. ამრიგად, აზრი აქვს ვისაუბროთ რეალურ დროში სისტემაზე კონკრეტულ ამოცანასთან დაკავშირებით. მაგალითად, ერთი დღის ჰაერის საშუალო ტემპერატურის დამოკიდებულების გამოსათვლელად კვირის დღეს, თითქმის ნებისმიერი კომპიუტერი, თითქმის ნებისმიერი პროგრამული უზრუნველყოფის მქონე, იმუშავებს რეალურ დროში სისტემად. თუ ჩვენ ვაკონტროლებთ თვითმფრინავის დაშვებას, სადაც მილიწამები მნიშვნელოვან როლს თამაშობენ, უფრო მიზანშეწონილი იქნება ტექნიკისა და პროგრამული უზრუნველყოფის ფრთხილად შერჩევა.

გარკვეულ მოვლენაზე რეაგირების განხილული ამოცანის გარდა, არსებობს რეალურ დროში დავალებების სხვა კლასები. ერთ-ერთი ყველაზე ხშირად ნაცნობი არის დინამიური პროცესის მუდმივი მონიტორინგის ან კონტროლის ამოცანა, ე.ი. როდესაც თქვენ გჭირდებათ მუდმივად გაცვალოთ სიგნალები გარე სამყაროსთან. კომპიუტერი არის დისკრეტული სისტემა, ამიტომ აუცილებელია გარკვეული მოქმედებების განხორციელება გარკვეული სასრული პერიოდებით, იმ ვარაუდით, რომ ამ მოკლე დროში გარე სამყარო უცვლელი რჩება. თუ ჩვენს სისტემას შეუძლია ინფორმაციის დამუშავება და საკონტროლო სიგნალების წარმოება საჭირო სიხშირით, მაშინ მას შეიძლება ეწოდოს რეალურ დროში სისტემა. ძნელი არ არის იმის გაგება, რომ ეს პრობლემა შეიძლება ადვილად შემცირდეს წინაზე, მოვლენის სახით შემდეგი დროის ინტერვალის დასაწყისის გამოყენებით. რეაქციის დრო უნდა იყოს ნაკლები, ვიდრე პროცესის შერჩევის დრო. ამრიგად, ადრე აღწერილი ამოცანა არის ყველაზე მნიშვნელოვანი, როდესაც საქმე ეხება რეალურ დროში სისტემებს. უნდა აღინიშნოს, რომ სისტემის არადამაკმაყოფილებელმა მუშაობამ შეყოვნების თვალსაზრისით ზოგიერთ ამოცანში შეიძლება გამოიწვიოს ფატალური შედეგები, ზოგიერთში კი არ მოხდება არანორმალური ან არასასურველი სიტუაციები. მაგალითად: თუ ზემოთ აღწერილი მაგალითიდან ტემპერატურის საზომი სისტემა შემთხვევით დაგვიანებულია დაუშვებელი დროით, მაშინ ეს ნიშნავს, რომ ჩვენ უბრალოდ შევცვალეთ ტემპერატურის კითხვის წერტილების შერჩევა და მაინც მივიღებთ სწორ შედეგს, მაგრამ თუ ავტომატური სამგზავრო თვითმფრინავზე მიახლოება შემთხვევით გადაიდო ერთი წამით უეცარი ქარის დროს, თვითმფრინავმა შესაძლოა ვერ მიაღწიოს ასაფრენ ბილიკს და ათობით ადამიანი დაიღუპოს. ამრიგად, სისტემები უნდა დაიყოს რეალურ დროში მძიმე და რბილ სისტემებად.

გამარჯობა, ჰაბრ!
დღეს მე ვისაუბრებ ისეთ საინტერესოზე, როგორიცაა რეალურ დროში ოპერაციული სისტემა (RTOS). არ ვარ დარწმუნებული, საინტერესო იქნება თუ არა ეს გამოცდილი პროგრამისტებისთვის, მაგრამ ვფიქრობ, ახალბედებს მოეწონებათ.

რა არის RTOS?

თუ გადავხედავთ ვიკიპედიას, დავინახავთ 4-მდე განმარტებას.
მოკლედ, RTOS არის ოპერაციული სისტემა, რომელიც რეაგირებს გარე მოვლენებზე გარკვეული პერიოდის განმავლობაში. აქედან შეგვიძლია გავიგოთ RTOS-ის მთავარი დანიშნულება - მოწყობილობები, რომლებიც საჭიროებენ მოვლენებზე სწრაფ რეაგირებას (თუმცა, არავითარ შემთხვევაში არ აურიოთ RTOS-ის მუშაობა შეფერხებებში).

რატომ გვჭირდება ის?

ამის მიზეზი საკმაოდ ბევრია.
პირველ რიგში, RTOS მხარს უჭერს მრავალ დავალებას, სემაფორის პროცესის პრიორიტეტებს და ბევრ სხვას.
მეორეც, ის ძალიან მსუბუქია და თითქმის არ საჭიროებს რესურსებს.
მესამე, ჩვენ შეგვიძლია მივიღოთ ყოველივე ზემოთქმული თითქმის ნებისმიერ აპარატზე (მაგალითად, FreeRTOS მუშაობს თუნდაც 8-ბიტიან AtMega-ზე).
და მეოთხე: უბრალოდ ითამაშეთ და გაერთეთ.

3 ცნობილი RTOS-ის მიმოხილვა.

გთხოვთ გაითვალისწინოთ: შემდეგი ჩემი პირადი აზრია.
FreeRTOS
დღეს ერთ-ერთი ყველაზე პოპულარული RTOS. პორტირებულია დიდი რაოდენობით აპარატურაზე. Ოფიციალური ვებ - გვერდი.
დადებითი
1) უფასო
2) გადატანილია დიდი რაოდენობით აპარატურაზე
3) ძლიერი ფუნქციონირება
4) არის სხვადასხვა ბიბლიოთეკა: გრაფიკული, ინტერნეტი და სხვა.
5) კარგი დოკუმენტაცია.
მინუსები
1) საკმაოდ რთული პროცესია პორტირების ახალ აპარატურაზე.

დასკვნა: ეს არის ნამდვილად პროფესიონალური RTOS კარგი დოკუმენტაციით. დამწყებთათვის კარგი იქნება თუ მის აპარატურას უკვე აქვს პორტი.

KeilRTX
ბოლო დრომდე, ეს RTOS იყო კომერციული, მაგრამ ახლახან გახდა ღია წყარო. მუშაობს მხოლოდ მკლავის არქიტექტურაზე. Ოფიციალური ვებ - გვერდი.
დადებითი
1) უფასო
2) ადვილად პორტირებული ახალ აპარატურაზე (მკლავის არქიტექტურის ფარგლებში).
3) არის სხვადასხვა ბიბლიოთეკა: გრაფიკული, ინტერნეტი და სხვა.
მინუსები
1) თითქმის შეუძლებელია Keil-ში მასთან მუშაობა
2) ოდნავ შემცირებული ფუნქციონირება
3) მხოლოდ მკლავი არის მხარდაჭერილი.
4) (პირადი გამოცდილებიდან) კარგავს ბევრ RTOS-ს სიჩქარის თვალსაზრისით.
დასკვნა: იდეალურია დამწყები და მცირე პროექტებისთვის.
uc/os
ძლიერი კომერციული RTOS. საიტი .
დადებითი
1) ფუნქციების და ბიბლიოთეკების დიდი რაოდენობა.
2) მხარს უჭერს ბევრ რკინას
მინუსები
1) კომერციული.
2) ძნელი გამოსაყენებელი.

დასკვნა: დამწყებთათვის RTOS-ად დარქმევა საკმაოდ რთულია.

სხვა საინტერესო RTOS

RTLinux RTOS რეგულარულ Linux-ზე დაფუძნებული.
QNX RTOS Unix-ზე დაფუძნებული.

RTOS-ის გამოყენებით განვითარების მახასიათებლები

კარგად, პირველ რიგში, თქვენ უნდა გესმოდეთ შემდეგი: RTOS არ არის Windows. მისი დაყენება შეუძლებელია. ეს სისტემა უბრალოდ აწყობს თქვენს პროგრამას.
RTOS-ით პროგრამების დაწერისას, ფუნქციები ჩვეულებრივი გაგებით არ გამოიყენება. ფუნქციების ნაცვლად გამოიყენება პროცესები (ან ამოცანები), განსხვავება ისაა, რომ პროცესები, ფუნქციებისგან განსხვავებით, არის უსასრულო მარყუჟები და არასოდეს მთავრდება (თუ ვინმე ან თვითონ არ მოკლავს მას - ანუ განტვირთავს მეხსიერებიდან).
თუ რამდენიმე პროცესი ჩართულია, RTOS ცვლის მათ, რაც თავის მხრივ უზრუნველყოფს მანქანის დროსა და რესურსებს. სწორედ აქ ჩნდება პროცესის პრიორიტეტის კონცეფცია - თუ ორ პროცესს ერთდროულად სჭირდება მანქანის დრო, მაშინ RTOS მისცემს მას უფრო მაღალი პრიორიტეტის მქონეს.
RTOS-ს აქვს სპეციალური დაყოვნების ფუნქციები - ისე, რომ დრო არ დაიკარგოს ერთი პროცესის დაგვიანებისას, მეორე შესრულდეს.
ახლა მოდით ვისაუბროთ ისეთ რამეზე, როგორიცაა სემაფორი - ეს არის ის, რაც აკონტროლებს პროცესის წვდომას აპლიკაციის რესურსებზე. თითოეული რესურსისთვის არის მარკერი - როდესაც პროცესს სჭირდება რესურსი, ის იღებს მას და იყენებს ამ რესურსს. თუ ჟეტონი არ არის, მაშინ პროცესს მოუწევს ლოდინი მის დაბრუნებამდე. ნება მომეცით მოგცეთ მაგალითი: სხვადასხვა პროცესი აგზავნის ინფორმაციას ერთი UART-ით. თუ სემაფორი არ არსებობდა, ისინი რიგრიგობით აგზავნიდნენ ბაიტებს და იქნებოდა დაბნეულობა. ასე რომ, პირველმა პროცესმა აიღო ჟეტონი UART-ზე, გაუგზავნა შეტყობინება და გადასცა მეორეს (და ასე შემდეგ უსასრულოდ).

დამატებითი RTOS ბიბლიოთეკები.

RTOS ხშირად გვთავაზობს სხვადასხვა ბიბლიოთეკებს სამუშაოდ, მაგალითად, გრაფიკასთან, ინტერნეტთან და ა.შ. ისინი მართლაც მოსახერხებელია და არ უნდა მოგერიდოთ მათი გამოყენება. ამასთან, გახსოვდეთ, რომ RTOS-ის გარეშე, რომელზეც ისინი დაწერილია, ისინი არ იმუშავებენ.
აქ არის მაგალითები:
RTX-სთვის

გამარჯობა, ჰაბრ!
დღეს მე ვისაუბრებ ისეთ საინტერესოზე, როგორიცაა რეალურ დროში ოპერაციული სისტემა (RTOS). არ ვარ დარწმუნებული, საინტერესო იქნება თუ არა ეს გამოცდილი პროგრამისტებისთვის, მაგრამ ვფიქრობ, ახალბედებს მოეწონებათ.

რა არის RTOS?

თუ გადავხედავთ ვიკიპედიას, დავინახავთ 4-მდე განმარტებას.
მოკლედ, RTOS არის ოპერაციული სისტემა, რომელიც რეაგირებს გარე მოვლენებზე გარკვეული პერიოდის განმავლობაში. აქედან შეგვიძლია გავიგოთ RTOS-ის მთავარი დანიშნულება - მოწყობილობები, რომლებიც საჭიროებენ მოვლენებზე სწრაფ რეაგირებას (თუმცა, არავითარ შემთხვევაში არ აურიოთ RTOS-ის მუშაობა შეფერხებებში).

რატომ გვჭირდება ის?

ამის მიზეზი საკმაოდ ბევრია.
პირველ რიგში, RTOS მხარს უჭერს მრავალ დავალებას, სემაფორის პროცესის პრიორიტეტებს და ბევრ სხვას.
მეორეც, ის ძალიან მსუბუქია და თითქმის არ საჭიროებს რესურსებს.
მესამე, ჩვენ შეგვიძლია მივიღოთ ყოველივე ზემოთქმული თითქმის ნებისმიერ აპარატზე (მაგალითად, FreeRTOS მუშაობს თუნდაც 8-ბიტიან AtMega-ზე).
და მეოთხე: უბრალოდ ითამაშეთ და გაერთეთ.

3 ცნობილი RTOS-ის მიმოხილვა.

გთხოვთ გაითვალისწინოთ: შემდეგი ჩემი პირადი აზრია.
FreeRTOS
დღეს ერთ-ერთი ყველაზე პოპულარული RTOS. პორტირებულია დიდი რაოდენობით აპარატურაზე. Ოფიციალური ვებ - გვერდი.
დადებითი
1) უფასო
2) გადატანილია დიდი რაოდენობით აპარატურაზე
3) ძლიერი ფუნქციონირება
4) არის სხვადასხვა ბიბლიოთეკა: გრაფიკული, ინტერნეტი და სხვა.
5) კარგი დოკუმენტაცია.
მინუსები
1) საკმაოდ რთული პროცესია პორტირების ახალ აპარატურაზე.

დასკვნა: ეს არის ნამდვილად პროფესიონალური RTOS კარგი დოკუმენტაციით. დამწყებთათვის კარგი იქნება თუ მის აპარატურას უკვე აქვს პორტი.

KeilRTX
ბოლო დრომდე, ეს RTOS იყო კომერციული, მაგრამ ახლახან გახდა ღია წყარო. მუშაობს მხოლოდ მკლავის არქიტექტურაზე. Ოფიციალური ვებ - გვერდი.
დადებითი
1) უფასო
2) ადვილად პორტირებული ახალ აპარატურაზე (მკლავის არქიტექტურის ფარგლებში).
3) არის სხვადასხვა ბიბლიოთეკა: გრაფიკული, ინტერნეტი და სხვა.
მინუსები
1) თითქმის შეუძლებელია Keil-ში მასთან მუშაობა
2) ოდნავ შემცირებული ფუნქციონირება
3) მხოლოდ მკლავი არის მხარდაჭერილი.
4) (პირადი გამოცდილებიდან) კარგავს ბევრ RTOS-ს სიჩქარის თვალსაზრისით.
დასკვნა: იდეალურია დამწყები და მცირე პროექტებისთვის.
uc/os
ძლიერი კომერციული RTOS. საიტი .
დადებითი
1) ფუნქციების და ბიბლიოთეკების დიდი რაოდენობა.
2) მხარს უჭერს ბევრ რკინას
მინუსები
1) კომერციული.
2) ძნელი გამოსაყენებელი.

დასკვნა: დამწყებთათვის RTOS-ად დარქმევა საკმაოდ რთულია.

სხვა საინტერესო RTOS

RTLinux RTOS რეგულარულ Linux-ზე დაფუძნებული.
QNX RTOS Unix-ზე დაფუძნებული.

RTOS-ის გამოყენებით განვითარების მახასიათებლები

კარგად, პირველ რიგში, თქვენ უნდა გესმოდეთ შემდეგი: RTOS არ არის Windows. მისი დაყენება შეუძლებელია. ეს სისტემა უბრალოდ აწყობს თქვენს პროგრამას.
RTOS-ით პროგრამების დაწერისას, ფუნქციები ჩვეულებრივი გაგებით არ გამოიყენება. ფუნქციების ნაცვლად გამოიყენება პროცესები (ან ამოცანები), განსხვავება ისაა, რომ პროცესები, ფუნქციებისგან განსხვავებით, არის უსასრულო მარყუჟები და არასოდეს მთავრდება (თუ ვინმე ან თვითონ არ მოკლავს მას - ანუ განტვირთავს მეხსიერებიდან).
თუ რამდენიმე პროცესი ჩართულია, RTOS ცვლის მათ, რაც თავის მხრივ უზრუნველყოფს მანქანის დროსა და რესურსებს. სწორედ აქ ჩნდება პროცესის პრიორიტეტის კონცეფცია - თუ ორ პროცესს ერთდროულად სჭირდება მანქანის დრო, მაშინ RTOS მისცემს მას უფრო მაღალი პრიორიტეტის მქონეს.
RTOS-ს აქვს სპეციალური დაყოვნების ფუნქციები - ისე, რომ დრო არ დაიკარგოს ერთი პროცესის დაგვიანებისას, მეორე შესრულდეს.
ახლა მოდით ვისაუბროთ ისეთ რამეზე, როგორიცაა სემაფორი - ეს არის ის, რაც აკონტროლებს პროცესის წვდომას აპლიკაციის რესურსებზე. თითოეული რესურსისთვის არის მარკერი - როდესაც პროცესს სჭირდება რესურსი, ის იღებს მას და იყენებს ამ რესურსს. თუ ჟეტონი არ არის, მაშინ პროცესს მოუწევს ლოდინი მის დაბრუნებამდე. ნება მომეცით მოგცეთ მაგალითი: სხვადასხვა პროცესი აგზავნის ინფორმაციას ერთი UART-ით. თუ სემაფორი არ არსებობდა, ისინი რიგრიგობით აგზავნიდნენ ბაიტებს და იქნებოდა დაბნეულობა. ასე რომ, პირველმა პროცესმა აიღო ჟეტონი UART-ზე, გაუგზავნა შეტყობინება და გადასცა მეორეს (და ასე შემდეგ უსასრულოდ).

დამატებითი RTOS ბიბლიოთეკები.

RTOS ხშირად გვთავაზობს სხვადასხვა ბიბლიოთეკებს სამუშაოდ, მაგალითად, გრაფიკასთან, ინტერნეტთან და ა.შ. ისინი მართლაც მოსახერხებელია და არ უნდა მოგერიდოთ მათი გამოყენება. ამასთან, გახსოვდეთ, რომ RTOS-ის გარეშე, რომელზეც ისინი დაწერილია, ისინი არ იმუშავებენ.
აქ არის მაგალითები:
RTX-სთვის

გაქვთ შეკითხვები?

შეატყობინეთ შეცდომას

ტექსტი, რომელიც გაეგზავნება ჩვენს რედაქტორებს: