きれいに制御されている

Rover MEMSからのデータの読み出し,ちょこちょこと作り込みの甘い部分はあるものの,データは収集できるようになったので,今日の遠出の往復の際のデータを記録し,手作業で視覚化してみた。

これは豊田から名古屋へ移動した際のデータの抜粋。

灰色の幅ひろいデータは酸素濃度センサ値。数値で見たときはかなりばらついているんじゃないかと思ったが,グラフ化してみたらきれいに一定幅に収まっている。青はエンジン回転数,橙色は蓄電池電圧。一箇所,異常値(20V)がある。定電圧装置が故障しかかっているのかなと思ったが,その瞬間のエンジン回転数は863rpmなので,発電電圧がそれほど上がっているとも思えない。コイルタイムなるものも記録をとったが,みると,蓄電池電圧の上下に反比例して変動している。MEMSの解説文書によれば,インジェクタ方式の制御ではエンジン回転数とバッテリ電圧に応じて点火装置の通電時間を制御しているとのことなので,このことなのだろう。但し,その文書では3.0から3.5ミリ秒の範囲で制御しているとのことであったが,手元のデータでは4.58から6.17ミリ秒となっている。謎。

ちなみにエンジンルームでのコネクタと電線はこんな処理。

車内側は基盤むき出しです。

ひっかけて短絡しないようエポキシ樹脂で適当にかばってあります。

ECUデータ読み出しその後

手が空いたときにちょこちょこと進めてきたRover Mini 1.3i のECUからどデータ読み出しプログラム,一段落しました。macOSで動かす IoT アプリを関数プログラミング言語Haskellで作るというかわった取り組みです。

これまでの経緯

もともとは,自分のMini 1.3i で出ている不具合の原因究明の参考情報をとりたいがためにはじめました。不具合は,具体的に はアイドリング中にエンジン停止する不具合が時々発生している他,アクセルを踏み込むと,特に上り坂で1800rps付近でエンジンが瞬停(?ノッキング?)するような現象が雨の日や標高の高い山間地でよく発生するような状況です。

  • 下記のCollin Bourassa氏のページで掲載されていた情報をもとに,自分のMini 1.3iに搭載されているECU接続用のUSB-シリアル変換ケーブルを作成した。変換チップ付きUSBケーブルは電子工作ではおなじみ秋月から購入し,自分で電線をはんだ付け。またECU側からの信号線はコネクタは通販で大垣の某事務用品店から購入,電線は大須の電気街で耐熱電線を購入して,自分ではんだ付け。
  • 上記接続ケーブルを使い,MacBook Airにのせてある仮想ソフト上のWindows XP/10 にてMEMS Gaugeを動作させることができた。
  • とりあえず,この環境で,しばらくログを取ってみた。上記の不具合との関連はわからないが,時々,各センサの値がおかしな値となるほか,バッテリ電圧も降下する様子。また,突然コネクトが切れ,再接続をしなければならない現象も発生。かなり電装系にトラブルを抱えている模様。
  • まずは,しばらくテスタを車内に持ち込み,シガレットプラグで電圧をモニタリング。当初は特に不具合はなかったが,そのうちエンジンの回転数に合わせて電圧が比例して変化する現象が発生。修理業者さんに見てもらったところ,発電機の定電圧化装置が壊れていたので修理。
  • エンジン停止が頻発したため,一時期,修理業者さんに長期入院させる。この頃,業者さんも発電機交換やECU点検・交換など様々な取り組みをしていただいたが,現象はおさまらなかった。鉄製の部品に穴の空いた場所を電線が走っており,その部分の被覆が剥けているのを見つけていただき,補修していただいた折はしばらく現象はおさまったが,その後復活。
  • また,ECUのコネクタ部分の接触が悪くなっているかもと爪をおこしていただいたりした後,やはりしばらく現象はおさまったが,その後復活。
  • 修理業者さんいわく,動力系に不具合はなく,この年式にしては状態が良いとのこと。
  • 毎回,車中にMBAを持ち込み,仮想ソフトを立ち上げ,Windowsを走らせ,USBポートをWindows側に接続し,MEMS Gaugeを立ち上げ,接続させ,ログをとる,という一連の作業をだんだんわずらわしく思うようになり,macOSのTerminal.appで直接動くものを作ることに。macOSで動けば,Raspberry Piに簡単に移植できるだろうから,気軽に使えるようになるだろうという目論見。
  • どうせやるなら新しいことに挑戦ということで,関数型言語Haskellで作ることにする。IoTと抽象化・遅延評価などというHaskellの特徴はあまり相性が良いというわけではないが,だからこそ誰もそんなにやらないだろうということで挑戦。
  • HaskellでUSB−シリアル変換ケーブルの通信をするのにOSのシステムコールを使うかとも思ったが,serialportというライブラリをHackageで見つけ,これを使うことに。まだHaskell環境に慣れていなかったため,当初はうまく自動で組み込めず,ソースを自分のプログラムのソースに移して動作させ始めた(その後,パッケージ管理の仕組みを学んで,外部ライブラリとして管理できるようになった)。
  • 時間の合間合間を見てMEMS Gaugeのソースを参考にしながら接続アプリを開発。当初は初期化コマンドは通ったが,コマンドに対する反応をうまく拾えなかった(4バイト読み込み指定でも2バイトしか拾えないなど。ECU側が数10MHzで動いているし,9600bpsという速度なので,タイムアウトの設定かといろいろ変えてみたが,結局,1バイトずつ読み込むことで解決)。
  • コマンド7Dで得られるデータ数が,ずいぶん少ない14バイトであることが判明(MEMS Gaugeは32バイトを設定している)。MEMS Gaugeのサイトはある程度年式の新しいモデルに対応していたが,こちらは1992年に買った,クーラー付きの日本モデルであり,別のサイトで見るとECUのモデル番号も桁数からして違っている(うちのMiniのECUモデルを表す4バイトの値は39 00 00 5Cという値であり,おそらく部品番号 MNE10078 の, Manual  SPI – Japan – Cooper 向け)。

