QNXとは？マイクロカーネル型RTOSの仕組み・Linuxとの違いとSDP 8.0の試し方・採用判断

QNX（キューエヌエックス）は、1980年にカナダで設立された企業が開発を始めた、マイクロカーネル型の商用リアルタイムOSです。いまはBlackBerry Limitedの一部門であるQNXが開発し、車載・医療機器・産業制御の分野で使われています。本記事では、QNXの中身をプロセスとAPIの粒度で分解し、Linuxとの違い、手元で動かす手順、採否の判断までを2026年10月時点の一次情報で整理します。

まとめ：QNXの正体と採用判断の結論

QNXの特徴は、ファイルシステムもネットワークスタックもデバイスドライバもカーネルの外、ユーザー空間のプロセスで動く点にあります。ドライバが異常終了しても、巻き込まれるのはそれを載せたプロセスまでで、カーネルは止まりません。復旧にはそのプロセスの再起動に加え、デバイスの再初期化などの手当てを設計しておきます。RTOSという枠組みの定義と、FreeRTOS・Zephyr・TOPPERSまで含めた選定軸はRTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断で整理しています。

現行はQNX SDP 8.0系で、2026年10月時点の最新は8.0.5（リリースノートの日付は2026年6月25日）です。8.0系の標準サポートは2031年12月31日まで、旧世代の7.1系は2028年7月31日で標準サポートが終わります。新規開発は8.0系を第一候補にし、対象SoCのBSPと、8.0で廃止された機能（APSやISRなど）の影響を先に確かめてください。

有償のQNXを選ぶ理由として最も重いのは安全認証です。QNX OS for Safety 8.0はISO 26262 ASIL DやIEC 61508 SIL 3などの認証を取得済みで、OS部分の認証作業を自社で抱えずに済みます。認証が要件に無く、Linuxで応答時間の要求を満たせると確かめられるなら、人材とライブラリの揃ったLinuxのほうが工数を抑えやすくなります。試すだけなら、非商用の無償ライセンスとQEMUで費用をかけずに始められます。

QNXとは：開発元と、マイクロカーネルという設計

QNXのメーカーはどこか｜Quantum SoftwareからBlackBerryの一部門へ

QNXは、ウォータールー大学の学生だったGordon BellとDan Dodgeが1980年に設立したQuantum Software Systemsから始まりました。その後、2004年にハーマン・インターナショナルへ、2010年にResearch In Motion（現BlackBerry）へ売却されています（経緯はWikipedia「QNX」）。

2026年10月14日の公式発表でも、発信者は「QNX, a division of BlackBerry Limited」と記されています。企業サイトはqnx.software、開発者向けドキュメントは従来どおりqnx.comで公開されています。公式サイトの公表値では、QNXを搭載した車両は2億7,500万台を超えます。

マイクロカーネルとprocntoの役割分担

Linuxのカーネルには、プロセス管理、メモリ管理、ファイルシステム、ネットワークスタック、デバイスドライバが同じアドレス空間に入っています。ドライバのバグがカーネルパニックにつながるのはこのためです。カーネルの役割分担そのものはカーネルとは？OSの中核が担う役割と仕組みで扱っています。

QNXでは、マイクロカーネルとプロセスマネージャがprocntoという1つの実行ファイルにまとまっています。マイクロカーネルが受け持つのはスレッドのスケジューリング、メッセージパッシング、割り込みの取り次ぎ、タイマです。同じprocnto内のプロセスマネージャが、プロセスの生成、メモリ管理、パス名空間の管理を担います。TCP/IPスタックもUSBドライバもファイルシステムも、その外側のユーザー空間で動くプロセスです。

ただし「ドライバ1本につき1プロセス」とは限りません。ネットワークでは、devs-で始まるドライバがio-sockのプロセスに読み込まれて動くため、ドライバが落ちればio-sockごと止まり、そのホストのネットワーク機能が途切れます。カーネルや他のプロセスは動き続けますが、ソケットを開き直すといった復旧はアプリケーション側で設計しておく必要があります。プロセス間の受け渡しが増える分、その往復を軽くすることがQNXの設計の中心になっています。

QNXは車載のOSか｜車載・医療・産業制御に共通する3つの要件

車載専用ではありません。公式サイトの対象業界には、自動車のほか医療機器、産業用制御、ロボット、鉄道、航空宇宙・防衛が並びます。共通点は3つです。応答時間の上限が仕様で決まっていること、機能安全規格の認証が調達条件になること、製品寿命が10年から20年と長く、OSの保守期間が製品の寿命を縛ることです。

