(^-^;(^-^; 昔々のＣＭに流れたフレーズです。(^^)bナツカシイというか、良く覚えているなぁ・・・普通に科学計算で使えるようになった電卓が発売された時に流れたＣＭです。
電卓が出現して数十年・・・演算処理は非常に楽になりました。 個人的に、Mathmaticaという数式演算アプリケーションも好きだったりするのですが、最近、身の回りでは使っている人を見かけなくなりました。仕事が変わったこともあって、Mathmatica自体が使えなくなっちゃいましたねぇ。Mathmaticaが持っていた演算処理の性質そのものは、今の関数電卓にも用いられていますので、スティーブン・ウルフラムさんの考えられた数学演算方法そのものが、より一般化されたという方が正しいような気がします。なんだかんだ、良いものは受け入れられるものです。造った人が儲かるとは限りませんが。(^-^;;;
Mathmaticaは演算精度を設計思想の基準として設計された計算ソフトだと考えています。倍精度だのなんだのではなく、関数や変数を記号化することで演算処理そのものの最終演算の精度をあげることがシステムの設計思想となっています。どうしても、演算精度や確かさを要求されるような計算をする場合は、Mathmaticaは便利ですねぇ・・・使えなくなったことは、ちょっと残念。
三角関数は、Sin、Cos、Tanあたりが一般的に使われる形ですが、関数そのものの逆数であるSin^-1、Cos^-1、Tan^-1も良く使われます。
逆関数という考え方は、数値演算の結果があっているかどうかを確認するための手法として、頻繁に出てきます。また、計算精度を確保するためには、出来る限り数値演算記号を含めて、演算処理をおこなっていくことも重要です。
例：πのような無理数や１／３のような循環小数の演算処理をする場合、変数をそのままできる限り変数として確保し、演算記号を含めて計算処理していく手法をとる方が、演算精度をあげることができる。ただ、この方法は、非常に多くのメモリを演算に必要とする欠点があり、組込用の演算処理には向かない。
ただ、組込で数値演算処理の演算精度をあげたい場合、作成した関数をいったん変数確保や演算記号確保の方法で演算処理をおこなってから、関数の入力値と演算結果の処理をデータベース化する方法があります。いわゆる関数表の自作ですね。パターン認識プログラム等の場合、非常に多くの関数を必要とし、関数のデータベースを使うことで、演算精度をあげている方法をとっていたりします。個人的にも、良く使っている手法だったりします。
| Permalink
|
| TrackBack (0)
０の数を数える
log(1)＝０
log(10)＝１
log(100)＝２
log(1000)＝３
対数グラフの場合、０の数を基準として、等間隔に並びます。
log(1)＝0.000
log(2)＝0.301
log(3)＝0.477
log(4)＝0.602
log(5)＝0.699
log(6)＝0.778
log(7)＝0.845
log(8)＝0.903
log(9)＝0.954
log(10)＝1.000
電卓で演算をおこなうと、上記のような計算結果が得られる。
結果から、log(20)からlog(1000)までの計算結果を記載する演習をおこないます。演算結果の記載は、方眼紙上におこないます。
| Permalink
|
| TrackBack (0)
前にも描いたのですが、LabVIEWは、アプリケーションのソフトとして配布することができます。個人的には、LabVIEWプレイヤを配布する形がいいかなと思ってたのですが、英語版だと可能らしいのですが、日本語版のＯＳ上ではLabVIEWプレイヤは稼働しません。どうも日本語版は発売されないようです。また、LabVIEWのベーシックでは、ビルダーが入ってないので、実行ファイルそのものが作成できません。LabVIEWプロフェッショナル開発システムを使うか、別途購入する必要があります。
また、LabVIEWのファイルを起動するためには、ランタイムライブリーが相手のパソコンにインストールされていなければなりません。このため、LabVIEWをランタイムライブライ毎ファイルを配布するには、インストーラソフトを作成する必要があります。相手のパソコンにLab VIEWのランタイムライブラリがインストールされていれば、実行ファイルだけでも良いのですが、LabVIEWの実行ファイルは、ランタイムライブラリがなければエラーになってしまいます。ここらへんは、Visual BASICとかと考え方は同じです。
相手のパソコンで実行した場合は、次のような雰囲気になります。
| Permalink
|
| TrackBack (0)
電気が流れる、電気量が移動すると描いた方がいいのかな？電荷は移動しないと言われたりするので、Ｑ[C]＝Ｉ[A]×ｔ[sec]で定義される場合、1.0[mC]に帯電した電荷が、1.0[μsec]ですべての電荷が移動するような短絡が生じた場合、瞬間的には何アンペアの電流が流れたことになるか？流れた電流を１秒間に積算した場合に何アンペア流れたことになるか？
図のように、電圧の変化と電流の変化でタイミングが異なる場合（つまりは位相が違う場合）、電力量は時間によって変化します。任意の時間における電圧を瞬時電圧、同じ時刻の瞬時電流を描けると、その時点での瞬時電力となります。電圧が5.0[V]あっても、電流が0.0[A]であれば、電力は0.0[W]となります。
信号の変化を追いながら、計算していくとそれぞれの時間で電力がいくらになるかを計算することができます。
ここらへんが、個人的な計算問題の造り方における傾向となります。対策は、各自でたててみてください。
| Permalink
|
| TrackBack (0)
＜前回の記事＞http://sugc.cocolog-nifty.com/labview/2009/05/ecuelectronic-c.html
電子制御ユニット[ECU:Electronic Control Unit]という用語については、まぁ大丈夫そうである。この言葉を広義に解釈するか狭義に解釈するかについては、関わるエンジニアの考え方によって異なるので注意が必要である。
広義でECUを捉えた場合、電子制御システム[Erectoronic Control System]という表現に近くなり、狭義でECUを捉えた場合、マイクロコンピュータによる制御システム[Control System ; Microcomputer]という表現に近くなる。個人的には、広義で捉えた場合の電子制御システム[Erectoronic Control System]としてECUを捉えている。このブログで組込や実装のお話をする場合、ECUの捉え方は広義の意味で統一して考えるように心がけています。（時々、違っちゃったりするかもしれないですけど、ご容赦くださいませ）
つまりは、AND OR NOTのゲートを組み合わせて制御するのも、マイコンにプログラムを組み込んで制御するのも、個人的には同じ扱いとしている。要求される仕様用件やコスト等から、最大限採用範囲を拡大して考えることが、個人的な目標でもある。場合によってはECUすら採用しなくても良いという考え方で、物事を捉えるように努力している。
| Permalink
|
| TrackBack (0)
図学とかの授業も最近は、あまり実施されていないようで、円から正弦波を作図するということもないようである。電子で電気製図そのものがなかったりとか、機械でもカム曲線を描いたりしなくもなっているようですから、なかなか稼働しているモノがどのようになっているかを学生とか若い技術屋さんが、想像することそのものが難しくなっているのが、現状になっているような気がします。
新しい技術屋さんや学生さんは、ほとんど知る機会もなく、知識として教科書に掲載されていても覚えることなく、学生時代を過ごしているようにも思います。必要かどうかで判断すると、知らなくても良い話だったりしますし、感覚的な事柄でもあります。また、センスのいい人は、教えなくても理解してたりします。ここらへんが問題なのですが、きちんと体系だてて確認していくことで、センスそのものを訓練することは可能です。センスのいい人はより鋭く、センスの厳しい人は補えるようになっていければと思います。
| Permalink
|
| TrackBack (0)
技術の分野で、評価基準の策定が徐々に進んでおります。
これは、国際社会の中で、色々と圧力がかかりつつある状況から進んでいる内容でもあるようです。稼働している製品が、人を殺してしまった場合、責任の所在と範囲の明確化が求められます。
設計技術者は、従来は何の資格がなくても、設計技術者と呼ばれていました。では、彼らが設計した製品に欠陥があった場合、設計者の責任範囲はどのように規定されるのでしょうか？会社は、何を持って、彼らに設計者として責任能力ありと判断することになるのでしょうか？
これが、今、世界を覆う安全の嵐であり、日本にも徐々に吹き込んできているのは事実です。ハードウェアであろうが、ソフトウェアであろうが、設計技術者が持つべきスキルの標準化が、様々な形で進められている原因のひとつでもあるようです。
製品を設計した人は、どのような人がどのように設計していたのか？製品をメンテナンスは、どのように実施されていたのか？日常の運用管理は？こういった安全設計の概念から、縛りがかかりつつあるというのが、国際社会の流れともなっているようです。
高コストと引き換えになってしまうため、浸透することには大きな壁があるのも事実ですが、ISOのGuide51(安全側面 JIS Z 8051:2004)が、ISO 12100(機械類の安全 JIS B 9700:2004)となって、稼働し始めているのも事実であります。
| Permalink
|
| TrackBack (0)
個人的には、授業を実施する場合は、講義形式ではなく、ディスカッション形式にする方が好みだったりします。脱線が多くなるのと、授業を受ける時に騒がしくなることから、ディスカッション形式は嫌われますが、脱線は別視点からのアプローチという点ではいいかなとか思っています。
しかしながら、ディスカッションではあっても、私語があってはならないというのはあたりまえです。討議することを前提とし、相手の話を聞くという行為を前提として、学生同士で討論するということであれば、それはそれでいいかなと考えています。
| Permalink
|
| TrackBack (0)
＜PLM:Product Lifecycle Managementの記事＞を前に描いた時の補足です。
個々の部品の寿命を考えていくというのは、非常に重要であったりするのですが、半導体素子や機械部品は、ある程度の部品に関する寿命が数値で計算できます。計算によって予測することが困難な部品の寿命が、ソフトウェアの寿命です。
ソフトウェアの寿命で一番有名な問題が２０００年問題であったろうと思います。ソフトウェアをそんなに長く使うことは想定していなかった・・・というか、現時点では大丈夫だから、誰かが何とかしてくれるんじゃないかな？という甘い期待？の下で、社会的な大問題となったのは事実である。
現在、一応は２０００年問題対応済みということであるが、対応の方法は、ソフト会社や対応したエンジニアによってばらばらであり、１００年以内にまた同じような現象が生じるような対処をしてしまったソフトもかなりあるとの噂もある。ソフトウェアに関わるエンジニアの方々は、実際にどのような対処がなされているかを確認されておく必要があるかと思います。
| Permalink
|
| TrackBack (0)
Recent Comments