これは、かつて秦帝国が中華皇帝となった時に起きたことだそうだ。列強各国が争いを繰り返す戦国時代、相手国の戦車や荷車を、自国で使い難くするために、少し車輪と車輪の間隔「轍」を変えていた。このため、他国の戦車等が走りにくく、戦では有利となったが、交易等の障害となった。これが、秦帝国による統一とともに、車輪の間隔、轍が統一され、各国の交易が活発化した。
これは、現在のWTO/TBT協定と共通する、基本的な交易障害における技術的な考え方であろう。
＜JISのWTO/TBTのページ＞http://www.jisc.go.jp/cooperation/wto-tbt.html
現状では、単位については、ＳＩ単位への統合が進んでいる。ＳＩ単位は、２００８年に８版となっていますから、大きな流れは変わりませんが、少しづつ改訂もされています。規格等は、ISOの中で、討議されて、ISO規格として公開されています。日本では、２００１年前後にJIS規格を、国際規格に準拠した形で、改訂が行われています。
回路図は、設計図である。回路図の目的は、相手に提示することで、製作に必要な情報を相手に伝えるための手段なのである。この条件からすれば、従来の回路図の表記では、表記できない内容が項目があるのも事実である。製作に必要な情報を、新JISで表記することが可能かというと、そうはなっていないのも実情である。これは、回路図の必要情報を検討する基準が、基本的に回路設計技術者の範囲を基準に構築されていて、基板設計技術者を対象としていないことにある。
回路設計技術者と基板設計技術者は、ウォータフォールの考え方として、上流側にいる技術者（回路設計技術者）と下流側の技術者（基板設計技術者）の意識が違うことも原因の一つであろうと考えられる。これは、収入面の違いになってあらわれている場合もあり、容易に解決できる状況とはなっていない。
今回の回路図では、回路設計とソフトウェア設計の連携を基準として、各種資料を作成している。
今回、音と光のシンフォニーに使ったECU：Electronic Control Unitは、PIC 12F683のDIP8pinのタイプのICを使っている。
ICは、写真左下にあるマークから反時計回りにピン番号が、１番から順番に割り振られている。ソフトウェア上の設定に関係なく決まっているのは、＋電源[VDD]とGND[VSS]の端子であり、VDDが１番ピン、VSSが８番ピンとなっている。写真では①が、1番ピンでVDDとなり、⑧が８番ピンでVSSとなる。
それ以外のピン番号は、GP0、GP1、GP2、GP3、GP4、GP5で割り当てられているが、ソフトウェアの設定によって異なる機能を有することができる。ハードウェア上のピン番号と内部の値で一致しているのは、GP0～GP5とピン番号となっている。内部の値とピン番号の順番が反対になっているのは、異なる設定になっていることを間違わないようにするためなのだろうか？別に一緒でも良いような気がするのだけど。ま、ここらへんは、IC設計者の自由なので、理由については良くわからない。
IC図記号の明日へ02 ＆ ソフトとハードと図記号と２
最近、使われている、ECU：Electronic Control Unitは、ICのピン数を省略するため、設定によってピンの機能が異なる設定あ可能な構造となっている。PIC12F683の場合、８pinの構造であるが、電源ピンのVSS、VDDを除けば、2個以上の機能を持つことができるICのピンとなっている。各ピンは、GP0、GP1、GP2、GP3、GP4、GP5というコードが割り当てられ、それぞれをどのように機能を割り当てるかが重要となる。
従来、電子CADを使うにあたって、下記のような問題点があった。
＜１＞回路図表記では、プログラムによる機能の変更を記載できない表記方法となっている
＜２＞基板上の部品配置や実装方法についても表記することができない
＜３＞部品の電子的特性および機械的特性が不明である
現在の電子CADでは、＜３＞の電子的特性について、部品の電子的特性をパラメータで設定することで、シミュレーションが可能なように開発されているものが多く、自分でパラメータの設定が可能となっているものもある。ただ、放熱による熱伝導解析といった機械的な特性のシミュレーション機能は、現在の電子CADに搭載されていない。＜２＞の基板設計は、現在の電子CADで可能となり、部品配置および実装方法についても記載できるようになっていることから、基板設計にヒートシンクといった、機械的な熱伝導解析等のシミュレーション機能が追加されることが望ましい。（どっかで、開発してくれないかなぁ・・・）
＜１＞については、新JISの図記号表記によって、回路図上に記載することがある程度は可能である。ここから、回路側のシミュレーションと連動させることが可能となるが、ここまで開発されている電子CADはまだないと思う。（ここらへんもまだまだである）
現在の電子CADにないからと言って、明日の電子CADにないということはない。非常に多くの困難が伴うことは理解できますが、開発は可能な追加機能だと思います。こういった機能の不足を考えると、まだまだ、本当の意味で電子CADというのは、存在していないのかなあというのがあったりします。
「綾乃は、昼寝をしたかった。だから、授業中に昼寝をした」
これは、論理的な文章でしょうか？
答えは、小野田博一さんの「１３歳からの論理ノート」１７ページに掲載されています。
論理的に正しいこととと、倫理的に正しいことは違います。論理的に正しくても、倫理的には間違っていることもあります。また、倫理的に正しくても、論理的に間違っていることもあったりします。さらに言えば、論理的には、正しいか間違いかを、判断すること自体ができないことも多かったりするのです。
さて、使っている方が非常に多く、電子CADが対応していないために、回路図が描けない状況にある代表は、ICであろうと思います。企業さんによっては、新JIS用の部品を自作されていたりして、用意されていますが、なかなか部品を自作していくのが、今の電子CADは面倒で難しいというのが、実情としてあります。
なんで、ICの図記号が変わったです。理由としては、電源の表記方法といった、クロック等の共通部分の表記があります。MIL規格のANDやOR、NOTといった記号には、電源部分の表記が明確ではありませんでした。これは、MIL規格が、論理回路の表記であって、電子回路の二値論理回路素子を表記するだけではなかったためです。電源の表記は、基板設計上で必要となり、電子CADが基板設計へ対応するところから組み込まれうようになったのですが、このため、各電子CADメーカーで独自の表記方法がつかわれることとなりました。
新JISが持つ特徴は、このICの回路図が持つ表記の必要上から生まれたものと考えられます。単に、新JISが嫌いだからという方には、ではどのように表記すれば、ICの回路図と基板設計が連携できるかについて、考えてほしいと思います。また、組み込み技術の進化は、回路図の表記を根本的に変化させてきました。CPLDのようなプログラミング可能な二値論理素子や、プログラムの設定によって、入出力の変化、アナログであるかデジタルであるかさえも変化してしまうような、システムに合わせて設計可能なECU:Electronic Control Unitが開発されていったことにあります。
ハードウェアの構造が、ソフトウェアによって変化してしまうことは、記号表記に柔軟性が必要になるということです。このため、電子CADメーカが回路シミュレーションを製作する場合、IC内に組み込まれる、ソフトウェアの設定に対応しなければならないことを意味します。今のところ、この変化するECUに回路シミュレーションが対応している電子CADは見かけません。このあたりは、今後の電子CADメーカへの課題となるかと思います。
前にも描いてたりしますが、抵抗器の図記号は、IEC60617に合わせて、ギザギザしていた図から、四角い箱のような形へと変わりました。ただ、JIS規格に拘束力は無いので、非準拠だからといって、問題があるわけでもありません。
ただ最近は、表記として、新JISと旧JISが混在する回路図をみかけるようになったのですが、これは問題であるように思います。図記号は会社内および、関係各位との連携は必要かと思います。連携をおこなう場合に、図記号として、どのように描くかは、きちんと取り決めておく必要はあると思います。新旧混合で描くのであれば、何が新JISで、何を旧JISで描くのかは、明確化が必要です。ここらへんを適当にする、というわけにはいかないのではないでしょうか？
ちょっとしたナショナリズムであれば、抵抗器を旧記号で描き、他の記号を新記号で描くというのは、ありかと思います。ある企業さんの回路図は、そんな感じだったりします。（苦笑）
音と光のシンフォニーを、１１月２９日（日）に開催されるポリテクビジョンのモノづくりコーナーで展示および製作体験をおこないます。部品を組み込んで、半田ごてを使って、半田付けをして造り上げます。ただ、プログラミングは、モノづくりコーナーではおこないません。学生が製作した、プログラムで音楽に合わせて、LEDイルミネーションが輝きます。（予定）
ポリテクビジョンのチラシ
さて、どのチームのイルミネーションがあなたの好みでしょうか？
ここんところ光と音のシンフォニーの話が多いのだが、このシステム設計からハードウェアおよびソフトウェア設計の基本は、LabVIEWでおこなっているのである。もともとの発想は、マイク端子を使ったADCの確認と音声データのWAVEファイル出力である。
ソフトウェアの方は、最終的にUSB-6009を使って設計製作した。
今回のテスト用に作成した正弦波による1kHz純音（LR同相信号、LR逆相信号）も、LabVIEWで作成したテストデータだったりします。
LabVIEWは、何かのシステムを設計するときに、モデリングをおこなって課題のチェックおよび解決手段の策定といったところで、重宝しているソフトウェアだったりします。個人的に、コーディングというが苦手というか嫌いだったりするので、今回のシステムも、設計仕様書だけ造って、サンプルソフトのコーディングは私ではなかったりします。
「どうかな？ヴァッツ」
「綺麗な出来だ。ただ、ちゃんとできているかどうかだな」
レッド、グリーン、ブルーの妖精たちに、合わせて作られた服を着せていく。
「呼び出すぜヴァッツ」
宝珠に呪文を刻み終えたレットから声がかかる。
「よし。いいぞ」
宝珠が稼働を始め、レッド、グリーン、ブルーの妖精たちがキラキラと輝きだす。妖精がすべて揃うと、白い色に光輝く。
「どうですか、リィ」
「俺には白く見えるよ。シェラ。ルウは、どう見える」
「うん。ちゃんと白く輝いている。良い感じだよ」
「良かったぁ」
ほっと胸をなでおろすシェラであった。
Recent Comments