QNX OS 8.0の仕組み：メッセージパッシングとスケジューリング

MsgSend・MsgReceive・MsgReplyの最小コード

QNXでプロセス同士をつなぐ基本手段は、同期メッセージパッシングです。クライアントがMsgSend()を呼ぶとブロックし、サーバーがMsgReceive()で受け取って処理し、MsgReply()を返した時点でクライアントが再開します。次のコードは、公式リファレンスのname_attach()の例を、値を2倍にして返す形に縮めたものです。関数の宣言はQNX OS 8.0のリファレンスに合わせ、宣言を写したスタブヘッダでCの構文検査までは通しています。QNX上での実行結果は載せていないので、手元のSDPでビルドして確かめてください。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/dispatch.h>

#define ATTACH_POINT "msgdemo"

typedef struct {
    uint16_t type;              /* 先頭は必ず型フィールド */
    int      value;
} my_msg_t;

typedef union {
    uint16_t      type;
    struct _pulse pulse;
    my_msg_t      data;
} recv_buf_t;

static int server(void)
{
    name_attach_t *attach = name_attach(NULL, ATTACH_POINT, 0);
    if (attach == NULL) {
        return EXIT_FAILURE;
    }
    for (;;) {
        recv_buf_t msg;
        rcvid_t rcvid = MsgReceive(attach->chid, &msg, sizeof(msg), NULL);
        if (rcvid == -1) {
            break;
        }
        if (rcvid == 0) {                    /* パルス（切断通知など） */
            if (msg.pulse.code == _PULSE_CODE_DISCONNECT) {
                ConnectDetach(msg.pulse.scoid);
            }
            continue;
        }
        if (msg.type <= _IO_MAX) {           /* open() 等のシステムメッセージは断る */
            MsgError(rcvid, ENOSYS);
            continue;
        }
        int answer = msg.data.value * 2;
        MsgReply(rcvid, EOK, &answer, sizeof(answer));   /* ここでクライアントが再開 */
    }
    name_detach(attach, 0);
    return EXIT_SUCCESS;
}

static int client(void)
{
    int coid = name_open(ATTACH_POINT, 0);
    if (coid == -1) {
        return EXIT_FAILURE;
    }
    my_msg_t msg = { .type = _IO_MAX + 1 };
    for (msg.value = 0; msg.value < 3; msg.value++) {
        int answer;
        /* 返信が来るまでこのスレッドはブロックする */
        if (MsgSend(coid, &msg, sizeof(msg), &answer, sizeof(answer)) == -1) {
            break;
        }
        printf("sent %d, reply %d\n", msg.value, answer);
    }
    name_close(coid);
    return EXIT_SUCCESS;
}

int main(int argc, char **argv)
{
    if (argc == 2 && strcmp(argv[1], "-s") == 0) {
        return server();
    }
    if (argc == 2 && strcmp(argv[1], "-c") == 0) {
        return client();
    }
    fprintf(stderr, "usage: %s -s | -c\n", argv[0]);
    return EXIT_FAILURE;
}

開発ホストでは、SDPの環境変数を読み込んでからqccでターゲットを指定してビルドします。x86_64向けはgcc_ntox86_64、AArch64向けはgcc_ntoaarch64leです。

source ~/qnx800/qnxsdp-env.sh
qcc -Vgcc_ntoaarch64le -o msgdemo msgdemo.c

ターゲットで./msgdemo -s &を起動してから./msgdemo -cを実行すると、0・1・2を送って0・2・4が返る作りです。MsgSend()のリファレンスでは、送信側は受信待ちの間STATE_SEND、受信された後は返信までSTATE_REPLYに入ると定義されています。pidinでスレッドの状態を見ると、どのプロセスがどこで待っているかが追えます。

優先度の継承とサーバーブースト

ChannelCreate()のリファレンスによれば、メッセージを受け取ったサーバーのスレッドは、送信したスレッドと同じ優先度で動きます。さらに、サーバーのスレッドが全員ほかのクライアントの処理中でメッセージが待たされたときは、そのチャネルで受信したことのあるスレッドの優先度が必要に応じて引き上げられます（サーバーブースト）。低い優先度の処理が高優先度のクライアントを待たせ続ける優先度逆転を、この2段で防ぎます。チャネル作成時に_NTO_CHF_FIXED_PRIORITYを指定すると継承は無効です。ファイルを開く、読む、デバイスへ書くといった操作も、内部ではこのメッセージ送受信です。

