はじめに
RTOS上での組込みシステムに携わってきて、半世紀近くなるが、Linuxのような他のOS上での組込みって、どのように作るんだ、機能間のIFはどのようにするんだ、メッセージが漏れたらどうするんだ、そんなものLinuxで作れるものか、と否定的。
そしたら、なぜRTOSが良いのか、と問うが、どうもはっきりしないのでここではその事を書いてみる事にしました。
組込みシステムって何?
車のエンジン制御、各ランプ、センサー表示するもの、炊飯器内でのお米を炊く制御をするもの。
小さい細かい制御するものなんだ、と思ったら、昔、開発した首都高速の中央監視制御装置、部屋2つ分を占有する大きなシステムも組込みで、大きさには無関係。
携帯内のApp(ダウンロードする)は組込なのか、なんか違う。ハードデバイスに絡んでいないいから?、いや、中央の監視装置って、直接デバイスに関係していないしなぁ。リアルタイム性が準備されているか否かなのか?
一般的に、
システムとして外部から閉じた用途特有なシステム
の事を組込みと呼ばれている。これによく追加されるのが、メモリに制限があるとか、リアルタイム性が要求されるとか、がある。でも、システムのデカさに関係ないのでメモリのサイズ、ハードには関係ない。リアルタイム性についてはハードで対応できるし、なんとでもなる気がする。
また、「用途特有」といっても見方によりそれが特有となってしまい、なんか漠然としている。
では、いったい組込みってなんなんだろう。
組込みと言われているシステムには何かの手順従って制御が含まれている。例えば、簡単がランプ表示の場合、ONの指示があれば、ON制御する、フリッカー表示の場合少し複雑である時間経過後、ON、再度時間後OFF、繰り返しをする。ある処理した後、この処理をするといった手順がある。そして、この状態の時はこれを実行すると言った状態遷移(FSM)によりその手順を実行する事が多い。
一方、組込みでないシステムはデータ取得と言った手順でなく処理結果のみを見る事が多い。
ここで、組込とは、と再定義するつもりはないが、「処理手順」は組込みの重要な特徴だと思う。
次に開発してきた組込みシステムの以下の特徴から組込みが何か考えます。
- 信頼性(正確に動作する事)を重視
処理がどう動いているかを証明しなければいけないし、予想されるエラーが発生した場合のどう動くのかを明らかにする必要があった。一旦、不具合(誤動作)が発生した場合、その原因を追求し、再発防止をしなればならない、と厳しいものばかりだった。 - システムとして閉じている
システムに閉じたシステムで外部からアクセスできない。プロクラムは基本自作。何かの不具合が発生した場合、ユーザーに自作でないものが原因、対処できないとは言えない。 - 開発プロセスがトップダウンで、即プログラミングはありえない
基本設計、詳細設計、テスト仕様、そして実装(コーディング)、デバッグ、テストとのプロセス
などがある。
程度こそあれ、組込みでは信頼性(正確に動作している事)が重要視される。
組込みは
- 処理手順がある
- 処理が正確に動作する
ものとなる。
リアルタイム性
どこかの資料から、
リアルタイム性とは、要求される期限までに処理が実行できる性質のこと。
となっている。
「期限」と言うが、現実のシステム開発ではほとんど、この期限なるものを意識して作る事はなくなった。昔は数マイクロ秒以内に処理をしなくてならない事など、を考える必要が多かったが、今はCPU処理速度が速くなった事とハードで対応されているので必要がなくなった。ハード対応の例として、シリアル9600bps(今時、9600と言ってもわからないかも)のデータの1ms毎の送受信だって、実際にはバッファが準備されているので、数十msになるし、DMA転送使えば、期限なるものを長くできる。
それにRTOS上ではいろんな処理が影響するので、システム全体の構造設計時に処理(期限)が間に合わないかを考えねばならないが、この20年、そんな事をする人に会った事がない。これらの事から「リアルタイム性=期限」と言うのはCPUクロックが遅かった時代、過去の産物のような気がする。
よくある大きな勘違いは「速い事がリアルタイムだと思われている」事だと言われている。そんな事は言っても、リアルタイムって言ったら、即応答して、なんか速い事の代名詞だよなぁ。ところが、世の中の事象には適正な時間が存在し、それぞれ、固有時間があるので遅い速いは判定できない。リアルタイム性は速い遅いには関係せず、「時間に正確である」事だと思う。例えば、ある弁の閉じる処理である処理から200μs後に閉じたいとの要求がある時、この時間は早くても遅くてもだめでちょうど200μs後でなればならない。ここには、期限などの要因はない。
リアルタイム性は本当に「期限」「正確な時間」と言う時間の事だろうか。時間の対応は割込み処理、タスクの優先で対応、最悪の場合は処理時間を測り、その時間を短くし、問題となる処理を優先的に処理させる事により対応している。この事からリアルタイム性って、時間の問題でなく、ある事象発生により即座処理する優先の仕組みを言っているのではないだろうか。
- リアルタイムの期限は意味があるのだろうか
- リアルタイム性とは速い事ではなく、時間に正確な事
- 時間ではなく、即時起動、つまり優先処理ではないのだろうか
やっぱりLinuxよりRTOSがいいんじゃね
RTOSはタスクを生成、起動し、そのタスク間でメッセージ、イベント、セマフォにより相互に同期を取る事ができるようになっている。
Linuxについても同様なものがあるが、タスク(プロセス)の処理がシステムに満遍なく動くようになっている。一方、RTOSでは優先によりタスク切り替え、移行が速く、リアルタイム性が高くなっている。そのため、linuxはタスク(プロセス)間の影響はあまりないが、RTOSではタスク間の影響が大きくなっている。つまり、RTOSの優先(リアルタイム性)をとるか、linuxの優先を犠牲にして相互に影響がないものをとるかの違い。
また、RTOSを使っているからと言っても、それがリアルタイムシステムになるとは限らず、ただ作り易くなるだけの事。
昔からRTOSでのソフトって、人間社会、会社組織に似ていると思う。人それぞれには役割(タスク)があり、お互いにコミニケーションをとりながら、動いている。もう少し例えを考えると、RTOSはチームプレイで、linuxは個人プレイではないだろうか。
チームプレイでは機能(ブレイヤー)との関係が密でお互いに影響を及ぼし、誰かが失敗すれば、負けてしまう。お互いにタイミングを取って処理をする。ある人にパスをすれば、その人は即動いてくれる。ボールを持たない人は遊んでいず、いかにパスを受けるか、動かなくちゃいけない。ただ、このチームプレイ、処理が複雑で作り上げるのが大変。
個人プレイでは、他に影響がない代わりに他のプレイヤーがどう動くのかわからない。
と横道に逸れてしまった。
元に戻ると、組込みには処理手順があり、処理間に時間的すきまはなく、実行する必要があるので優先処理が不可欠。そして、「正確に動かなくちゅ」には機能毎の役割分担をする事にそれぞれの動作が簡単で明確になり動作が正確になる。一方、linuxの場合はなんでもかんでも処理する事となり、混乱し、複雑になる。
理由が希薄だけど、「やっぱりRTOSの方がいいじゃね」と思う。
最後に
最近、Linuxで作られる組込みシステムばかりが目立つようになっている。それは当然だろう、そこら中からpackageを集めて、切りはりして、あっと言う間に作り上げてしまうんだから。一方で「まずは設計から」って、そんな肩ぐるし事を言っていたら、そりゃ、誰も使おうとはしない。それにフリーのRTOSがあるが、普通は有料お金がかかるし、開発に時間が湯水の如くかかる。
また、世の中にはLinuxとRTOSが同時に動作するOS(VxWorks、RTLinuxなど)が存在する。それを使えば、いい所取りで万全だけど、これも莫大な金が必要となる。RTOSに金がかかるのは防ぎようがない、そりゃ、処理、動作を保証しないといけないから。
システム、製品の品質(魅力?)には機能性、信頼性、使用性、効率性、保守性、移植性がある。開発してきたシステムのほとんどが信頼性重視であったが、どれを重視しようがかまわない。故障ばかりしていても、安価であればそれもひとつの品質(魅力)となる。つまり、組込みシステムにlinuxを使い、何かの魅力が出せれば何も問題がない。
ここで、RTOSを広めたいなんてのは思ってはいない、ただただ、機能毎に分割して、相互に連絡をとりながら処理をしていくようなしくみを広めたいと思っている。