ECUのログを見ると2016年4月3日のものが残っていたので,遅くともその頃から実際に試行錯誤していたはずだが,記事として出てくるのは2016年から。Amazonの注文履歴では2013年に入門Haskellを,2014年にはReal World Haskellを,2016年にはRaspberry Pi 2Bとディスプレイを発注した記録が残っている。MEMS Gaugeのタイムスタンプは2016年2月。また,非公開の書きかけ記事で関数型言語プログラミングのデザインパターンに関するものが2015年5月2日付けで見つかった。HaskellをECUデータ読み出し用に使おうとしだしたのは2015年から2016年にかけてか。

以下,魚野のサイト内ページです。

Androidで動くPDAのGeminiや,Windows10で動くGPD Pocket でありもののソフトを動かしてもよいのだけれど,ログを解析するのにやっぱりmacでやりたいのと,日本仕様ECUの対応を組み込むのが楽という点で,自作を続けます。

今後の予定

  • パフォーマンス計測と改善。現在は80と7Dのデータを読み込んで表示する1周期に400ミリ秒程度。非同期IO・マルチスレッドにしてもよいのだが,どうせデータを待っている間にmac側がすることもないので,シングルスレッドの基本線は変えない予定。改修はHaskellのチューニングの勉強として,読みづらい表現の変更や例外処理の改善(ByteStringでindexの指定を間違うとHaskellといえど実行時エラーで止まってしまう—止まってしまうのは黙って意図しない処理が行われるよりよっぽどマシなのだが—のでその対策をきちんとする)など。
  • 上記と関連するが,ちゃんとHaskellらしい構造に。今はファイルハンドル情報(を含んだSerialPort型の情報)をあちこち持ち回っているが,本来,カプセル化すべき。文字列の++演算も遅いだろうし,メモリリークの現状も把握できていない。たかだか1回あたり数十バイトの情報を保持するのにByteStringを多用してループをまわしているので,かなり効率の悪い構造になっていてガベージコレクションの時間もかなりとなれているのではと想像する。
  • 出力はcsv形式なので,これをもとに別途GUIを使った表示の仕組みを用意する。本体がHaskellなのでElmを活用?FRPを使ってGUIにもHaskellを使う?昔ながらのcursesなどにしてしまう?
  • Raspberry Pi と得体の知れない互換ワンボードが用意してあるので,そちらで動くようにHaskell環境,OS環境,ディスプレイ環境を整え,車内に常時備え付けられるようにする。ケーブルは今の半自作USBシリアル変換ケーブルをそのまま転用。
  • 広域低電力WANなどの利用で1992年式Miniをコネクティッドカーにする?
  • 関数型言語でのIoT対応について,何かしら発展の方向性を考えてみる(たくさんのセンサからいろんなデータが来て,それを処理していく。また,センサからデータを拾う頻度がまちまちになるだろう。そして,データの処理について,おそらくは柔軟にユーザーに変更できるようにしたくなるだろう。
  • モナドなどは概念をある程度理解し,使えるようにはなった(作れるまでには至っていない)ので,Haskellでのモナド,並行並列処理,GUI,DSL,FRPを使いこなせるように。
  • また,関数型言語プログラミングでの抽象化やモナドなどの考え方は,生物の意識という問題と何かしら関係がありそうな気がするので,それを検討してみる。

参考にした資料など

ECUとの情報のやりとりのプロトコル等

きっかけは忘れましたが,このプロジェクトを始めるに当たり,大いに参考になったのは,独自解析でRover MiniのECUからの情報を読み出すプログラムを公表していたColin Bourassa氏のページ。

  • Rover MEMS 1.6 diagnostic Protocol以前はとある大学のサイトに掲載されていたColin Bourassa氏によるRover MEMSの診断プロトコルに関するページ。今はbearinghead.comというドメインに掲載されている(記事の掲載日時は2014-04-21となっているが,2015年6月と12月に追記されている)。オープンソースで無料の診断情報ソフト(MEMSGauge)やライブラリ(librosco)が紹介されている他,接続用のシリアルケーブルの作り方(利用するUSBシリアルチップやコネクタの規格・入手先情報を含む),ECUのプロトコルなどの詳細が紹介されている。このページがなければ,今回のプロジェクトはなかった。
  • MEMS Diagnostics (Google Group) … 上記サイトからリンクされている。2015年に開設された模様。
  • MG Rover MEMS Modular Engine Management Explained (ビデオ)…最近見つけた,おそらく販売店向けなどのために作られた技術解説ビデオ。ECUがどんな情報をもとに何を制御しているかを簡単に解説している。
  • Display/diagnostics utility for Rover MEMS 1.6 ECU…github内にあるプロジェクト
  • MEMS 1.6/1.9 ECU diagnostics…android用の診断ソフトを紹介している。androidは興味の対象外なので一応あるということだけ知っておく。

シリアル通信について

かつて学生時代,パソコン通信華やかりし頃の1980年代後半,PC-9800シリーズなどのDOS上でTurbo Pascalや,Pascalを開発したWirthが後継として開発した言語,Modula-2を使って端末エミュレーションプログラムなどを作っていました。ですのでシリアル通信の大枠は理解しているのですが,今回はmacOSというUnix系のOSで,しかもUSBポートを通じてのシリアル通信ですので,いろいろよくわからない点があります。そこでまずはLinux Serial HOWTOなどであらためて基礎から勉強してみました。

その他見つけた情報

車のSNSサイトみんカラや自動車販売・修理業者さんのサイトに,Androidoのソフトと自作ケーブルを使った接続事例,市販されているらしい簡易モニタでの診断事例が時々紹介されている。

そろそろガソリンエンジン車の終焉も近いでしょうし,カーシェアリングなども東京ほどではないですが名古屋でも充実してきつつありますので,いつまでMiniを所有し続けるのかはわかりません。そもそもデータを吸い出しても400ミリ秒単位では,現在出ているような瞬停みたいな現象や前触れのない回転数の低下の原因究明に役立つものでもなさそうですが…。まぁ工学部出身の元エンジニアとしては,こういう技術探求がしたくなるのです。

 

 

Threepenny-gui とは

Haskell で Rover Mini の ECU データを拾うプロジェクト,ぼちぼち進めています。

開発は MacBook Air 11” でやっていますが,実際の稼働ではラズパイなどワンボードの小型PCでやろうかと。Haskell はあちことのプラットフォームで動くのでいいのですが,問題はGUI。

Real World Haskell などは汎用GUIライブラリの呼び出し例なども掲載されていますが,macOS で他のプラットフォームと共通のデザインだとものすごい違和感を感じます。また,GUI の世界では最近,Functional Reactive Programming という新しい考え方に基づく実装例も増えてきています。そのものずばりの名前の本(Functional Reactive Programming , Manning Publications )も2016年に出版されたので,計算機科学分野の英語の復習の意味も含めて電子ブックを買い求めて読み進めています(ちなみに最近,書店店頭で翻訳本を見かけましたが,意味が読み取りにくい翻訳となっている箇所が多数あったため,購入は見送りました)。

そこで今回のブログ記事では,Haskell の GUI 環境の中でも FRP が使え,ラズパイ でも macOS でも使えそうな Threepenny-gui ライブラリについて調べてみることにしました。

以下はHaskell wiki Threepenny-gui より。2018年1月17日15:00 (JST) 閲覧した際の記述内容に基づいたもの。

1. Threepenny-gui とは

Threepenny-gui とはウェブブラウザーをディスプレイとして見立てた GUI (Graphic Interface Library; グラフィックユーザーインターフェース) のフレームワークである。

以下の機能を持つ:

  • 容易な設置 いまどきは誰でもブラウザをインストールしている。従い、threepenny-gui ライブラリを hackage からインストールするだけでよい。このライブラリは多数のプラットフォームで動作する。
  • HTML + JavaScript ユーザインタフェースを作成する際、HTMLの機能をすべて使用することができる。これは素晴らしいことではあるが、うっかりするとはまり込んでしまうことにもなりかねない。それゆえ、このライブラリには、CSSを使用しなくてもユーザインタフェースを素早く構築できるよう、レイアウトコンビネータが含まれている。またFFI(Foregin function interface; 他言語接続機能)を利用してブラウザの中でJavaScriptを走らせることも可能である。
  • FRR ( Functional Reactive Programming ) により、ユーザーとのやりとりのプログラミングでイベント駆動式のスタイルを伝統的な手続き型言語で構築するときに陥りがちなスパゲッティコードを避けることができる。Threepenny は FRP ライブラリを持っているが、それを使うか否かは自由である。便利と思えばFRPを利用してもよいし、袋小路にはまり込んだと思ったら FRP を使わなくてもよい。

2. Threepenny-gui ができないこと

  • ウェブのフロントエンドではない。サーバはローカルホストで稼働することを想定している。(ネットを経由する)ウェブアプリとして使用するには遅延が問題となるだろう。つまり、ローカルネットワークの多数のユーザーを想定した場面には向いているということ。サンプルコードの Chat.hs example を参照。
  • JavaScript や HTML のライブラリではない。Threepenny-gui は Haskell の API を備える GUI フレームワークであり、ドキュメント・オブジェクトモデルについて様々なことを抽象化している。Threepenny-gui を使うにあたっては、 HTML については多少の知識が必要だが、JavaScript の知識は必要ではない。もっとも、外部クライアントライブラリを活用とする場合はその限りではないが。

ウェブアプリを作ろうとしているなら、他のプロジェクト(たとえばFay, GHCJS, Haste など)を参照のこと。Threepenny の API はこれらのプロジェクトにいくらか影響を与えている、もしくは将来与えることになるかもしれないが、現時点ではそこ(ウェブアプリ開発向きの機能)に焦点はあたっていない。

3.開発経緯

現在、活発に開発が行われいる状況であり、主要なAPIについても将来の版では改訂されているかもしれない。このプロジェクトの目標はGUI プログラミングをできるだけ簡素にすることにある。そのためにやや実験的に様々な挑戦を行っている。

  • 2017.04.29 threepenny-gui-0.8.0.0 公開
  • 2016.09.16 threepenny-gui-0.7.0.0 公開
  • 2015.05.15 threepenny-gui-0.6.0.2 公開
  • 2015.05.13 threepenny-gui 0.6.0.1 公開
  • 2014.10.04 threepenny-gui 0.5.0.0 公開
  • 2013.11.21 threepenny-gui 0.4.0.0 公開
  • 2013.09.07 threepenny-gui 0.3.0.0 公開

4. 応用例

Threepenny を使って書かれたアプリケーションの例

5. 現況と参考資料

Hackage からのダウンロード threepenny-gui

参考資料

フィードバック先および連絡先

github 上のソースコード

Haskellメモ というか,High Sierra と FTDI USB Serial メモ

以前からぼちぼち開発しているRoverMiniコンピュータデータ取扱用のプログラム,ので本日はその原因究明と対策実施。

現象

  • macOS X を High Sierra にしたら,FTDIのUSBシリアル変換機がマック上ではttyデバイスとして認識されなくなった。
  • 同じハードで仮想マシン上のWindows10では同変換器を検出し,正常にECUと通信できるので,マック上のドライバの問題と想定。
  • メーカー(FTDI社)の最新ドライバなどをインストールしてみたが,状況は変わらなかった。
  • High Sierra ではセキュリティ強化のため,場合によっては「システム環境設定」のセキュリティとプライバシー設定で,明示的に権限許可を与えないと動作しない機能拡張があるが,現時点では許可催促の表示は出ていない(ただし,当該催促は最初にその機能拡張が動作しようとしてから一定の時間以内にのみ表示され,その後は消えてしまうとのことなので,OSアップデート後にケーブルを初めて挿入した際,これを見逃した可能性はある)。

原因探索

ネットで検索した所,以下のことがわかり,ドライバが複数あって,衝突して不具合となっている可能性があるものと思われた。

  • Appleは,しばらく前(少なくとも Marverics )から,自社のFTDIチップ用ドライバを mac OS に含めて提供している。
  • 幾つかのサイトでは,FTDI社のドライバとApple社のドライバの切り替えを行って問題が解決したことを報告している。(例1例2例3例4
  • 両ドライバとも,kext形式で提供されている。
  • kextとは,加除可能なOS機能追加モジュールであり,sudo kextstatで現在使われているモジュールの確認ができる他,sudo kextload xx.kext でモジュールを追加することができる。
  • 当該ハードには,OSバージョンアップ前からFTDI社のドライバが入れてあり,機能していたが,こうした場合,High Sierraのインストールでは,(クリーンインストールであっても?)サードパーティー提供のドライバが新たな権限許可を与えずとも動作するようになっている模様。

対策

ドライバを一つにする。Apple社提供のものでまずは実験してみて,その上で,FTDI社のものを実験してみるかを判断することにした。実際の作業としては,以下の通り。

  • 存在しているドライバの確認。→/System/Library/Extentions にAppleUSBFTDI.kext 2017/08/25 14:20 6.0.0 がある。また,Library/Extentions に FTDI社のドライバ D2xxHelper.kext 2015/11/09 2.0.0 があった。
  • kextstat | grep FTDI で動作している機能拡張を確認。今回の場合はなかった(両方共読み込み失敗の様子)。
  • FTDI社のドライバを削除の上,マックを再起動。
  • 手動でAppleのドライバを読み込み(cd /System/Library/Extentions  -> sudo kextload AppleUSBFTDI.kext)
  • kextstat で機能拡張が読み込まれているかを確認。この時点では読み込まれていない。
  • ケーブルを接続。kextstatで状況確認→ドライバが読み込まれている。
  • /dev/ を確認。無事,認識され,/dev/tty.usbserial-DJ0… として表示された。

まとめ

  • 今回のトラブルの原因は複数の機能拡張(ドライバ)を設置したことによる競合。
  • 純正とメーカー製の二種類のドライバで機能・性能が違いそうなので,今後,機能・性能で不審な点があった場合,ドライバを変えてみるという策をとってみる必要がある。

以上

 

Haskellメモ Haddock

この説明は,Haskellの公式サイトの記述を魚野が自分のメモとして部分的に日本語化したもの。
詳細は下記サイト参照。
http://haskell-haddock.readthedocs.io/en/latest/markup.html

1 Haddockとは

Haddockとは,プログラミング言語,Haskellのソースファイルにコメントを記述することで,
自動的に参考用の文書を作成するシステムのこと。

2 Haddockの記法

2-1 トップレベル宣言

・トップレベル(関数の型署名や方宣言,クラス宣言等)での記述。
・「--|」という句で書き出すと,それ以降の部分はその直後の宣言に関する説明となる。

-- | The 'square' function square an integer
square :: Int -> Int
square x = x * x

・トップレベルとは
トップレベルの関数の型署名
型署名のないトップレベルの関数の定義
data 宣言
newtype 宣言
type 宣言
class 宣言
data family または type family 宣言
data instance またはtype instance 宣言
・別の宣言が続いた時は,後の宣言はHaddockに無視される。
・宣言の後にコメントを書くことも可能。

square :: Int -> Int
-- ^ The 'square' function square an integer
square x = x * x

2-2 宣言の一部分へのコメント

・クラスメソッド トップレベル宣言に同じ(「-- |」 や「--^」を使う)。
・コンストラクタ,レコードフィールド 同上

2-3 関数の引数

・「--^」を使う。

f :: Int -- ^ The 'Int' argument
-> Float -- ^ the 'Float' argument
-> IO() -- ^ the return value

2-4 モジュールの説明

・モジュールの説明は記述が多岐にわたることが多い。

{-|
Module : W
Description : Short description
Copyright : (c) Some Guy, 2013
Someone Else, 2014
License : GPL-3
Maintainer : sample@email.com
Stability : experimental
Portability : POSIX

Here is a longer description of this module, containing some
commentary with @some markup@.
-}

・各フィールド全てを記述する必要はない。重要度の順で記述すること。
・各フィールドの中身が二行以上になる時は,フィールドのラベル終了位置よりも右方から記述する。
・但し,冒頭に「--」を記述した際は例外(詳細は冒頭のURL参照)

2−5 モジュールの説明要素

・Module モジュール名
・Description モジュールの概説。
・Copyright, License, Maintainer, Stability できるだけ明示すること
・Portability OSの制約や必要なGHC拡張が記述されることが多い。

3 ドキュメントの構造

・各モジュールが輸出(エクスポート)している要素のみ説明文作成の対象とされる。
・輸入(インポート)されたモジュールで輸出されている場合も説明文作成の対象となる。
・3つの構造がある:セクション頭書,名前付記述,モジュール全体の再輸出

3-1 セクション頭書

・Class, Typeなどは同位のセクション,Type, A data type などはセクションの下位化
・「-- *」,「-- **」などで書き始める。*数はセクションの下位化

3-2 名前付記述

・名前付記述 二個目の「-- $XXX」以降の記述は一個めの「-- $XXX」の部分に置かれる。
XXXは名前)

3-3 ハイパーリンクと要素再輸出

・Haddockは説明文書作成の際,クラス名などを全てハイパーリンクつきにする。

Haskellメモ inkey$を実現する

難しいことを簡単にし,簡単なことを難しくする,などといわれる純粋関数型言語 Haskell。かつてBasic 言語でプログラミングをしていた際によくつかったinkey$関数の実現方法を調べてみた。

inkey$関数とは実行されたときに押されている一文字からなる文字列を返す関数。キーが押されていないときは””が返ってきたはず(30年以上前の記憶なのでうろ覚え)。

以下のコード〜raspberry pi で動けばいいので,とりあえずはこんなコードで〜を macOS で動作確認したところ,おおむね期待通りに動作した。Windows でどうなるかは不明。

import Data.ByteString as BS
import System.IO

main :: IO ()
main = do
 hSetBuffering stdin NoBuffering -- set non buffering mode 
 keyscaned <- BS.hGetNonBlocking stdin 1 -- ::IO ByteString
 if keyscaned == BS.empty
 then main
 else do
 print keyscaned
 main

Haskell メモ MyECU

Haskell の習作として Rover Mini の ECU (MEMS)モニタソフトを作りかけている。以下はそのために試行錯誤した際のメモ。順次追記予定。

  1. 16進数表記の文字コードを入力し,文字を得る。
    
     do
       charcode <- readLn :: IO Int
       let command = chr charcode
     

    ECUコマンド発行用。ECUコマンドは基本的に1バイト文字。符号なし1バイト整数を意味する Word8 をこの時点から使おうかと思ったが,chr 関数にWord8を引数とさせる方法を調べるのが面倒だった(多分,こちらの記事が役に立つ。あとで調べる。)ので,とりあえず Int で入力させることを決め打ちにしてこのようなコードに。コンパイラオプション({-# LANGUAGE OverloadedStrings #-}ghc -XOverloadedStrings )を活用する方法を使わなかったのは,単に使うオプション類をできるだけ少なくしたいというコーディングスタイルの趣味の問題。

  2. macOS 機または Raspberry Pi での動作を前提とし,USBシリアル変換ケーブル経由のデータのやりとりをデバイスファイル経由で行う。
    
    result 

    ByteString 内の hPut や hPutNoBuffring では,文字を書き込んでも制御が戻ってこない。下層の Unix システムコールを Haskell で使う Posix.IO の wirteFd あたりを使う必要があるか。Haskell の問題というよりは Unix の使い方の知識の問題。
    【2017.05.30 追記】結局,serialPortモジュールを使うことで解決。初期化やデータのやりとりができるようになった。protocol.c では初期化コマンド送出の途中に ping を入れているので,この仕組も取り入れた。

  3. コンソールで入力した16進の文字コードをECU側に発行し,その反応を,時刻付きでコンソールに表示する。
  4. コンソールに表示した時刻と反応のセットを,第二引数で指定したファイルに書き込む。
  5. シリアル通信が途切れたときのための例外処理の追加。

20150403 研究会に出席

本日は診断士仲間の研究会,グローバル・ビジネス研究会(旧国際ビジネス研究会)に出席してきました。昨年度から今年度にかけてのテーマは海外でのサービス業展開の支援。関係者である専門家の方2名,診断士仲間3名の計5名でビジネスアイディアについて,活発な議論が2時間繰り広げられました。

本日の段階ではこれまでの数回の議論を踏まえて固まってきた簡単なビジネスモデルについて,活用できる経営資源をどう利用するかというアイディア出しが行われました。参加した5名の背景がそれぞれかなり違うことから,それぞれの経験を踏まえた鋭い指摘がいくつも出され,議論が急速に深まり,事業の実現の見通しに対する印象も,ずいぶん良くなりました。また,参加者からも,たいへんよい議論だったとの感想が多くありました。

次回は連休明けの5月8日の開催を予定しています。

20130925 診断士・診断士制度に対する3つのアイディア

 昨日の理論政策更新研修の際にお話した先輩診断士との会話の中で,診断士制度がTPPでどうなるかという話になった。制度相互乗り入れの対象となるのかなと思うが,アジア・オセアニア・北米で国が認定する経営コンサルタントの資格制度というものはほとんどないのではないか。とすると,会計事務所系や金融機関系,IT系などの大手や専門コンサルティング会社との競争となるかもしれない。

 いずれにせよ競争環境が厳しくなるとして,診断士や診断士制度はどう生き残るべきか。

 診断士以外の専門家ができない分野を開拓すべきと思う。総合的な知見+専門分野,中小企業支援行政との関係が強いという点を活かした何かということになろう。

 以下,魚野の私的なアイディア(魚野自身が実際に以下のアイディアを即,担えるようなレベルになっているというわけではないことはあらかじめお断りしておく)。

1. 米国型シンクタンク化

 アメリカのシンクタンクのように,行政に政策を提案し,採択された場合,その政策を担当するために期間限定で任官するのはどうかと思う。実現には診断士側が政策提言できるくらいのスキルアップ(場合によっては法案や条例案を自らつくり,専門家と討論できるくらいの相当の学びをしなければならない),公務員制度(狭い担当範囲の短期雇用任官)や行政制度の改革(道州制か県単位,市町村単位程度が適当ではないかと思う。)が必要となるから実現には相当ハードルが高いアイディアだが,だからこそ,補助金や認定支援,支援組織からの派遣などの行政・商工会の下請け的な業務形態に甘んじること無く,日頃から政策アイディアを考え,提言にまでまとめていくことを重ねるべきと思う。

2. 小規模事業者の支援への特化

 TPPで国境を越えてコンサルティング業者が進出するようになり,規模の大きいところとの競争が本格的になるとしたら,彼らができないことを担えばいい。いわゆるニッチ戦略。小規模事業者が支援対象だと,なかなか診断士側の収益の出処が確保しにくい可能性も出てくる。そこでアイディアとしては,BOPビジネスのような,支援ビジネスのイノベーションをはかること。IT活用(特にSNSなど)や,小規模事業者の組織化といったような方策が有効なのではないかと思う。6次産業化プランナーの業務,特に魚野が担当している事業者さんは小規模事業者さんが多く,やっていることはややこのアイディアに近いが,農林省という行政の予算で動いていることなど,まだ不徹底,かつ,ビジネスモデル確立には至っていない点をなんとかしなければならない。

3. 診断士制度・ビジネスモデルの海外輸出

 すでに診断士制度の海外への紹介,制度定着支援などは過去に行われていたが,アジア諸国・地域の更なる発展の下支えとして,経営診断,支援の需要は一定程度あるのではないか。このアイディアの問題点や課題は,社会開発の関係者としっかりした協力関係が築けていないことや,診断士側のメンタリティが戦後のガンバリズム・縦型の人間関係に慣れている人が多く,価値観多様化・異文化対応が必須の海外で指導・支援ができるかという心配がある。これはしかし,日本国内で業務を続けるに際しても,横型の人間関係やプロジェクト型チームのような事業者の形態は今後増え続けるだろうから,対応できる診断士が増えていくだろうとは予想している。片道1万円程度で香港あたりまではいけるようになった。海外進出する日本系企業も多くなるだろう。タイムマシン効果をねらってはいかが。

4. その他いろいろ

 小粒ネタから壮大な夢までレベルの違う話がいろいろ入り交じっていますが,今まで他の人に話したことのあるアイディアとしては,会計参与ならぬお雇い参謀(外部取締役の派遣),日本語経営支援・ビジネス・事故啓発系コンテンツの海外発信,大学生や第二新卒者のキャリア相談,…。

12th Nagoya Profession English Book Club was held

In 4th June, Wednesday afternoon, the 12th Nagoya Profession English Bookclub was held in Nagoya.

This time, we discussed under the theme of Abenomics evaluation.

In the first half of the program, we read and talked about in each paragraph of the article the moderator specified, ‘Hope in Japan That Shinzo Abe’s “Abenomics” May Be a Cure’ ( http://www.nytimes.com/2013/05/21/world/asia/hope-in-japan-that-abenomics-may-be-turning-things-around.html?pagewanted=all&_r=0 ) issued in NYTimes website.

In addition, in the second half, while citing impact of Abenomics, we continue talking to organize our opinion in so-called pro / con format.

Many comments were presented and finally, we found variety of viewpoints were included, such as the point of view of people’s lives and perspectives of government-run. Of course we know it is not well organized, but running out of time, it was with the results of as shown in the photograph.

Thank you, Mr Yusei Yamazaki and Mr Masahiro Kunishima, for attending the anniversary meeting.

Well, I found that there are differences between actual programme and the original schedule we planned in march. So we have to adjust date and moderator for the next meeting. I will ask you in several days for the next date after asking Mr Toru Oda for his participation as a moderator for the next meeting.

Thank you.

Kentaro Uono
Representative
Nagoya Profession English Book Club