組込み機器の制御にStandard Commands for Programmable Instruments(SCPI)を用いる事を考える

あらまし

組込み機器を設計すると、小さな規模の装置でも数十から数百を超える操作が簡単に生まれてしまいます。設計実装した機器が確かに意図したとおりに機能しているのかを確認しようと考えた場合、それら全ての操作に対して考え得る全ての組み合わせで実行しない限り、予期しない動作が生まれない保証はありません。特に機器側に何らかの状態を持つような設計が含まれる場合、人間が操作したのでは到底網羅出来ない数の組み合わせが存在する事になります。

さて、エンジニアとしては自分の設計と実装が期待通りの動作をしているのか確認してから枕を高くして眠りたいところですが、その操作インターフェースが独自コマンド体系になっていると色々な弊害が出てきます。例えば、「そもそも操作を自動化できるコマンド体系になっていない」、「独自の概念に基づく操作が並べられており第三者の理解が難しい」、「機器側の状態にコマンドの実行結果が依存しすぎる」など。ついつい作ってしまう独自コマンド体系によって自動化が困難な状況も自ら作り出してしまう事になります。おろろ・・・これでは枕を高くして眠れない・・・。

ということで、「何か代替案はないかなぁ」と調べ始めたのが今日のお話。

Standard Commands for Programmable Instruments(SCPI)

Standard Commands for Programmable Instruments(SCPI)とは、プログラマブルな計測器をコマンドで操作するために作られた規格です。独自の操作体系で作られた数多くの機器を制御するのが難しかった背景から策定されたもので

1. 同種の二つの計測器が存在した場合、同一の制御方法を持つ（垂直互換性）
2. 二つの測定器では計測手法が何であるのかに依らず同じ計測が可能である（水平互換性）
3. 同じ機能を持つ二つの計測器では同じコマンドで操作できる（機能互換性）

という３つのコンセプトがベースになっています。

実際に規格に書かれたプログラマブル計測器のモデルを見ると計測器のみならず、様々な組込み機器でも再利用可能に思えてきました。上記のモデルで言うと、Measurement Functionは入力系統、メモリは文字通り、Signal Generationは出力系統です。要するに入力された信号がメモリに入り、計算されて出力されるというコンピュータシステムそのものなのです。

例えば、オーディオを処理するような装置を仮に作った場合、上記モデルで言うところの上段は入力(録音)系統、下段は出力(再生)系統になるわけです。実際、規格文書の例は車台ダイナモメータのモデルが示されたおり、ちょっとやってみたくなる素材としても面白い内容になっています。どのような装置であっても、広義の意味で測定器と言えるのでその応用の範囲は広そうです。

という事で、何か作ってみたくなる素材のお話しでした。

http://www.ivifoundation.org/docs/scpi-99.pdf

KiCadのコンポーネントエディタにまつわるティップス

先日からKiCad (Version: 4.0.1-stable release build)への移行を始めました。
EAGLEからKiCadへ移行する方への参考になればと、「おぉ！これは！」と思ったポイントをまとめてみましたので御紹介します。

コンポーネントに対するドキュメント

私の場合、後から設計情報を見た時に何を根拠に設計したのか明らかにする意味で、採用した部品のデータシートを必ずリポジトリに入れることにしています。

KiCadでは、コンポーネントエディタで「ドキュメントファイル名」を指定しておく事で、回路図から直接ドキュメントを開く事ができるようになります。

部品点数が多くなってくると、ドキュメントを開くのも億劫になってしまいますので、この手のちょっと便利な機能は、膨大な時間を節約する事に繋がります。これは便利。

残念な外観のコンポーネント

コンポーネントを作り始めてから数日後、何か違和感あるよなぁと思いました。

最初、それが何かわからなかったのですが、よくよく他人の回路図と比べるとコンポーネントの外観がとても残念です。

