RTOS的に使えるがRTOSではない「QP」はMATLABの代替候補にもなり得る？：リアルタイムOS列伝（22）（2/4 ページ）

[大原雄介，MONOist]

RTOSではないQPのコンセプト

　さて前置きが長くなったが、QP、厳密に言えばQP RTEFsとは何なのか。RTOSというのはある意味ブロッキング（Blocking）な処理を行うものであり、RTEFsではノンブロッキング（Non-Blocking）な形で処理を行うというコンセプト（というか、Samek博士の信念？）に基づく実装を提供する（図2）。

図2　Thread／Message／Queuesなどは共通だが、いわゆる同期メカニズムを廃しているところがRTOSとの相違点である［クリックで拡大］

　もう少し正確に書けば、RTEFsはActorなどと呼ばれることもあるActive Object（アクティブオブジェクト）と、階層構造化されたState-Machine（ステートマシン）の組み合わせであるとされる。これにより、「本質的に並行プログラミングのベストプラクティスをサポートし、自動的に実行される。結果として、従来のRTOSにおける“裸の”Thread（スレッド）や無数のBlocking Mechanism（ブロッキングメカニズム）よりも、安全で応答性が高く、管理が容易なアプリケーションが実現できる」というのがQuantum Leapsの主張だ。

　ただ、だからといって必ずしも従来のカーネルを全廃できるわけではない。図3がQP RTEFsを利用した場合のアプリケーション構造である。ArmのCortex-MなどのMCUを使う場合、ここにはQVやQK、QXK（これらは後で説明）などで提供されるBuilt-in Kernel（ビルトインカーネル）や、場合によっては従来のRTOSやOSなどを使うことも可能になっている。

図3　QP RTEFsにTrace用のQS（QP/Spy）、MBDツールであるQMが基本的な製品パッケージで、後は開発用にQUTest（単体テストツール）やQView（モニタリングツール）、QWin（プロトタイプツール）などが提供されている［クリックで拡大］

　これは、どちらかといえばハードウェア管理のために利用されるものであって、アプリケーション（というかThread）そのもののハンドリングはActive Objectをサポートするフレームワークや階層構造のEvent Processor（イベントプロセッサ）などで賄う形になっている。いわゆるRTOSの定義からすれば、このBuilt-in Kernelを利用する場合には確かにRTOSとしての条件をそろえていると言えなくも無いが、別のRTOSや汎用OSを利用する場合には、RTOSというよりはフレームワークと称した方が実情に合っている気がする。

　ところでこのフレームワークをうまく利用するためには、アプリケーションの側でState-Machineをある程度理解して使う必要がある。State-Machineが1つだけならプログラミングはそれほど難しくないが、QP RTEFsの場合には山ほどState-Machineが存在するために、これを普通のプログラマーがうまく利用するのはなかなかに大変（というか、かなり難易度が高い）である。そこで活躍するのがQMと呼ぶModel-Based Design（MBD：モデルベース設計）ツールである。