リソースマネージャとドライバの実装形態

アプリケーションから見たデバイスの窓口は、リソースマネージャと呼ばれるプロセスです。起動するとパス名空間に担当パスを登録し、そこへのopenやread、writeをメッセージとして受け取ります。シリアルならdevc-、ブロックデバイスならdevb-で始まるプロセスがこの役を担い、ハードウェアを叩くドライバ部分はその中に実装されるか、モジュールとして読み込まれます。

ネットワークのリソースマネージャはio-sockです。QNX OS 8.0の移行ガイドは、7.1までのio-pktがio-sockに置き換えられたと明記しており、BSPのビルドファイルもdevnp-系からdevs-系のドライバへ書き換えが要ります。io-sockはFreeBSDのネットワークコードを土台にしており、8.0.5でその基準がFreeBSD 13.5から14.3へ上がりました。古い資料でio-pktの設定例を見つけても、8.0ではそのまま使えません。

スケジューリングポリシーとAPS廃止の影響

スケジューラは固定優先度のプリエンプティブ方式で、同じ優先度の中の扱いを3つのポリシーから選びます。

7.1までの資料でよく紹介されていたアダプティブパーティショニング（APS）は、プロセス群にCPU時間を百分率で割り当てる仕組みでした。SDP 8.0の廃止告知では「Adaptive partitioning scheduler (APS)」がDiscontinuedで、代替は「N/A」です。7.1でAPSに頼って表示系の負荷から制御系を守っていた設計は、8.0へ移るときに作り直しになります。

8.0で特定のスレッドの実行時間に上限を設けたいなら、スポラディックの予算と補充周期で縛るのが標準の手段です。ただしCPU時間の上限は締切の保証そのものではありません。制御系の締切は、優先度の割り当てと最悪実行時間の見積もりで別に示す必要があります。

8.0で変わった点｜細粒度ロック・IST・QNX OSへの改称

8.0は7.1からカーネルの内部を作り替えています。公式のSDP比較表は、2〜64コアのSoCでほぼ線形のスケーラビリティと、約10〜20マイクロ秒の割り込みレイテンシを掲げています（測定条件は公表されていません）。

割り込み処理は、移行ガイドで「Interrupt Service Routines (ISRs) are no longer supported」とされ、割り込みにスレッドを結び付けるIST方式へ移りました。ハンドラ内で使えるAPIの制約に悩む場面が減る一方、7.1のISRを書いたドライバは書き直しになります。製品名も整理され、従来の「QNX Neutrino RTOS」は8.0から「QNX OS」と呼ばれます。

QNX SDP 8.0の版と開発環境

8.0.xのリリース履歴とサポート期限

QNX SDP（Software Development Platform）は、OS本体・ツールチェーン・IDEをまとめた開発キットです。公式のライフサイクル表では、8.0.xの初回提供を2023年12月としています。各リリースノートの日付は次のとおりです。

期限は、8.0.xが標準サポート2031年12月31日・製品寿命2033年12月31日、7.1.xが2028年7月31日・2030年7月31日です。7.1で動いている製品の版上げを考えるなら、io-sockとISTへの書き換えを見積に入れてください。

対応アーキテクチャと開発ホスト｜macOSとArmホストは対象外

ターゲットはx86_64とAArch64の2系統で、32bit ARMは対象外です。8.0 GAのリリースノートには、Raspberry Pi 4 Model B、NXP i.MX8M Plus・i.MX8QM、TI Jacinto 7 TDA4VM、Intel Celeron J6413からRaptor Lake i9-13900までが検証済みとして並びます。ARMv9については、8.0.2のリリースノートが「ARMv9.0機でAArch64バイナリを検証済みだが、ARMv9.0の拡張は未対応」と書いており、ARMv9のSoCでもARMv8相当の命令で動くと読むのが正確です。

開発ホストは、8.0.5のリリースノートでWindows 11、Ubuntu Desktop 24.04／22.04 LTS、Red Hat Enterprise Linux 9に限られます。8.0.4まで入っていたWindows 10は外れ、macOSとArmプロセッサのホストは8.0のGA時点から対象外です。Apple シリコンのMacしか無い開発者は、x86のLinux機かクラウドのLinuxを用意することになります。

ツールチェーンとIDE｜GCC 12.2・Momentics・VS Code

