相手に伝わるタイムチャートの書き方を例題形式で解説

問題

下記のように、ダウンエッジ型JKフリップフロップ(JKFF)を3つ接続した回路に6個のクロックパルス$x$を入力した際の動作を考える。全てのJKFFの初期状態を$Q_1=0,Q_2=0,Q_3=0$とした時、各クロックパルスにおけるタイムチャートを図示せよ。

背景 (タイムチャートを勉強する理由)

院試では、Dフリップフロップを初めとする順序回路の設計能力を問う問題が多数出題されます。出力1を立てる条件の説明から始まり、状態遷移表の記入、順序回路の作図まで一連の流れがあります。

一方で、作成した順序回路の動作をタイムチャートとして記載する問題についてはあまり問われません。大学によりますが、5年に一度出たら良い方です。

ではなぜ、院試対策向けの本サイトで取り上げるのでしょうか。
理由はシンプルで、それをするだけの価値があるからです。社会(特に大企業)に入ってからよく使います。

社会で使用する理由

自分の作成した仕様が正しいことを上司に説明するときに有用だからです。

社会に入ると、AND、ORなどの細かい演算ロジックを定義するところまではいかなくとも、誰かにコーディングを依頼するための要求仕様書を作成することが多々あります。仕様書には、実現したい機能とそのアルゴリズムの概要を記載する必要があります。大企業になるほど大きなプロジェクトにアサインされる確率が高くなり、自身の実装した機能が自領域のみの動作で閉じることが殆ど無くなります。自身が判断した内容を参照する影響先も踏まえてアルゴリズム設計をする必要があります。

このとき、当然上司チェックは厳しく見られます。不具合が出てからでは遅いためです。「◦◦が××だから影響先の動作含めて問題有りません!」とある程度の説明を口先でしても、実績のない若手の頃に信じてもらえることは殆どありません。

そこで、タイムチャートが役に立ちます。自身が作成した機能の結果を参照するブロックへの信号の流れ(機能配置図)と合わせて、信号の動きを可視化し影響先を特定。それぞれのブロックに対する動作影響をしらみつぶしに検討し、問題が無い結果を提示することが出来れば、晴れてJTCのソフトウェア作成チームの一員になれます。

本記事では、相手にも伝わりやすいタイムチャートの書き方のルールについて、問題演習を通して説明していきます。

解答例

本題に入る前にまずは問題を解いてみます。院試レベルの解答の書き方をしていきます。

まず、過去のJKフリップフロップの解説記事を参照し、JKFF自体の動作内容を思い出します。JKFFは、下記のような真理値表になります。

これにより、下記の決まり事が分かります。

JKフリップフロップの決まり事(復習)
  • 現状態:$Q_n=0$のとき、$J=1$を入力すれば次回周期での状態は$Q_{n+1}=1$になる
  • 現状態:$Q_n=1$のとき、$K=1$を入力すれば次回周期での状態は$Q_{n+1}=0$になる。

上記を前提にタイムチャートを考えてみましょう。JKFF1,2,3毎に下記の特徴があります。

問題で与えられた3つのJKFF回路の特徴
  1. JKFF1:$\bar{Q_3}$がJに入力されているため、$Q_3=0$のとき、次回周期で$Q_1=1$になる。常時K=1が入力されているため、$Q_1$が成立した次回周期で$Q_1=0$になる。
  2. JKFF2:$J,K$に$Q_1$が入力されているため、$Q_1=1$が成立した次回周期で、$Q_2$の値は反転する。
  3. JKFF3:$\bar{Q_3}$がJに入力されているため、$Q_3=0$のとき、次回周期で$Q_1=1$になる。常時K=1が入力されているため、$Q_1$が成立した次回周期で$Q_1=0$になる。

これを念頭に置くと、下記のようなタイムチャートになります。ダウンエッジ型のため、クロック$x$が取り下がった時に状態の更新を行いますが、これだけだと分かりづらいです。クロックの取り下がりに依らず、今、上記の条件を適用した時、各JKFFの状態はどのようになるのかを示した値を、補足情報($Q_i$入力部)として記載しました。

院試では上記の内容でも得点できますが、どうして上図のようになるのか、タイムチャートの画像自体を見ていてもぱっと見で分かりません。前述した特徴を読み返し、冒頭で提示した回路と見比べて、ようやく整合性が取れる・・・。という有様です。この状態で忙しい上司の元に持っていったら、おそらく怒られます。

そこで、次の章からは分かりやすいタイムチャートの書き方を紹介していきます。

タイムチャートの書き方のルール

院試ではここまで求められませんが、下記のことを守ると相手から見て非常に分かりやすくなります。

タイムチャートの書き方
  • 信号が変化するタイミングで縦線を引き、同じ時間で変化している他の信号を明確にする。
  • 波形と波形の間に矢印を追記し、信号の入出力関係を明確にする
  • 定義元の信号は上に、参照側の信号は紙面下に書く
  • 複数の信号である小機能を実現している際は、グループ化する

それぞれの項目を、下記で解説していきます。

信号が変化するタイミングで縦線を引く

補助線的な意味を持ちます。専門書でも当たり前のように記載していることが多いですが、わざわざ明文化していることは少ないので説明します。

先に提示したタイムチャートですが、6Step分記載しているだけあって、各信号が忙しく立ち上がったり下がったりしています。紙面に限りがあると、煩雑な波形になりがちです。

