組込みプレス Vol.5
が発行された。この号で是非読んでいただきたいのは「文系エンジニアのためのハードウェア講座－電子回路を読む－」だ。この記事、決して文系エンジニアのためだけではなく、理系の組込みソフトウェアエンジニアにもじっくり読んでみるとよい。
おそらく組込みソフトエンジニアでも回路図を読む機会のないソフトウェアエンジニアは「自分には関係ないや」と思うかもしれないが、それはこの記事の見方を少し変えてみれば違った発見があるはずだ。
その違った発見について書く前に、自分の電子回路との接点について振り返ってみたい。
入社5年目くらいのことだと思う。組込みソフトウェアエンジニアとしてアプリケーションソフトを書き続ける日々が続いた後、CPU周りの電気回路の回路図を書く機会があった。電気系のCADの導入が始まったばかりで採用が決まったCPUのデータがCADに登録されておらず、CPUのデータブックを見ながらピン番号と信号名を入力してくれと電気系の技術者の頼まれたのだ。
電気系CADの使い方を覚え、ピン番号や信号名を入れていくうちにだんだん回路図を書くのがおもしろくなってきた。すでに登録してある部品は部品番号を入れるとその部品の回路がCADの画面にパッと表れる。そして、使用する部品をあらかた画面上に表示させておいて、信号線をつないでいくという作業はとても楽しい。
ちなみに、このときから10年以上たって、UMLツールでモデリングするときのこの電気系の回路図を書いていたときと同じようなおもしろさを感じた。
ただ、初めて電気回路の作図に挑戦したとき実際に書けたのはCPUとROM、RAM、拡張ポート、SCIの石などとの接続だけで、電源周りやアンプなどの回路については書けなかった。
「文系エンジニアのためのハードウェア講座－電子回路を読む－」を読んで、組込みソフトエンジニアとしてのキャリア20年間でなんとなくデジタル回路を書く電気屋さんが普段やっていることで「なんでそうなっているのか分からなかった」ことや、「そんな方法もあったのか」といったことがいろいろ解き明かされた。
たとえば、スイッチ入力で起こるチャタリングはコンデンサでもある程度押さえられるということ。
また、通常のオペアンプは電源電圧まで振幅を振ることができないが、Rail to Rail のオペアンプは電源電圧近くまで使えること。（Rail to Rail ということばを電気屋さんがよく使っていたが、何のことだか初めて分かった）
プリントP板上でICの近くに必ず配置されている青い小さなパスコンと呼ばれるコンデンサ、このコンデンサはデジタルICの出力パルスが切り替わる瞬間に発生するスイッチングノイズを押さえるためにICと近くの電源とグランド間に設置し、ICが電流を流したときにこのコンデンサにたまっていた電気を放電して供給することで対応していたということなどなど。
この記事には、デジタル電気回路の実践的設計に関するノウハウがたくさん書かれている。そういう意味では、電気屋さんが基礎をおさらいするときにも役立つだろう。
組込みソフトエンジニアがこの記事を熟読して、渡された回路図の間違いやこう直したほうがよいという点を指摘できるとかっこいいかもしれない。
さて、組込みソフトエンジニアでも回路図を読む機会のない、読む必要がないと考えるソフトウェアエンジニアが、「文系エンジニアのためのハードウェア講座－電子回路を読む－」の記事をどう読んだらよいのかについて考えたい。
実は、デジタル回路を設計するアプローチについてよく考えてみると、巨大化した組込みソフトウェアの海で喘いでいる組込みソフトエンジニアの救いの船が見えてくるのだ。
--- (a) --- デジタル回路を設計する電気系エンジニアのアプローチ
デジタル回路を設計する電気系のエンジニアはまず、電気回路の基礎（電源やトランジスタの仕組みなどなど）を学んだのち、自分たちが使う分野の部品についての調べる。
電気部品は自分で作るのではなく、市場に供給されている部品から必要なものを選ぶ。部品にはデータシートが付いていて、その部品の仕様、実装するときの例、入力や出力の Max値、Min値、Typical値などが書いてある。
電気系のエンジニアはこのデータブックに書いてある情報をよく読んで、必要な部品を選別し、目的の回路を組み上げていく。場合によっては、既存製品のある機能をつかさどる部分の回路をそっくりそのままコピーして使うこともよくある。でも、前の製品に使われた回路の設計思想をよく考えずにコピーしたりすると、うまく動かなかったり、最悪の場合回路が壊れたりするので、中身の構造を理解しないで既存の回路図をコピーするような新人がいると先輩は「データシートを見て、なぜそのような回路構成になっているのかよく考えて使え」と怒る。
このような電気系のエンジニアが回路図を作るアプローチと組込みソフトエンジニアのアプローチの違うはなんだろうか。それは“部品”の存在だ。デジタル回路の世界では自分ではない他人が作った“部品”が存在しており、これらの部品にはデータシートがあり、制限事項が書かれており、品質が保証されている。ごくまれに不良品やデータシートには書かれていない制限があったりするが、データシートを読み込んでいれば問題が起こる確率は非常に低い。
そして部品を組み合わせて目的の機能を満たす回路を設計する。同じ部品を使っているとその部品を使うノウハウがたまってくる。
たとえば、同じような部品を使っていると「ブラシ付きのDCモータが回転するときは整流子とブラシの間で火花が発生し、ノイズを誘発するので、モータの端子間に0.001μF程度のコンデンサを接続し、ノイズが外部に出るのを防ぐとよい」といったノウハウだ。
--- (a)'---
ある意味、組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える。しかし、融通が利かないのは流通する部品の数が少ないときであって、いろいらな種類の部品が入手可能な状況でそれらの部品のインターフェース仕様が事前に分かっていれば、それほど不自由はない。
だから、この話をソフトウェアの世界に置き換えると 21世紀の巨大化した組込みソフトウェアの世界では、ソフトウェアもハードウェアの“部品”に相当するソフトウェア資産（部品）があると有利なことがわかる。
(a)から(a)'までの部分を、ハードウェア部品から再利用可能なソフトウェア資産に置き換えてみよう。
--- (b) --- 巨大化した組込みソフトウェアの設計アプローチ
組込みソフトエンジニアはまず、組込みソフトに関する基礎（プログラミング言語や、割り込み、OS、ドライバの作り方）を学んだのち、自分たちが使う分野のあらかじめ用意されたソフトウェア再利用資産（部品）について調べる。
ソフトウェア部品は自分で作るのではなく、すでに用意されている部品から必要なものを選ぶ。ソフトウェア部品にはデータシートが付いていて、そのソフトウェア部品の仕様、インターフェース仕様、実装するときのパターンの例、制限事項などがなどが書いてある。
組込みソフトエンジニアはこのデータブックに書いてある情報をよく読んで、必要なソフトウェア部品を選別し、目的の機能・性能を満たすためのモデルを組み上げていく。場合によっては、既存製品のある機 能をつかさどる部分のモデルをそっくりそのまま、コピーして使うこともある。でも、前の製品に使われたモデルの設計思想をよく考えずにコピーしたりする と、うまく動かなかったり、最悪の場合機能や性能を満たすことができなくなるので、モデルの設計思想を理解しないで既存のモデルをコピーするような新人がいると先輩は「ソフトウェア部品のデータシー トを見て、なぜそのようなモデル構成になっているのかよく考えて使え」と怒る。
ソフトウェア部品は自分ではない他人が作った“部品”であり、これらの部品にはデータシートがあり、制限事項が書かれており、品質が保証されている。ご くまれにソフトウェア部品にはバグが混入していたりするが、データシートを読み込んでいれば問題が起こる確率は非常に低い。
そしてソフトウェア部品を組み合わせて目的の機能を満たすモデルを設計する。同じようなモデルやパターンを使っているとそのソフトウェア部品を使うノウハウがたまってくる。
--- (b)'---
しかし、(b) には (a) とは違った難しいところがある。まず、ソフトウェア部品は多くの場合他人が作ったものではないし、インターフェース仕様や制限事項が書かれたデータシートに相当するドキュメントがあることは少ない。品質が保証されているかどうかも分からないし、問題が発生してもバグの修正を保証してはくれない。バグを修正するのは自分だったりする。
また、ソフトウェアを部品化できたとしても実際には、RTOSなどを使いひとつのCPUで疑似的に並列で動くだけなので、他のソフトウェア部品から影響を受けてしまう。メモリリークなどが発生するとソフトウェア部品としての独立性を高めてあったとしても動けなくなってしまうこともあるだろう。
また、組込みソフトのソフトウェア部品はCPUパフォーマンスやメモリ資源のことを何も考えずに設計し、つなぎ合わせていくと制限をクリアできずに破綻してしまうことがある。
だから、ソフトウェア部品を組み合わせて配置しても制限をクリアできるような、フレームワークやアーキテクチャの設計ができていないといけない。また、このようなフレームワークやアーキテクチャは、製品や製品群によってそれぞれ異なるので一般的なものは存在しない。
だから、再利用可能なソフトウェア資産を作ることができたとしてもハードウェア部品を組み合わせるように簡単にはいかない。
でも、巨大化した組込みソフトウェアを効率よく開発できるようにするには、このようなハードウェア部品を組み合わせて目的を達成するアプローチを見習わなければいけない。
そうすれば、ソフトウェア資産を使うノウハウがたまり、組込みソフトウェアもどの資産をどうやって使えば効率的に開発できるのかわかるようになる。そのドメインに特化したデザインパターンが構築され、そのコンセプトがプロジェクトや組織の中で継承されていくということだ。
「文系エンジニアのためのハードウェア講座－電子回路を読む－」を読みながら思い浮かんだのは、デジタル回路設計ののアプローチは、組込みソフトエンジニアの問題を解決するのに役に立つということだった。
ところで、デジタル回路の世界では FGPAなどのプログラマブルなロジックデバイスがよく使われるようになってきた。このようなプログラマブルロジックデバイスはCライクな高級言語を使って動作を記述することもできる。ということは、これまで部品を組み合わせてデジタル回路を作ってきたハードウェアエンジニアが我々の“何でもあり”の世界に入ってきたということになる。
ハードウェアエンジニアは（わざわざ苦労しに）組込みソフトの世界入ってこようとしており、組込みソフトエンジニアはハードウェア設計のアプローチを学ぼうとする。
隣の芝は青いということか・・・
0 件のコメント:
コメントを投稿