Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Was sind die technischen Besonderheiten von QNX RTOS im Vergleich zu anderen RTOS?
ich bin neu hier und weiß nicht, ob ich hier richtig bin im Netz habe ich vieles gelesen, aber dennoch nichts konkretes gefunden was nur QNX RTOS hat und die anderen nicht.
Danke für die Antwort
Mein Prof ist ein kleiner QNX Fan und er meinte ich solle u.a. diese Frage auch behandeln. Hinsichtlich Mittbewerber habe ich folgende ausfindig gemacht:
Vx Works
Free RTOS
Linux
Sysgo
Nucleus RTOS
Green Hills Software: INTEGRITY RTOS
Darfst gerne ergänzen, falls ich weitere "bigplayer" vergessen habe
Ergänzung ()
Häufig lese ich diese Besonderheiten bei QNX:
"QNX Neutrino achieves its unique degree of efficiency, modularity, and simplicity through two
fundamental principles:
• microkernel architecture
• message-based interprocess communication"
Des Weiteren habe ich auf QNX gelesen:
Der Begriff "Mikrokernel" ist in Mode gekommen. Obwohl es sich bei vielen neuen Betriebssystemen um
"Mikrokernel" (oder sogar "Nanokernel") sein sollen, bedeutet der Begriff ohne eine klare Definition nicht viel.
Das eigentliche Ziel bei der Entwicklung eines Mikrokernel-Betriebssystems besteht nicht einfach darin, es "klein zu machen". Ein Mikrokernel-Betriebssystem verkörpert einen grundlegenden Wandel in der Herangehensweise an die Bereitstellung von Betriebssystemfunktionen. Modularität ist der Schlüssel, die Größe ist nur ein Nebeneffekt. Einen beliebigen Kernel als "Mikrokernel" zu bezeichnen, nur weil er zufällig klein ist, würde den Punkt völlig verfehlen.
Microkernel vs. Monolith sind so akademische Fragen, die außerhalb des Elfenbeinturms in der Praxis kaum eine Rolle mehr spielen, weil es am Ende doch auf Performance ankommt. Selbst bei macOS ist man mit einem "Nanokernel" gestartet und dann in der Praxis bei XNU davon abgekommen. Genau dasselbe wie mit RISC vs. CISC, wo inzwischen alle ISAs Hybride aus beidem sind, weil das in der Praxis einfach besser funktioniert.
Marketing-Unterlagen von Closed-Source-Betriebssystemen zu lesen, wenn man keinen Zugriff auf den Quelltext hat, ist auch wenig hilfreich, wenn es um "Forschung" geht. Keine Ahnung, wie hier jemand deine Hausaufgaben machen soll und was das überhaupt mit "Virtualisierung und Emulation" zu tun haben soll.
Hallo Wechsler,
danke für dein Impulse zu RISC CISC etc. werde ich recherchieren.
Übrigens, meine Hausaufgaben mache ich, nur brauche ich etwas. Unterstützung.
Danke für die Antwort
Mein Prof ist ein kleiner QNX Fan und er meinte ich solle u.a. diese Frage auch behandeln. Hinsichtlich Mittbewerber habe ich folgende ausfindig gemacht:
Linux ist kein Echtzeitbetriebssystem, sondern ein GPOS, das durch Preempt-Patch zu weicher Echtzeit fähig ist. Sysgo ist der Vendor des Echtzeitbetriebssystems und Hypervisors PikeOS.
JiHanh schrieb:
Darfst gerne ergänzen, falls ich weitere "bigplayer" vergessen habe
Ergänzung ()
Häufig lese ich diese Besonderheiten bei QNX:
"QNX Neutrino achieves its unique degree of efficiency, modularity, and simplicity through two
fundamental principles:
• microkernel architecture
• message-based interprocess communication"
Ist nichts besonderes bzw. frage ich mich bei message-based interprocess communication, ob da sich nochmal eine Besonderheit versteckt. Für mich sieht das nach den üblichen Mitteln mit Mutexen und Semaphoren aus.
Linux ist kein Echtzeitbetriebssystem, sondern ein GPOS, das durch Preempt-Patch zu weicher Echtzeit fähig ist. Sysgo ist der Vendor des Echtzeitbetriebssystems und Hypervisors PikeOS.
Was ist mit "Embedded Linux". Soweit wie ich verstanden habe, handelt es sich hierbei um ein RTOS und wird im Bereich Automotive eingesetzt oder hab ich es falsch verstanden?
Beinemann schrieb:
Ist nichts besonderes bzw. frage ich mich bei message-based interprocess communication, ob da sich nochmal eine Besonderheit versteckt. Für mich sieht das nach den üblichen Mitteln mit Mutexen und Semaphoren aus.
Ein Embedded Linux ist ebenfalls ein GPOS, das zwar im Automotivebereich eingesetzt wird, aber nicht für sicherheitskritische Anwendungen. Damit kannst du bspw. ein Mediacenter betreiben, das zu aufwändig zu programmieren wäre auf einem RTOS. Du musst bedenken: RTOSe sind in der Regel nicht sehr umfangreich in ihrer Funktionalität, sie sollen bestenfalls klein und schlank sein und eben das Notwendige können. Overhead ist meistens schlecht für ein RTOS. Ein GPOS wie Linux kann aber mal umfangreich daherkommen (auch im Embedded-Bereich).
Allerdings kommt jetzt die Besonderheit ins Spiel, dass manche RTOSe auch Hypervisoren sind (z.B. PikeOS) und dann kann das eingebettete Linux auf einer Partition vom RTOS laufen. Das Ganze ist dann so angelegt, dass eine native Partition, auf der irgendeine sicherheitskritische Anwendung läuft, räumlich und zeitlich getrennt ist von der Embedded-Linux-Partition, auf der dann z.B. ein Mediacenter läuft. Räumlich und zeitlich getrennt bedeutet hier, dass für die einzelnen Partitionen gewisse Systemressourcen reserviert werden wie eigene Speicherbereiche und somit keine Interferenzen vorkommen (sollen).
Ein Embedded Linux mit Echtzeitpatch ist ja nun trotzdem für weiche Echtzeit brauchbar (d.h. man kann damit bspw. irgendwelche nicht-sicherheitskritischen Sachen realisieren, die rasch ablaufen sollen, bei denen aber Determinismus keine Rolle spielt). Aber überall, wo eine vorher notwendig zu planende Zeitspanne dabei sein muss harte Echtzeit garantiert sein (z.B. weil eben eine Motorsteuerung nicht warten kann bis der Mediaplayer beendet wird und vermutlich eine Toleranzgrenze im Mikrosekundenbereich hat).
tl;dr: Wichtig zu verstehen ist, dass es einen Unterschied bei der Art der Echtzeit und im Umfang zwischen einem RTOS und einem GPOS (wie Linux) gibt, der nur RTOSe dazu befähigt in sicherheitskritischen Bereichen eingesetzt werden zu können.
Hi,
vielen Dank für dein Feedback!
Bist du sicher, dass Linux heute noch nicht für sicherheitskritische Systeme (Iso 26262 - ASIL B) eingesetzt wird? Leider kann ich nichts konkretes dazu im Netz finden. Außer auf der R*dhat Website, dass sie bereits vor 1-2 Jahren angekündigt haben, dass sie daran arbeiten. Leider noch keine Update dazu gefunden :/
kann mir bitte jemand jeweils kurz erklären, wieso diese Aspekte als QNX-Vorteile deklariert werden. Für euch wird es sicherlich selbsterklärend sein, für mich leider nicht :/
- Memory protection
· Full POSIX support
· Support for a wide range of networking protocols
· Support for a wide range of file systems
· Wide range of tools (from editors through to web servers) available for QNX
Hi JiHanh, vielleicht erläuterst du mal kurz, warum du diese Infos brauchst? Mir ist deine Motivation unklar (machst du das fürs Studium um irgendwas für einen Kurs zusammenzukratzen)?
Ergänzung ()
Linux im safety-kritischen Bereich einzusetzen halte ich für waghalsig. Die Initiative von Red Hat ist mir deswegen auch suspekt und ich erkenne darüber hinaus auch nicht die weiterführende Strategie. Für wichtige failure-is-no-option-Bereiche, also eigentlich alles ab ASIL C, wird, soweit mir bekannt, nichts eingesetzt, was nicht explizit dafür entwickelt wurde. Soll heißen: Auf eine Motorsteuerung (die vermutlich eher ASIL-D genügen muss) kommen nicht noch Binaries für den Empfang von DVBT-2 und erst recht kein ausgewachsenes GPOS (was gar nicht erst laufen würde wg. unzureichender Ressourcen). Da hat man dann einen Controller, der nur eine Aufgabe erledigt und so überschaubar ist, dass man genau weiß, wie sich der Controller verhalten wird und das wird meistens dann bare metal programmiert oder im höchsten der Gefühle mit einem RTOS, das MPU-handling mitbringt (was auf deine Frage abzielt, was memory protection angeht). Kurzer Exkurs und blumig-verkürzt dargestellt: Controller sind sowas wie die kleinen Brüder von CPUs. CPUs haben Memory Management Units, die sich reguläre OS zunutze machen für die dynamische Speicherverwaltung. Ein Controller hat idR nur eine Memory Protection Unit (MPU), die Speicher nicht dynamisch zuordnet, sondern nur Speicher vor (unbefugten) Zugriffen schützt. Das ist alles schlichter, überschaubarer und in der Konsequenz sinnvoller zertifzierbar.
Es gibt ja hart-echtzeitfähige Hypervisoren, die dann auf SoCs gemischt-kritikale Sachen packen und das dann auch recht sicher ist, aber da reden wir dann davon, dass ein GPOS wie Linux eigene Ressourcen hat und daneben theoretisch noch eine sicherheitskritische Anwendung läuft, die dann aber auf einer nativen Partition des RTOS läuft. Aber wie gesagt: So ein RTOS ist idR auch ein paar Millionen Codezeilen kleiner als ein GPOS wie Linux, weswegen sowas dann vermutlich eher geht und zertifzierbar ist).
Ergänzung ()
JiHanh schrieb:
· Full POSIX support
· Support for a wide range of networking protocols
· Support for a wide range of file systems
· Wide range of tools (from editors through to web servers) available for QNX
im Netz habe ich vieles gelesen, aber dennoch nichts konkretes gefunden was nur QNX RTOS hat und die anderen nicht.