調べてみると、コンポーネントの枠に対して背景色で塗りつぶすという選択がある事に気づきました。回路図上でコンポーネントが格段に見やすくなりますのでお勧め。

3Dシェイプのデータパス

これはどちらかというと「どうやってやるんだ？」な話。

コンポーネントに対して3Dモデルを割り当てられるのですが、どうしても固有環境のパスが入ってしまいます。これでは、他の環境でチェックアウトして作業・・・なんて芸当が出来ません。

実際には、ダイアログが自動的に挿入するパスから手動でKiCadが内部で持つ環境変数名を入れてやれば良い事がわかりました。

コンポーネントに対する説明

KiCadでは、コンポーネントに対する説明を加えておく事で、部品選択ダイアログで絞り込み検索が可能です。既存ライブラリなどの説明を見ていると、「あぁ、これだと検索にかからないよなぁ。」なんて書き方があります。自前のライブラリを作る場合、データシートに書かれたDescriptionからテキストをコピーするのがお勧めです。

コンポーネントのピン編集作業

コンポーネントエディタでピンを追加する場合、ピンを置きたい位置にマウスをクリックし、出現したダイアログに情報を入力・・・というのが通常のやり方です。が、そんな事を何度も繰り返していると、さすがに「これは不便なんじゃないか？」と疑問を感じ始めます。

KiCadの場合、キーボードの操作だけでピンを追加できるように操作系が工夫されています。

KiCadティップスコーナー

Twitter上で「今朝のKiCadティップスコーナー」を更新中ですのであわせて御覧下さい。

KiCadを使い始める

ちょっと思い立ってKiCadを使い始める事にしました。

もうだいぶ長い間EAGLEを使っていたので、乗り換えるにあたってツールが前提としているワークフローの違いについても見ておかなければなりません。KiCadのウェブページを見るとGetting Startedのページに御丁寧に説明が書いてありましたの紹介します。

EAGLEの場合、ライブラリファイルの中にシンボルとフットプリントが一緒に管理されていました。
世界中で広く使われている一般的な電気系CADの場合、シンボルとフットプリントが一緒に管理される事は滅多になく、通常は別々の管理になっています。EAGLEに慣れた人がKiCadだけを見ると特異なものに見えてしまうかもしれませんが、実際にはEAGLEの方が特別なケースと言えるでしょう。


ということで、チマチマとワークフローを辿って操作を学習していく事にします。
何か実際に設計するための題材が欲しいなぁ、何にしようかなぁ。

「製品開発におけるソフトウェアの品質保証」と題してプレゼンテーションを実施させて頂きました

CQ出版社Interface 2015年11月号「レベルアップ！フリーのCプログラミング道具箱」の第２章「シンプル・便利・基本的！フリー・ソフトで高品質プログラミング」にも関連する内容で、「製品開発におけるソフトウェアの品質保証」と題して、酔漢さんの主催するワークショップでプレゼンテーションを実施させて頂きました。

近年、幾つかのプロジェクトを見ていて感じている事ですが、製品品質を確保する上で本質的に欠かせない内容に触れる事なく、何か別の（形式上の）作業に振り回されているうちに、肝心の品質保証が不十分になってしまうケースがあるようです。今回のプレゼンテーションでは、現代的な製品に欠かす事のできないソフトウェアの品質保証について、実際に現場で起きた事をざっくりデフォルメして説明させて頂きました。

先日のInterfaceの記事でも少し触れましたが、設計がどうして必要なのか、実装は何に対するものなのか、実装の正しさは何によって証明すべきものなのか、など、これらの関係について明確な思想を持っておく事が非常に重要です。

しかし、実際に現場で色々な作業成果物を見てみると、何とも残念な結果になっている事が少なくありません。それらがどのような背景で起きるのかについて触れるとともに、どのようなアプローチが実際に現場で有効であるのかについて、ヒントを示すような内容としました。