8.0 GAのツールチェーンはGCC 12.2（binutils 2.41.0）、GDB 11.2、Python 3.11、LLVM libc++ 16で、C++17とC++20に対応します。8.0.2でGDBが14、libc++が18、binutilsが2.43へ上がりました。新しいGCCを前提にしたサードパーティのライブラリは、そのままでは通らないことがあります。依存ライブラリが要求するコンパイラの版は着手前に洗い出してください。

IDEはEclipse 2023-06を土台にしたQNX Momentics IDE 8.0と、Visual Studio Code向けのQNX Toolkitの2つです。どちらもターゲット上のプロセスのデバッグ、プロファイリング、監視ができます。

QNXを手元で試す方法：無償ライセンス・QEMU・AWS

QNX Everywhereの無償ライセンス｜非商用・本番に使わないことが条件

QNX EverywhereはCES 2025で始まった取り組みで、2026年1月6日の公式発表によれば、QNX SDP 8.0とQNX Hypervisor 8.0を非商用向けに無償で提供しています。発行数は同発表時点で12,000件を超えました。myQNXアカウントを作り、QNX Software Centerから入手します。

条件はライセンス案内にあり、趣味の利用では「商用製品を作らないこと、成果物を本番に使わないこと」が求められます。社内の業務で使う試作は境界にあたるため、評価の目的を決めた段階で契約条項を読んでください。

QEMUでQNX OS 8.0を起動する手順

ボードが無くても、公式のQuick Start Target Image（QSTI）を使えばUbuntu 22.04／24.04のPC上のQEMUでQNX OS 8.0を起動できます。QSTIの手順書の流れは次のとおりです。QNX Software Centerで「QNX SDP 8.0 Quick Start Target Image for QEMU」を入れると、イメージが~/qnx800/images/qemuに置かれます。

cd ~/qnx800/images/qemu
./unpack_qemu_image.sh          # 分割アーカイブを展開し qemu フォルダを作る
source ~/qnx800/qnxsdp-env.sh
cd qemu
mkqnximage --run               # 既定は8 CPU・4GB RAM・720p

# 別の端末で、同じ環境とフォルダに入ってから実行する
source ~/qnx800/qnxsdp-env.sh
cd ~/qnx800/images/qemu/qemu
mkqnximage --getip             # ゲストのIPアドレスを表示
mkqnximage --stop              # 停止（シリアル側なら Ctrl+A のあと x）

起動した端末がそのままシリアルコンソールになります。先ほどのmsgdemoをgcc_ntox86_64でビルドし、表示されたIPアドレスへ転送すれば、メッセージパッシングの動きを手元で確かめられます。手順書は全機能を使うならQEMU 10への更新を勧めており、QEMU 8ではVulkan系、QEMU 6では高度なグラフィックを避けるよう書いています。

Raspberry Pi 4の実機とAWSのQNX OS AMI

実機で試すなら、GAで検証済みのRaspberry Pi 4が最短です。SDPとRaspberry Pi用BSPを入れ、SDカードにイメージを書き込み、シリアル接続で起動を確かめます。CIに組み込みたい場合は、AWS MarketplaceにQNX自身が出品している64ビットArm向けの「QNX OS 8.0.5 AMI」があり、Graviton搭載のEC2で動かせます。AWSのQNX on AWSワークショップは、東京を含む7リージョンでCodeBuildからQNXインスタンスにテストを流す構成を公開しています。

QNX OS for Safetyと安全認証：ASIL Dの取得範囲

QNX OS for Safety 8.0の認証範囲

QNX OS for Safety（QOS）8.0の製品ページによれば、TÜV Rheinlandから次の認証を受けています。

同梱の読み取り専用ファイルシステムQNX Filesystem for SafetyはISO 26262 ASIL B、C/C++のツールチェーンはISO 26262のTCL3・IEC 61508のT3に分類されています。鉄道のEN 50128やEN 50657などは、製品の認証ではなくQNXの認証支援サービスの対象として挙がっている点に注意してください。

認証済みOSの再利用と自社に残る適合確認

未認証のOSでASIL Dのシステムを組むなら、OSの設計文書、テスト証跡、故障モード解析、ビルドに使ったコンパイラの適格性確認までを自分たちで用意して審査に出すことになります。QOSは安全要素（SEooC）として組み込める前提で作られており、公式も「認証が要るのは自社が作る部分だけで、土台のOSやツールチェーンは含まない」と説明しています。それでも、自社のアプリとシステム統合がSafety Manualの前提を守っていることの証明は自社に残ります。無償のRTOSと有償のQNXを比べるときは、ライセンス費と「認証を自前で通す工数と期間」の差で比べてください。

