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

» 2022年05月09日 07時00分 公開
[大原雄介MONOist]

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

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

図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 図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:モデルベース設計)ツールである。

Copyright © ITmedia, Inc. All Rights Reserved.