このとき、特に重要な部分について、縦に点線を引くことでその部分が強調できます。下記画像の青枠で囲った部分がそうです。また、同じタイミングで変化する信号が分かりやすくなり、相手にとって見やすくなります。これは、院試でも是非記載したいところです。

波形と波形の間に矢印を追記し、信号の入出力関係を明確にする

ある信号が変化したとき、トリガとなった大元の信号を明示する手段として有用です。本問では、例えば下記の動作が該当します。

  • JKFF2(状態$Q_2$)は、JKFF1(状態$Q_1$)の出力を参照する。
  • JKFF2(状態$Q_2$)は、JKFF1およびJKFF2出力が両方1ならば、1が立つ。

上記の動作は、本問を解くうえでカギになる振る舞いですが、元々の解答内容だとそれが明示されていません。

結局、JKFF2の内部状態は、JKFF1の出力であることが分かるように、$Q_1$から$Q_2$へ矢印を追記した方が分かりやすいです。JKFF3の内部状態の場合は、JKFF1と2の出力を参照していることが分かるよう、二つから矢印を伸ばす書き方にする方が分かりやすいです。

定義元の信号は上に、参照側の信号は紙面下に書く

人間は、資料を読むとき、上から下へ目が流れます。そのため、時系列を説明するタイムチャートも上から下に信号の流れを書いた方が分かりやすいです。解答例もそのような記載にしています。

一方で、フィードバック制御のような、指令値と実動作値を比較して目標値を決定する制御構造の場合、実動作値に相当する信号は下から上へ流れることが多いです。本問では、$Q_1$が$Q_3$の出力を参照している部分が該当します。見せ方に異論のある方は居るかもしれませんが、筆者としてはこれで良いと考えています。下から上に信号が流れている特徴から、フィードバック値であることが感覚的に伝わるからです。

複数の信号を用いて小機能を実現している際は、グループ化する

白黒の仕様書だと限界がありますが、カラーが使えるパワポだと使えるテクニックです。仕様書の目的に依りますが、本問を仮に、JKFF3の内部状態に基づいてXX動作をするシステムと想定しましょう。このような時、JKFF1と2は中間変数の役割を取り、JKFF3の動作を助けるための存在になります。

よって、JKFF1と2は中間変数グループ、JKFF3は最終判断値として各波形をグルーピングしてみましょう。

カラーだと特に分かりやすくなります。

白黒の仕様書だったとしても、中括弧{}でまとめておく書き方にすると分かりやすくなります。

結局

上記で説明した内容を全てまとめると、下記のような見せ方になります。最初に比べると見やすくなったと思います。色が多くなって、どれに注目すれば良いのか分からなくなる時がありますので、3色程度にまとめておくと良いです。また、クロックが立ち下がった時に入力が変わることは共通ですので、クロックからの矢印は省略しても私は問題ないと考えています。

※Q1に入力するK1=1が省略されているため、がQ1:0⇒1になるトリガが本タイムチャート上だと分かりにくくなっています。必要に応じてK1の波形も追記しても良いです。

タイムチャートの欠点

冒頭ではタイムチャートを作成する意義(利点)について詳しく語りましたが、ここでは欠点(2点)も話そうと思います。

作成に時間がかかる

昨今、海外との技術開発競争が激しさを増しています。日本製品の品質は、海外と比較して良いものが多いと今でも感じますが、開発に時間がかかる欠点があります。

最近は、アジャイル開発など言われていますが、品質優先のJTCからするとどこ吹く風です。事前検討の重さは変わりませんし、不具合が発生した場合は再発防止検討、横展開に時間がかかります。筆者の属している業界も同じです。(正直この部分は、失敗を袋叩きにする管理職やメディアにもっと寛容になって欲しいところですが。)

タイムチャートは確かに便利で、担当者の事前検討レベルでも思考の整理に使えます。しかし、他に優先する業務がある中で、書くことが目的になってしまいがちな所に注意しましょう。筆者は、典型動作パターン、過去に不具合が発生したパターンなど含め、5通り程度の作成にしています。

海外メーカーに対しては使えない

これは筆者の経験によります。他業種ではそんなこと無いかもしれませんが、傾向として存在するよ。というレベルで聞いて下さい。

欧米企業に対し要求仕様書を出すときは、タイムチャートではなく文章の比重をより高めて要求を出した方が良いです。上記の国の方々は、日本人より文章で厳密性を求める傾向が強いです。タイムチャートは動作のイメージを伝えやすい説明方法ですが、厳密性には欠けています。細かい文言が抜けていても、意図が伝わればうまく仕様作成をしてくれる日系企業とは訳が違います。後から不具合が発生し、言った。言ってない。なるトラブル話になった時のためにも、要求は文言で細かく残すことを強く推奨します。(日系企業に対しても当たり前ですが)

最後に

社会に出ると、自分で仕様設計するだけでなく、他の人が書いた仕様書を読むことも非常に多いです。動作を理解できたか確認する意味でもタイムチャートを使います。

研究活動においても同じで、前任の先輩方が書いたコードを読むこともザラにあります。このような背景から、院試でも問う機会を増やした方が本当は良いと筆者は考えています。

こういった資料の見せ方の話をすると、中身が無い!とご指摘される方も居ますが、技術に関しても勿論聞かれます。検討内容を早く上司に理解してもらう手段として分かりやすい資料は存在し、その後の技術議論はセットで付いてきますので、忘れないようにしましょう。

他、こんな見せ方したらもっと分かりやすくなるよ。という知識をお持ちの方がいらっしゃいましたら、教えてください。ではでは~

タイトルとURLをコピーしました