例えば、製品の見た目や大きさで設計対象物の大きさを判断しない事、など、少し考えてみれば当たり前の事ですが、混乱が繰り返し起こるような現場では有用な示唆になると思います。この「物事は見た目ほど単純ではない」というのは、色々な場面で使えます。

資料は、後日酔漢さんのウェブページで公開予定ですのでお楽しみに。
https://signalbottom.wordpress.com/

2015年12月16日追記：(リンク)
https://signalbottom.wordpress.com/2015/12/13/2015%E5%B9%B411%E6%9C%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97%E3%81%BE%E3%81%A8%E3%82%81/ に公開頂きました。

2015年12月29日追記：(要約)
製品の品質を担保するための活動は、その製品の企画構想、仕様、設計、実装、内部検証、外部検証、文章化、クロージングなど、製品開発の全てのフェーズに渡るのが通例である。しかしながら、実際の開発現場では、各フェーズの関連性を見い出せず、結果的に品質保証の視点が完成したシステムに対する外から見た挙動を評価する事に終始するようなケースもみられる。このような背景を踏まえた上で、本発表ではシステムの内部品質にフォーカスし、特定の指標を用いた設計や実装の品質保証について概略を述べる。

「ちょっとすごいロガー(NinjaScan-Light) スイッチサイエンス版」を「ちょっとへぼいケース」に入れる話

スイッチサイエンスさんで人気沸騰中のちょっとすごいロガー(NinjaScan-Light) スイッチサイエンス版を購入しました。基板好きにはこの凝縮感がたまりません。

早速ですが、気軽に外に持ち出せるようにと何らかのケースに入れる事にしました。部屋の中を見回して色々な小物ケースを探したのですが、しっくりはまったのはフリスクのケース。

ただ、ケースの中で基板がガタガタ動いてしまってはセンサの値に影響を与えます。かといって、両面テープでがっちり固定する気にもなれなかったので、今回はスコッチが出しているジェル状の接着物を使用する事にしました。

残念ながら耐熱温度仕様などは書かれていません。もしかしたら後でまずいことになるかもしれませんので、同じようにやってみようという方は自己責任でお願いします。

当初はu-bloxのモジュールが上を向く形で実装するつもりでしたが、この面を接着面として使った方が具合が良いと判断。u-bloxのモジュールに接着物を貼り付けてフリスクケースに固定します。

これでばっちりケースに入りました。CON1がケースの蓋に当たるので、蓋の肉厚を調整して対処します。

USBのコネクタを外に出すために穴もあけておいて下さい。
私の場合・・・もっと綺麗にやり直したい。バリとか取っておかないと後で色々困ります・・・俺。

システムにおけるレイテンシーとスループットの話題

レイテンシーとは、あるシステムに何らかの入力を与え、それに対応する何らかの出力が出てくるまでの時間（遅延量）を指します。例えば、ある処理の実行を指令してから実際の結果が得られるまでに250ミリ秒かかったとすると、それは250ミリ秒のレイテンシーを持つシステムという事になります。それではここで、この時のスループットについて考えてみましょう。

以下の図は、横軸が時間で、250ミリ秒かけてある処理を4回実行した時の様子を示したものです。

上記の図に示した「ある処理」で取り扱われるデータが32MBだったと仮定します。このシステムの場合、「ある処理」を直列に実行しており、スループット[MB/s]は(32[MB] x 4) / 1[s] = 128[MB/s]となります。

さて、ハードウェアであってもソフトウェアであっても、最初に設計実装した処理のスループットが想定を下回り、結果的に何らかの対策が必要になる場合があります。必要なスループットに達していない場合、所望の処理を並列に実行する事でスループットを改善しますが、これは一体どのようなメカニズムによるものなのでしょうか？・・・というのが今日のお話。

さっそく先ほど1系統で行っていた処理を複数系統に拡張する事を考えてみます。下の図は、先ほどの処理を5並列で実行するようにしたものです。

