異色の分散システム向けRTOS「Virtuoso」の30年にわたる系譜：リアルタイムOS列伝（34）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第34回は、分散システム向けRTOSとして約30年展開されてきた「Virtuoso」「OpenComRTOS」「VirtuosoNext」を紹介する。

[大原雄介，MONOist]

「Virtuoso」の思想を受け継ぎスクラッチ開発した「OpenComRTOS」

　さてこのWind RiverによるVirtuosoの買収により、Virtuosoを使っていたユーザーはかなり困ることになった。先述した通り、大規模分散型RTOSというものはVirtuosoしかなかったからだ。そこで、Virtuosoの思想を受け継いだRTOSをスクラッチから開発しよう、という機運が高まった。これに携わったのがOpen License Society（http://www.openlicensesociety.org：このサイトURLは既に登録が切れているので注意）である。

　Open License Societyは研究団体であり、組み込みシステム向けに統一されたコスト効率の良いシステム設計手法を研究開発するための団体である。このOpen License Societyは目的を達成するための手段としてOpenSpec／OpenRTOS／OpenObjectsといったものを開発しようとしていた。実際に開発が始まったのは2005年頃で、その最初のターゲットがRTOSであるOpenComRTOSとなる。

　これはベルギーのIWT-Flanders（フランダース科学技術活用イノベーション促進機構）の資金援助を受けて開発したもので、ゲント大学 教授の Raymond Boute氏が率いるチームによる形式手法を使って最終的なコードを生成している。このOpenComRTOSは、分散カーネルをサポートして、多数のプロセッサを持つヘテロジニアス構成のシステム上で動くもので、分散型スケジューラーとハードリアルタイム性を担保できるとする。またカーネルのサイズは1KB未満と非常に小さい。

　機能的に言えば「Virtuoso 4」とほぼ同じものを提供するのが目的であり、これはほぼ達成できた。面白いのは、最初のターゲットになったのがMelexisのMLX16という16ビットRISC MCUであることだ。これは、Open License Societyへのスポンサーの一社がMelexisであることと無縁ではないように思う。他にWindows NTもターゲットになっており、OpenComRTOSのためのVPE（Visual Programming Environment）はこのWindows NT上で動作する。これは2006年8月にリリースされた。2008年1月には、Win32上で動作するOpenComRTOS 1.0.0のシミュレーターも提供されている。

　ただし、Open License Societyで提供されるものはどちらかといえば研究向けとなるRTOSの断片といった形で、フルセットのものではなかった。このOpenComRTOSをベースに、実際に製品レベルに仕立て上げたのが、やはりOpen License SocietyのスポンサーとなっていたベルギーのAltreonicである。2008年に同社はOpenComRTOSの製品化を行い、以後のメンテナンスは同社が行っている。ちなみにAltreonicの創業者兼CEO兼CTOであるEric Verhulst氏は、EONIC Systemsの創業者兼CTOでもあった。EONICがWind Riverに買収されたタイミングでVerhulst氏はCTOを辞め、2004年からはOpen License SocietyでOpenComRTOSの開発を行い、そして2008年にAltreonicを創業してOpenComRTOSを引き取った格好だ。

　さてそのOpenComRTOSというか、おおもとのVirtuosoの基本的なコンセプトは図2のようになっている。OpenComRTOSの基本はNodeで、これはCPU＋RAM／ROM＋周辺回路を組み合わせたものである。要するに普通のMCUそのものがNodeというわけだ。

図2　これ、Transputer T400シリーズを触ったことがある方には実にスッキリくる構図だと思う（もうその時点で年齢が分かるが）［クリックで拡大］

　1つのNode上では複数のタスクを実行可能である。これともう1つある要素がHubである。HubはNodeを接続するだけでなく、Hub同士での接続も可能である。Hub自身がNodeの機能を併せ持つことももちろん可能だ。この結果として、複数のタスクを1つのNode上で実現する事もできるが、複数のNodeの上にそれぞれタスクが稼働し、それらが相互に同期を取って稼働することもシームレスに可能である。というか、アプリケーションプログラマーから見ると、あるタスクが同じNodeなのか、別のNodeなのかを区別しない（できない）。これにより、膨大な数のプロセッサやDSPを抱えたシステムであっても、大きな1つのシステムとして扱うことが可能である。ちなみに管理の方では、NodeとHubをまとめたCluster、さらにそのClusterを複数個内包できるSiteという管理単位があるが、これはシステム管理上の都合であってアプリケーションには直接影響しない。