Granite River Labs Inc.
アプリケーション・エンジニアリング・マネージャー

浦邉 康雄　様

IARシステムズ
テクニカルマーケティング マネージャー

大山 将城

大山

以前に、弊社のお客様から、「開発途中に市場の要求から機能の追加を余儀なくされた。開発現場としては、本当に困るんだよなあ。」というお話を聞いたことがあります。

ということで、今回は機能追加をテーマにしてみたいと思いますが、こういう機能追加ってよくあることなのでしょうか？

浦邉

システムの大小にかかわらず非常によく聞く話ですね。最近のデバイスは、メモリに余裕があるケースも増えてきていますので、大規模な機能追加でなければ、対応することはそれほど難しくはないとは思います。

大山

だとしても、機能を追加するとこれまで最適に設計してきたシステムを再度見直す必要があります。テストをやり直すとか、デザインレビューをもう一度行うとか、かなり手戻り感は否めないため、本音で言えばやりたくない。

浦邉

そうは言っても、やらざるを得ないのが機能追加でしょう。

大山

確かに。仕方ない側面もありますが、何かいい方法はあるのでしょうか？

浦邉

実はあります。 それは、規模の大小に関わらず組込み用のOSを搭載しておくことです。

単機能なシステムでもOSを採用するメリットは、かなり多いです。 組込みOS自体、現在では無償、有償のものを含めればかなりの数がありますので、アプリケーションや予算に応じたOSが選択しやすい時代になっています。

大山

個人的には、RTOSというと複雑なタスク管理や通信が必要なアプリでのみ使うイメージが強いのですが、機能追加という視点でもメリットがあるのでしょうか？

浦邉

はい。組込みOSを採用することのメリットは、急な機能追加によって発生するシステム構成を見直す手間が、かなり軽減されるということです。 OSを入れるとオーバーヘッドを気にされる方も多いと思いますが、機能追加に比べれば、ほんの僅かなオーバーヘッドで済みます。また、機能追加＝タスクを追加すると同義になることが多いと考えられます。

ですから、事前に優先順位の低い空のタスクを用意しておくのも、ある種のオーバーヘッドと言えるかもしれませんが、システムに与えるインパクトはかなり抑えられるでしょう。

大山

なるほど。 予期せぬ機能追加のために空タスクを予め用意しておくということですね。

浦邉

もちろん、機能によってはタスクだけとは限りませんが、OSを採用することで、タスクを追加する時のシステムに与える影響を同じプラットフォームを使っていれば事前に調べることも出来ますし、実装も事前にテストできるので開発効率も向上します。

大山

本来なら、途中で機能追加することがないようにすべきでしょうが、売れてこその商品開発になりますので、機能の一つや二つ、サクッと実装できる余裕があれば、製品価値の向上やTime to Marketの短縮にも貢献できますね。では、こうした視点で組込みOSを導入する場合、ソフト開発視点で抑えておくべきポイントはありますか？

浦邉

以前にRTOSベンダにて色々なユーザーの開発をみてきた経験も踏まえて回答させてもらいますと、以下の3つのポイントを押さえておくといいのではないでしょうか。

ポイント1：各タスクは待ち時間を必ず作ること。
ポイント2：タスク内は、ループさせること。
ポイント3：割り込み処理は、割り込みハンドラおよび割り込みサービスルーチンに丸投げする

ポイント1の「各タスクは待ち時間を必ず作ること」についてですが、そのタスクが待ち時間に入ることで、次の優先度のタスクにCPUの実行が遷移します。それを繰り返すことで、各タスクが実行できるようになります。もちろん組み方にも依存しますが、各タスクに処理が回ることが重要なのです。

ポイント2の「タスク内は、ループさせること」については、1回で処理が終わったら再び起動するとこがないということであり、組込みシステムにおいては、そういう処理は極めて少ないものです。一般的ではありますが、組込みシステムは繰り返し動作を要求されることがとても多いです。なので、タスク内はループさせ、一通り処理が終わったら再度同じリクエストを受け付けるといった動きとして実装することになります。

ポイント3の「割り込み処理は、割り込みハンドラおよび割り込みサービスルーチンに丸投げする」については、組込みOSを初めて使う場合は戸惑うかもしれません。組込みOSを仕様しないシステムの場合、割り込みに入ってほしくない処理があった場合、その処理区間を割り込み禁止にすることで、目的の処理を実行し、その処理が終了したら割り込み禁止を解除するというコーディングになります。

浦邉

RTOSを使用しない場合は、mainの処理の中で、さまざまなイベントが生じることを念頭において記述する必要があります。その場合、可読性が落ちることはもちろんですが、いろいろなユースケースが生じた場合、どの割り込みを禁止にして、どの割り込みは受け付けるのか？など、再度調整し直す必要が出てきます（図１の左側）。

それに比べて、組込みRTOSを採用した場合、各々のタスクは簡潔に処理を記述できますし、割り込みの面倒はOSのカーネルが面倒みてくれます（図1の右側）。もちろん、組込みOSを使用しても割り込みの禁止や割り込みの許可設定も可能です。ですが、割り込みが入ってくることで、割り込み処理やスタックの考慮はRTOSのカーネルが管理してくれるので、コーディングのしやすさや可読性はかなり向上します。

また、上記内容は理解した上で、RTOSを使用していないケースもあるかと思います。全てのシステムにRTOSを採用の強制はできませんが、機能追加が発生するたびに、システムのメモリリソースの見直しが発生すると考えられます。テストもやり直しになります。RTOSの場合は、タスク単位でメモリの管理が行えますので、システムへのインパクトを最小限に抑えることが可能です。

そう考えると、RTOSを使用するメリットは、十分あると言えます。

大山

なるほど、RTOSを使うことで、可読性や割り込み調整に関しては大きなメリットがありそうなので、機能追加が開発途中にきたとしても、組込みRTOSを利用しておけば焦ることなく対応できるケースも増えそうですね。 浦邉さん、今回もありがとうございました。