Was hält Gerätehersteller davon ab, auf RTOS-basierte Multicore-Geräte umzusteigen?

Entwicklungskosten, Komplexität und Bedarf.

Auf einem System, das harte Echtzeit sein muss, ist Multi-Core ein Schmerz (denke teuer) und die meisten Dinge, die harte Echtzeit sein müssen, sind nicht so komplex. Dinge, die keine harte Echtzeit sein müssen, müssen kein RTOS sein, also haben Sie ein System, das all das harte Echtzeit-Zeug handhabt, und eines, das Linux ausführt und das andere Zeug handhabt.

Die AFAIK-Multicore-Technologie wird derzeit in einigen Automobillösungen verwendet, jedoch normalerweise nicht als SMP( symmetrische Multicore-Verarbeitung ), sondern entweder AMP( asymmetrische Multicore-Verarbeitung ), bei der jeder Kern seine eigenen dedizierten Aufgaben ausführt, oder als Lock-Step-Dual-Cores, die denselben Code ausführen extra Verlässlichkeit.

Dieser Artikel von Freescale-Ingenieuren bietet einige Gründe für die Einführung in Autos:

Automobil-SoCs waren traditionell Single-Core, da nicht viel Rechenarbeit oder High-End-Anwendungen darauf abzielten. Automobile waren einfacher, ebenso die Anwendungen und die SoCs. Da immer mehr Elektronik in den Automobilen Einzug hielt, nahm die Komplexität der SoCs weiter zu. Jetzt liegt der Fokus darauf, den größten Teil des Automobils unter elektronischer Kontrolle zu haben.

Heutzutage produzierte High-End-Automobile bieten Funktionen wie elektronische Stabilitätskontrolle (ESC), Traktionskontrollsystem (TCS), fortschrittliche Fahrerassistenzsysteme (ADAS) usw. Diese Funktionen erfordern im Kern komplexe SoCs, die Daten schnell sammeln, verarbeiten und übertragen können Rate von mehreren Peripheriegeräten.

Unabhängig davon, mit wie viel Hochfrequenz der einzelne Kern arbeitet, wird es immer Leistungsengpässe und Herausforderungen geben, während mehrere Aufgaben ausgeführt werden. Ein einzelner Kern, der mit einer höheren Frequenz läuft, verbraucht mehr Strom. Dies macht die Single-Core-Architektur für Ultra-Low-Power-Anwendungen ungeeignet. Dual-Core-basierte SOC-Architekturen bieten einen besseren Kompromiss zwischen Leistung und Stromverbrauch als Single-Core-basierte Architekturen.

Freescale hat auch ein Dokument Embedded Multicore: An Introduction veröffentlicht, das die Vorteile und Herausforderungen von Multicore-Chips in eingebetteten Umgebungen erläutert. Zum Beispiel (auf Interconnect-Bussen):

Obwohl Mikroprozessoren fast augenblicklich die Art von komplexen Komplikationen ausführen können, für die Institutionen vor Jahrzehnten Millionen ausgegeben und Räume gebaut haben, hat der Schritt in die Multicore-Verarbeitung ironischerweise ein einfaches Problem ans Licht gebracht: Weil die Gesamtbandbreite unter den Bus-Mastern aufgeteilt werden muss, Mehr Kerne bedeuten weniger Bandbreite pro Kern.

Außerdem steigt mit zunehmendem Busverkehr das Risiko von Kollisionen und dies verringert die Bandbreite noch weiter. Kurz gesagt, ein Bus skaliert nicht weit über vier Kerne hinaus.

Während die Automobilindustrie ihre eigenen Sicherheits- und Zertifizierungsanforderungen hat, denke ich, dass es für Hersteller etwas einfacher ist, mit Multicore-Lösungen am Boden zu experimentieren, verglichen mit Flugzeugen, die in allen Situationen richtig fliegen müssen und ein viel größeres Schadenspotenzial haben, sodass die Einführung von Multicore wahrscheinlich ist viel langsamer sein.

Aber auch in der Avionik könnten sie irgendwann Einzug halten:

Die Arbeitsgruppe Multicore for Avionics (MCFA), der Vertreter von BAE Systems, BARCO, Boeing, EADS, ELBIT, GE Aviation, Hamilton Sunstrand, Honeywell, Rockwell Collins, Thales und Freescale angehören, wurde gegründet, um kommerziellen Avionikunternehmen dabei zu helfen, die Leistungs-, Leistungs- und Größenvorteile hochentwickelter eingebetteter Multicore-Prozessoren, wie denen von Freescale

Quelle

Bericht vom Arbeitsgruppentreffen 2013: http://onboard.thalesgroup.com/successful-multi-core-for-avionics-working-group-meeting-with-authorities/

Mehrkernsysteme bedeutet, dass auf Prozessorebene ein Verbindungsbus vorhanden sein muss, der Daten teilt. Diese Verbindung bringt ein gewisses Maß an Indeterminismus auf Nanosekundenebene mit sich – was ist, wenn sich die angeforderten Daten im Cache von Kern 1 und der Prozess in Kern 2 befinden? Was ist, wenn Streit entsteht?

Wenn RTOS den Mikrokernel startet, wie wird es außerdem mehrere Kerne nutzen – als separate Einheiten? Wird es strenge Sicherheitsrichtlinien erfüllen, wenn es den L3-Cache teilt, aber einen separaten L1-/L2-Cache hat?