QNX OSとQOSのバイナリ互換と安全要求の確認

QOSの製品FAQは、QNX SDP 8.0とQOS 8.0が「completely binary compatible」だと書いています。試作は通常版のSDPで進め、認証が要る段階でQOSへ移す段取りが取れるため、初期から安全認証版を調達しなくて済みます。ただし同じFAQは、移行の中心がQOSに付属するSafety ManualとSecurity Manualの内容を理解し、設計に織り込むことだと説明しています。マニュアルが課す使い方の制約は、試作の段階から設計に入れておかないと終盤で手戻りになります。

QNXとLinux・FreeRTOS・Zephyrの違い

QNXとLinuxの違い｜PREEMPT_RTでも埋まらない3点

LinuxにもPREEMPT_RTがあり、応答時間はかなり詰められます。それでも同じにならない理由は3つです。構造の面では、モノリシックカーネルのLinuxはドライバの不具合がカーネル全体を巻き込みます。認証の面では、ASIL DやSIL 3を取得したLinuxディストリビューションの選択肢が限られます。そして最悪応答時間を数値で保証する材料が、QNXのほうが揃っています。

逆にLinuxが強いのは、技術者の集めやすさ、パッケージの豊富さ、クラウドやコンテナの資産です。比べるときは、ライセンス費だけでなく、BSPの有無、既存資産の移植量、認証と保守にかかる工数まで含めてください。認証が要件に無く、対象SoC上のLinuxで最悪応答時間を測って締切を満たせるなら、Linuxを第一候補にしてよい場面が多くなります。Linux側の事情はLinuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説にまとめています。

Linux向けソフトの移植条件とバイナリ非互換

Linuxのバイナリはそのままでは動きません。QNXはpthread、ソケット、ファイル操作といったPOSIXのAPIを備えるため、ソースからの移植なら書き換えは少なく済みます。ただしglibc固有の関数やLinux独自のシステムコール、epollのようなLinux専用のAPIに依存する部分は書き直しです。車載でAdaptive AUTOSARを載せる構成なら、Adaptive AUTOSARがアプリケーションへ課すPOSIXプロファイルとの突き合わせも要ります。

Rustで書く場合、rustcのプラットフォーム表ではQNXはTier 3で、SDP 8.0向けのaarch64-unknown-qnx・x86_64-pc-qnxは標準ライブラリの完全対応が作業中です。Rust資産を前提にするなら、no_stdで足りるかを先に確かめてください。

FreeRTOS・Zephyrとの違い｜MMU要件とプロセス分離

FreeRTOSやZephyrは、MMUを持たないマイコンでも動く軽量なRTOSで、フットプリントは数十キロバイト規模です。QNXはMMUを前提にプロセスごとのメモリ空間を分けるため、あるプロセスのポインタ暴走が他を壊しません。代わりにMMU付きのアプリケーションプロセッサと、数メガバイト以上のRAMが要ります。

RAMが数百キロバイトのセンサーノードならFreeRTOSやZephyr、プロセス分離とファイルシステムとネットワークが要るSoCならQNX、というのが選び分けの軸です。Zephyr側の構成はZephyrOS（Zephyr RTOS）とは？特徴・FreeRTOSとの比較とLTSの選び方で扱っています。

VxWorks・ITRONとの比較｜認証実績とPOSIX資産

商用RTOSの競合はWind RiverのVxWorksで、こちらも機能安全の認証実績を持ちます。国内に長くあるITRON系（μITRON、TOPPERSなど）は軽量でロイヤリティの負担が小さい代わりに、プロセス分離やPOSIX資産の面でQNXとは土俵が違います。分類の全体像は組み込みOSとは？3分類の境界とITRON系の位置づけを参照してください。実務では、仕様書や調達要件にOSの指定や求める認証レベルが書かれているかを先に確かめ、指定が無ければ認証・SoC・資産の3点で候補を絞ります。

QNX Hypervisor｜QNXとLinuxのゲスト分離

認証が要る制御系と、機能が多い情報系を1つのSoCに載せたい場合は、QNX Hypervisorで両方を分離して動かします。8.0のリリースノートでは、ゲストとしてQNX OS 8.0とUbuntu 22.04を検証済み、Androidもサポート対象としています。メーターはQNXで確定的に描き、ナビや音楽はAndroidやLinuxの資産を使う、という車載の典型構成です。仮想化の型そのものはハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定までで扱っています。