上記の場合、スループット[MB/s] = ((32[MB] x 4 x 1) + (32[MB] x 3 x 4)) / 1[s] = 512[MB/s]となり、先ほどの128[MB/s]に対して大幅にスループットが向上している事がわかります。

直列的に処理する事になれた人が時間軸だけに注目してこの例を考えた場合、「250ミリ秒かかる処理なのに、どうして50ミリ秒毎に結果が出せるの？」と不思議に思うかもしれませんが、図示してみれば特別驚くべき事もありません。

このように、同じ処理を実行可能な系統を複数用意して並列動作させるだけで、システム全体のスループットを大幅に向上可能である事がわかります。上記の方法で重要な点のひとつは、系統毎の処理方法と処理時間は、系統を並列にする前の直列動作時と何ら変わりが無いという点です。

ここで、その他の方法として、単一の「ある処理」を複数に分割して、複数の系統で同時に並列処理する事も考えてみましょう。下記は、緑の部分は５つに分割して処理した結果、時間軸上では1/5の時間で済むことを示しています。

上記の場合、250ミリ秒かかる「ある処理」を5分割にして50ミリ秒ほどで完了する細かな処理に分割し、それら分割した処理を複数の系統で同時に処理する事で、レイテンシー50ミリ秒、計算系統5系統で「ある処理」を50ミリ秒で片づける事に設計する事になります。但し、並列化する前と後では、処理の実装が異なる他、並列化に要する新たなオーバーヘッドが発生する事があります。



システムにおけるレイテンシーとスループットを考える場合、何を並列化するのか、どのように並列化するのか、その並列化においてのスケーラビリティはどのようなものか、など様々な視点で設計について考察しなければなりません。

この話の続きには、同期と非同期や多段接続に関する話題、バッファリングに関する考察が必要ですが、それはまたの機会にと思います。

CQ出版社Interface 2015年11月号に「レベルアップ！フリーのCプログラミング道具箱」と題して記事を書きました

CQ出版社Interface 2015年11月号に「レベルアップ！フリーのCプログラミング道具箱」と題して、高品質ソフトウェア設計実装を目指す活動に関する記事を書きました。

 

http://www.kumikomi.net/interface/contents/201511.php 

http://www.kumikomi.net/interface/sample/201511/if11_028.pdf

実際の製品開発現場では、割り当てられた期間の中でどれだけ品質の高いものを素早く実現できるのかが鍵になってきます。現代の製品ではソフトウェアの設計実装活動の占める割合は高くなる一方ですが、十分に余裕のある形で品質を担保するための活動が出来ない事が少なからずあるようです。

また、現場によってはソフトウェアの設計や実装に関して着目する事が無く、とにかく製品全体を外部からのみ見て評価しようと試みるところもあるようです。しかし、実際に製品は内部の設計実装成果物によって動作しているわけですから、その内部品質について度外視する事は出来ません。
 このような背景から、今回の記事では、ソフトウェアの内部実装品質について現場レベルで活動するための道具を少しだけ紹介する内容としました。不安いっぱいの状態で製品をリリースするのは単なるリスクですし、顧客に迷惑をかける結果になりかねません。であれば、事前に色々な検証を手軽に楽しく行って、安心して製品をリリースする事でエンジニア生活を楽しもう！といった趣旨です。

図1. 設計と実装と内部検証と内部記録の関係

図1は、設計、実装、内部検証、内部記録の関係性を示したものです。設計から実装を行いますが、実装は内部検証とも関連があり、そして内部検証は設計とも関係がある・・・そんな関係性を接触面で表現したものになっています。

小さなマイコンで動作しているような組み込み装置、高性能なCPUで動作している広帯域サーバーなど、装置の規模や性格に依らず、様々な場面で使えるアプローチとしてコンパクトにまとめた記事になっていますので是非ご覧ください。

CQ出版社のウェブショップからも購入可能です。
http://shop.cqpub.co.jp/hanbai/booklist/series/Interface