携帯電話の端末システムは、ITRONなどのリアルタイムOSで設計されている。様々な機能を実現しつつ基本機能となる電話通信機能を確保していくというのは骨の折れる仕事でも有る。低レベルの処理から高レベルの処理までRTOSの制御下で行われている。PDCでもCDMAでも肝となる部分はハードウェアで構築されている為にこうしたハードウェアの制御をする部分には時間制限のあるリアルタイム制御が必要となるのである。

かつて携帯電話の競走は、待ち受け時間の競争であった。現在でもカタログには記載されているが実際に購入される方がこれを尺度に判断されているとは思えない。最良の待ち受け時間を実現していく為にはタイミングを吟味して必要な部分のみの電源やクロックを提供するように制御してようやく達成されるのである。マイコンで必要となるクロックまでも切断して補助の低速クロックに落としてかつ精度を維持しようとするノウハウなど幾つもの技術がそこには展開されている。

待ち受け処理として軽視しているわけではないが優先順位的にはリアルタイムの性能から低く設定されているのがユーザーインタフェースであるといえるだろう。会社によっては一番優先順位の低いのはウォッチドッグ処理だという会社もあるかもしれない。一番優先順位の低いタスクが規定時間内に応答しているという考え方かもしれない。ところがウォッチドッグの処理自体は規定時間内に処理を必要とするリアルタイムな処理であり制御が渡らない可能性のあるようなシステム設計ではNGなのである。

ウォッチドッグを最優先の処理だとする考え方もある。といっても各タスクとのライブ確認をメッセージングなどで実施した上でウォッチドッグのハードを叩く処理を規定時間内に行うという目的での優先処理として最高の優先度で行いハードとシステムが正しく動作していることを検証するのである。ウォッチドッグの機能はどんなに高い負荷状態でも機能が満たされている限り行わなければならないというのが、その哲学となっている。

タスクの優先順位の話となると所謂優先度の逆転という問題がリアルタイムシステムの設計では定番の課題となって出てくる。低い優先度の処理が何かの資源を確保してしまい、その資源を高い優先度の処理が待つ場合にデッドロックとなってしまうからだ。OSの実装方法としてそうしたことが起こらないように低いタスクの優先度を一時的に引き上げるという処理が必要になるのである。これを優先度の継承と呼ぶ。こうした事が携帯電話の中でも当然行われているのである。

RTOSの機能として元々考慮されたOSもあれば、ユーザーがシステム設計で考慮して対応していくケースもある。あまり高機能なOSにするよりもシンプルな機能で設計して優先度制御を行うほうが性能が出しやすいというのが考えの底流にはあったりもする。低消費電力を実現していくためには当然ステップ数が少ないほうが好ましいわけだがそうした視点は現在の製造メーカーからは失われてしまったようにも見受けられる。誰が設計しても、機能が満たされタイプの冗長なシステムが望まれているようだ。

システム物と呼ばれる特注開発のものであれば、安全設計という観点でそれもよいのかも知れない。しかし資源の限られた量産品でのソフト開発にそれでよいはずは無いが・・・。開発規模の増大が、マクロな視点もミクロな視点も失ってしまい期限のみデッドエンド死守というスタイルになってしまったからなのかも知れない。仕事としての優先度は果たしてそれで会社としての将来を託すことが出来るのだろうか。回収を恐れて、鈍重なソフト開発になっている様は技術者達の感性の低下を引き起こしてしまうのではないか。

「描画処理が遅くてこのユーザーインターフェイス処理から一定時間内にライブ応答が返せないので、ウォッチドッグ障害になっていますが、どうしたら良いのでしょうか」と意味も不明な質問が投げられてきたりする。描画処理中であればその処理からのライブ確認をバイパスするように改造すればよい事だと思うのだがと当然のように思ってしまうのだが、いかがなものか。「どうしたらウォッチドッグ機能を止められますか」という質問に走ってしまうのは火消しの哲学なのだろうか。

遅い描画処理を改善するには、ロジックの改善高速化やコード展開を考慮したコードの書き方に最適化していくということが必要となる。こうした感性は、かつてコンパイラを開発した際に自分自身でCの文法と出来上がるアセンブリイメージの対比が想像出来るようになったりした経緯があり私自身はよく判るのだが最近の人はアセンブラコードを見ない人たちなのでそうした感性も失われているようだ。機械語とはいわないまでもアセンブラを知らずに最適化が出来るとは思えない。間に合わないからクロックを上げてくださいとでもいうのだろうか。

電話機の待ち受けという処理は、実は深くて節電を図る処理でもあると同時にそうした状況かどうかは知らずにいるユーザーが操作をしているケースが多い時間帯でもある。寝てしまうと反応が遅くなるし、寝ようと決めた場合にはクロックダウン制御などのリアルタイムで優先度を高めて実行すべき瞬間がある。だからこうした処理は動的に優先度を制御することが必要なのである。システムの理解が不十分なままにユーザーが拡張していくとタイマー処理などにフックした機能などが悪さをすることも多い。寝ようと決めたら何もしないようにするのがシステムの健康の元だ。

そうだ寝床から、こんな事が気に掛かるからと書き留める必要もないのかも知れない。また明日がある。