QNXの採用判断：選ぶ条件と見送る場面

採用してよい3条件｜安全認証・最悪応答時間・長期保守

1つ目は、ISO 26262 ASIL D、IEC 61508 SIL 3、IEC 62304 Class Cのいずれかが仕様書に書かれている場合です。認証済みOSを買うほうが速く確実に進みます。2つ目は、「平均は速い」ではなく「上限は何マイクロ秒」を示す要件がある場合。3つ目は、製品寿命が10年を超え、保守とセキュリティ修正の供給元を契約で確保したい場合です。商用OSは期限が明示されるので計画は立てやすい一方、8.0系の製品寿命は2033年12月31日で、2026年に設計する製品の10年には届きません。採用するなら、延長保守の契約条件か、次の版への移行計画を見積の段階で確かめてください。

見送るべき3場面｜量産単価・人材・クラウド前提

1つ目は、出荷台数が多く単価が厳しい民生機器です。台数に比例するランタイム費用が効くため、認証要件が無いならLinuxやZephyrのほうが原価は下がります。2つ目は、開発体制をこれから組む場合です。QNXの経験者はLinux技術者よりはるかに少なく、短納期の案件で人が集まらないリスクは技術的な優位を打ち消します。3つ目は、KubernetesやDockerを前提とするクラウド連携が主題のシステムで、Linuxのエコシステムには勝てません。

商用ライセンスの費用構造｜開発シートとランタイム

商用ライセンスの価格は公開されておらず、案件ごとの見積です。費用は、開発者が使う開発シートと、出荷台数に応じたランタイムの2本立てが基本の形です。見積の前に、想定出荷台数、対象SoC、QOSの要否、サポート期間の4つを決めておくと話が早く進みます。年間売上1,000万米ドル以下の新興企業・中小企業向けには、2026年10月14日に発表された「QNX Launchpad」があり、SDP 8.0やQOS、Hypervisorを商用利用できる条件で提供しています。

QNX案件を外部へ委ねるとき見積書で確かめる5項目

3つ目は見落とされやすい項目です。「QNXで作ります」という記述だけでは、通常版で作るのか認証版で作るのかが分からず、ライセンス費も証跡づくりの作業量も変わります。認証を通す前提なら、証跡の作成と提出までが作業範囲に入っているかを文面で確かめてください。組み込み機器のソフトウェアとクラウド側のデータ基盤をまとめて相談したい場合は、AI/IoTソリューションで受け付けています。

よくある質問

QNXは無料で使えますか？

非商用に限れば無料です。QNX EverywhereでmyQNXアカウントを作ると、QNX SDP 8.0とQNX Hypervisor 8.0を入手できます。製品に載せて販売する場合や本番で使う場合は、商用ライセンスの契約が要ります。

QNXとLinuxはどちらを選べばよいですか？

機能安全規格の認証が調達要件にある、最悪応答時間を数値で示す必要がある、保守を契約で確保したい。このいずれかに当てはまればQNXを候補に入れます。そのうえで、対象SoCのBSP、開発体制、出荷台数あたりの費用を比べて決めます。どれにも当てはまらず、Linuxで締切を満たせると測れたなら、Linuxのほうが工数を抑えやすくなります。

QNXの最新バージョンはいくつですか？

2026年10月時点の最新はQNX SDP 8.0.5で、リリースノートの日付は2026年6月25日です。OS本体の名称は8.0から「QNX OS」で、旧称はQNX Neutrino RTOSです。7.1系は2028年7月31日に標準サポートが終わります。

QNXのエミュレータはありますか？

公式のQuick Start Target Image for QEMUがあり、Ubuntu 22.04／24.04のPC上でQNX OS 8.0を起動できます。mkqnximage --runで起動し、mkqnximage --stopで止めます。

QNXの開発にmacOSは使えますか？

使えません。SDP 8.0はmacOSとArmプロセッサのホストをサポートせず、8.0.5の開発ホストはWindows 11、Ubuntu 24.04／22.04、RHEL 9です。Macから作業するなら、x86のLinux機かクラウド上のLinuxにSDPを入れる構成になります。

関連記事

• RTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説
• 組み込みOSとは？3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説
• AUTOSAR OSとは？OSEK由来の仕様とスケーラビリティクラスの選び方を実装目線で解説
• カーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】
• ハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定まで実装者向けに解説