香港の現状に思うこと

Why Civil Resistance Works 表紙

香港との接点

1987年から1988年にかけて,南京大学に語学留学していた冬休み,上海から船路で香港を訪ねた。鄧小平の南巡講話はすでにされていたが,経済発展の端緒についたばかり。翌年には天安門事件が起こるというタイミングである。19世紀末とあまり変わらないであろう生活スタイル,電力の節約で暗い中国大陸から,いきなりきらびやかな自由経済の旗手,東西混淆の香港にたどり着き,彼我の違いに目を見開きながら楽しんできた。

その後,就職して後も国際調達担当の業務で単独で新疆ウイグル自治区や山東省,河北省,江蘇省,福建省と訪れ,東京からの直行空路がふさがっているときは,啓徳空港からバスで市内を移動して境界を越える鉄道に乗り換えて広州へ往き,そこからまた空路で中国国内へと移動したこともある。また,食品会社を離れてからも,支援先の事業者さんや支援仲間と,あるいは単独で,視察や商談・出展・販売支援,観光にと随分足を運び,ときには密貿易の現場を覗きに行ったり,早朝の食品市場をめぐってみたり,いきあたりばったりでたどり着いた海岸で昼寝をしたりと,たびたび香港にはお世話になってきた。

スライドショーには JavaScript が必要です。

揺れる香港と過去の記憶

その香港が,今,揺れている。

一国二制度の形骸化を懸念しつつ,それでも独自の立ち位置にある香港は,海外旅行や食品輸出,海外展示会出展,商談の入門編として,手頃な場所であった。LCCが飛び始め,当初は大阪から発って深夜に到着するような強行軍をやってみたりしたが,ほどなく中部国際空港からも便利な時間帯に新たな路線が開設され,旅券とクレジットカード,スマホさえ持っていれば,当日思い立ってその日の夕方には香港などということもできるようになった。英語や中国語が通じ,社会秩序が安定しているという安心感があった。

一方で,銅鑼湾の書店主が行方不明になったり,愛国教育ー大陸では歴史・道徳教育的な位置づけーの延長として讒謗律のような法令が制定されるなど,耳目を集めるニュースが続いていた。

そして雨傘運動が起こり,民主派の立候補規制がかかるなど,揺れ動きが続いてきた。

今回,半年近くになる抗議活動が続いている。北京での騒動を,南京から戻ったばかりの頃,まだインターネットでニュースや動画が駆け巡るなどと思いもよらなかった頃,限られた情報を見つめていた。一介の学生としてやれることは限られていた。その頃の記憶につい意識が向き,暗い結末を迎える懸念が頭を離れない。

社会政治運動の成功率と香港の特殊な位置

ここに,20世紀100年間+アルファの期間の各種政治運動を分析した研究結果をまとめた本がある。

Book

・非暴力運動のほうが暴力行為中心の運動よりも成功率が2倍以上高い
・運動の参加率がピーク時で3.5%を超えると成功率が飛躍的に高まる

Why Civil Resistance Works 表紙
“Why Civil Resistance Works” Columbia University Press, SBN: 9780231527484

という研究成果が記載されている。香港の人口は約700万人。3.5%というと,約25万人だ。主催者発表では200万人を超える(警察発表でも30万人を越える)参加があったデモが複数回すでに起こっている。過去のデータから得られた知見からすれば,この運動は少なくとも香港域内では成功する確率が高いといえそうだ。

もっとも,香港は中国の一地域という位置づけである。大陸での香港情勢に関する情報流通はかなり統制がかかっており,関心も高くない。中国自体が変わるには,総人口12億人(未登録者も多いので13億人以上というのが実態だろうが)の3.5%という数字を使えば4,200万人以上が動くことが指標となる。年々変動しているが,香港への入境者人数は年間約4,000万人。大陸から7割として,年間2,800万人が香港を訪れていることになる。もちろん,生活費が安い大陸に住み,越境して勤務する人も多く,現時点では大陸から香港への観光を大幅に制限しているようなので,直接,香港の今を見聞きしている大陸の人達の人数は現時点ではかなり限られるだろう。それゆえ,上記の数に達して大陸側も変わるという可能性は,全く0とはおもわないし,一国二制度が維持される50年間の間に融合的な動きが起こってほしいとは思うが,今の所そこまでの広がりはない。また,運動もそうした目標を持っているとはいえず,今回の五大要求は表面的にはあくまで香港域内での政府の変化を要求している。もちろん,行政長官が北京の了承がなければ辞任もできないように,香港の統治・政策は中国共産党の意志が大いに関わるので,間接的には大陸政府の変化を狙っていることになるが,

ともかくも

自分は社会問題の専門家ではないし,中国語も北京語はともかく広東語は片言程度しか話せないので,もっぱら個人的関心,業務上の必要から香港に関心を持ち続け,時折訪問しているわけだが,馴染みがあり,また訪れたい場所といえば間違いなくその筆頭候補の一つである。また,中国が世界と協調して平和裏に,経済のみならず,政治や社会も発展してほしく,またその変化を見続けたい。アジアのみならず,世界の行く末を決める大きな要因の一つが,中国のありかたであり,その重要な因子として,香港,台湾や,中国国内の民族・人権・政治の変化は,目が離せないでいる。

評論的なものはさておき,上記の研究結果を知るにつけ,また,暴力は慎むべきという個人的に信条からしても,軸となる人達には非暴力という志向を持ってほしい。暴力装置の介入は,そこで生活している人々の大きな不幸を招くだけでなく,世界的な経済の大混乱や,人材の喪失に至る。これを防ぎつつ,理想とは行かないにしても一歩でもより望ましい社会をより少ない不幸で実現するには,知恵と理性と戦略とをもち,周囲の共感を引き起こせる行動をしなければならない。市民側からすれば,警察や社会インフラ機構は攻撃対象ではなく,説得対象ではないだろうか。また,行政側からすれば,市民活動を力づくで抑え込もうとするほど,運動が過激になり,みすみす外部からの介入を許すことになりかねない。攻撃による反作用を燃料に活動活力を維持することは,双方いずれにとっても安直で愚かな手法である。

希望を持ち続けたい。

重陽節の夕べに来し方を振り返りつつ

菊の花

MEMS(ECU)モニタ開発状況 GHCのバグ?環境整備の問題?

エンジンルームを乾燥中の Rover Mini 1.3i

インジェクション・ローバーミニの車載コンピュータのモニタリング,Macではstack環境下で順調に開発・運用していますが,ラズパイでの運用は未完。stackでのコンパイルがまだできないので,ghcで直接コンパイルをしてみたのですが…

現状把握:何が起こっているか

使用している serialport パッケージ内の関数で引数の型として指定されている ByteString の参照先が Mac でstackを使ってコンパイル(stack 2.1.3) した場合と RaspberryPi で直接GHCでコンパイル(GHC 8.0.1 on Raspberian 4.14.79-V7+)した場合とで異なる。ラズパイ上ではなぜかbytestringのインターナルモジュール内の定義を参照し,呼び出し側は,モジュール内で明示的に指定した公開ライブラリを見にいっています。

具体的には,serialportパッケージのsend関数の第2引数の型が合いません。serialportの中では

> import qualified Data.ByteString.Char8 as B
>(中略)
> send :: SerialPort -> B.ByteString -> IO Int

と定義されています。一方,自作のモジュール内では,

> import qualified Data.ByteString.Char8 as BS
> (中略)
> send p $ BS.singleton (chr 0x0a)

みたいな感じで呼び出しています。

引数の型は合っているはず。Data.ByteString.Char8 (以下,「D.B.C」と省略)でのsingletonの定義は,

> singleton :: Char -> ByteString

です(尤も,D.B.C内のByteStringの定義は,後述の通り,Internalモジュールからインポートしていますが)。

実際,macOSでstack buildをした場合,問題なく通りますし,運用もできます。ところがraspberianで ghc でのコンパイルをすると,BS.ByteString は Data.ByteString.Internal で定義されているbytestring-0.10.8.1:Data.ByteString.Internal.ByteStringと合わないというわけで,型の不一致とされてしまいます。うーむ。

原因分析:何が原因か

serialportのソースをおっかけてみると,まずByteStringの定義は前述の通り,D.B.Cを参照しています。また,sendの第2引数は,途中でWord8に変換するため,B.unpackをかけており,その先のD.B.Cのほうでは,unpackは結局,内部関数のunpackAppendCharsLazyを束縛しています。

> unpackChars :: ByteString -> [Char]
> unpackChars bs = unpackAppendCharsLazy bs []
> (後略)

そこでunpackAppendCharsLazyを見ると,内部のByteStringの定義を用いて関数が定義

> unpackAppendCharsLazy :: ByteString -> [Char] -> [Char]
> unpackAppendCharsLazy (PS fp off len) cs
> (後略)

されています。

InternalモジュールでのByteStringの定義は
> data ByteString = PS {-# UNPACK #-} !(ForeignPtr Word8) -- payload
> {-# UNPACK #-} !Int -- offset
> {-# UNPACK #-} !Int -- length
> deriving (Typeable)

となっています。これは外部公開していないモジュールのはずですから,ここを参照すべきではないでしょうし,D.B.Cのほうで,ちゃんとByteStringをエクスポートしています。

> module Data.ByteString.Char8 (
>
> -- * The @ByteString@ type
> ByteString, -- abstract, instances: Eq, Ord, Show, Read, Data, Typeable, Monoid
> (後略)

ですので,D.B.Cを指定したByteStringで型は一致するはずなのですが…

真因追求:本当の原因として考えられること

  • raspberian 上で整えた GHC の環境がおかしい? … 冒頭で述べたように,stackでの開発がラズパイ上ではできていません。cabal ライブラリのコンパイルをはじめて,大きなライブラリのコンパイルでメモリが不足して止まってしまう(一応,仮想メモリとして4GBを確保してあるのですが)。stackの環境構築がこのように中途半端になっているので,それがローカルなライブラリDBを構成するなどの悪さをしている?
  • 環境・構成に依存するGHCの挙動の違い? … GHC のバージョンや,Stackを使った場合と生で呼び出した場合のGHCに渡されるオプションや構成の違いが真因の可能性も。

考えられる対処

いずれにしても,検証するには環境を合わせることから始める必要がありそうです。そもそも stack ・ GHC 直接という違いもあり,macOS と raspberian とでは GHC のバージョンも違うため,そこらへんを合わせてみることが必要なのかもしれません。

思い切って,ラズパイ用は go言語で組み直してみる?手続き型言語の冗長さと,代数データ型やモナドが使えないなどの面倒さにつきあうのはためらいがありますが…。

蛇足

こんなデータを0.5秒おきにとっています。開発目的は,時々発生するECU気絶に由来すると思われるエンジン停止や回転数低下の原因を特定したいためと,IoTや関数型言語でのプログラミングの勉強。

下記画像では,右端の部分で時々横線が入っているように見える部分が,そこが,ECUのデータ読み出しができなかった瞬間です。左側の数値が羅列されている部分でいうと,文字列が並んでいる行です。

気が付かれる方もあるかもしれませんが,魚野の車はマニュアル車です。ですが,ECUが原因かという検証のため,修理業者さんが別の車のオートマ用ECUをつないでくれたために,オートマと表示しています。ECUが変わっても,瞬停や回転数落ちはまだ発生していますので,ECUそのものが原因ではないと思っています。

Rover Mini ECU(MEMS) Monitor CSV Data
Rover Mini ECU(MEMS) Monitor CSV Data

ECUモニタ開発状況

ローバーミニ,すでにクラッシックカーの領域に入りつつありますが,1992年以降に日本で新車として販売されたミニにはインジェクション方式が導入され,制御用のコンピュータECUも載せている。趣味として関数プログラミング言語 Haskell を使ってこの制御用コンピュータのデータをモニタリングしようとしてきましたが,少しづつ開発を進めています。ちなみに現在も引き続き車内にMacBookAirを持ち込んで,運転中に自動記録しつつ,車載モニターにライブデータを表示しています。

スライドショーには JavaScript が必要です。

開発の現況

全体としては安定してモニタリングできるようになり,プログラムの一部を改造しても他の部分に影響を出しにくくなりました(モジュラー化が進んだ。以前は各パーツが密接に絡み合っていたため,一部を改造するとしばらくコンパイルエラーのみならずロジックエラーを誘発していた。)。

Rover Mini ECU(MEMS) Monitor Screen Shot
2019年5月の Rover Mini ECU(MEMS) Monitor スクリーンショット

これは2019年5月にとったスクリーンショット。数値表示だけでは一瞥したときに全体像が把握できないなと,アスタリスクによる各データのリアルタイム棒グラフをつけたもの。

試作したRover Mini ECUモニタの画面
開発が進んだRover Mini ECUモニタのスクリーンショット

そしてこちらは過去データや他のデータとの相関を見たいと思い,縦棒グラフを並べるようになったバージョン。

2019年9月現在の画面

そして現在は複数のデータを同一のグラフに描画しています。一通り走った後,エンジンを停止した状態(エンジンを切っても10秒くらいはECUが動作しています。おそらく冷却液用の冷却ファンをしばらくまわすため)での画面キャプチャ。画面右側は,テキスト表示でむりやり表現した温度や回転数など各種センサー値の重ね合わせグラフ。テキスト表示なのは,ラズパイなど超小型コンピュータで動作させる際に簡単に実現できそうだからです(GUIはメモリや処理能力に要求される水準がTUIに比べて圧倒的に高いが,超小型コンピュータにそれを求めるのは酷ですものね)。

ループ処理や例外処理を見直し,エンジンの稼働状況やECUと繋がれた信号線の状態に影響を受けにくくなり,安定して稼働するようにしました。

こちらのログは岡崎から名古屋に帰る道すがら記録したものです。時々接続が切れて再接続しています(再接続に1秒近くかかっているのはあえて待ち時間を1000m秒入れているから)。路面の凸凹やアクセルオフ時の振動に連動(?)して接続が切れているので,コネクタかセンサ固定に何か問題がありそう。

Rover Mini ECU(MEMS) Monitor CSV Data
Rover Mini ECU(MEMS) Monitor CSV Data

得られた学び

前回の報告から進展したHaskellの学び,Haskell中級編といったところでしょうか。

モナドを作れるようになった

モナド,Haskell初心者のつまづきの石です。わかってしまえばなんてことはない概念ですが,RealWorldHaskellとかでゆっくりまなびつつ,試しにECUとのコミュニケーションモジュールで自作のモナドを作ってみました。裏で動く仕組みが理解できたため,ソースを見ても動作に検討がつくようになりましたし,liftとか融合とか,避けていた知識を身に着けたら,いろんなことがより簡素に表現できるようになりました。結局,ECUとのコミュニケーションモジュールは,出来合いの ReaderT を活用しています。ちなみに,モナドはRealWorldHaskellの記載内容から変わったところ(変わるところ)があるので,要注意。

Haskellでの例外処理を理解した

関数やIOモナド,スレッド間通信などがからむので,”Parallel and Concurrent Programming in Haskell”を電子書籍で購入して並行プログラミング関係だけ読み,初歩はマスターできました。このプロジェクトではマルチスレッド間の資源の取り合いはほとんどないので,できるだけ例外をマスクして,Eitherなどで把握・対処するようにしています。STMを利用したチャンネルで,スレッド間の通信をおこなうようにしました。

Haskell用TUIライブラリを使ってみた

Brickを使ってみました。GUIの基礎概念は知ってはいましたが,使ってみたのはほぼ初めて。プログラミングをよくやっていたのは学生時代で,まだGUIが一般的でない時代にPascalやModula II でPOSシステム,パソコン通信プログラム(端末エミュレータ)などを作っていました。まだオブジェクト指向という考えが広まる前で,インタフェースもGUI普及前。ユーザーとしては,まわりがワープロを使っている時代にMacintosh Plusで卒業論文を書いていたのでまさにエバンジェリストといった感じでしたが,イベント処理とか,GUIやオブジェクト指向でのクラスとかいった概念は,Smalltalkでちょっと触ったくらい。学び直しました。とはいえ,Brickのドキュメントを読むと一通り書いてあるので,それで済ませましたが。

グラフの作成

TextPlotというそのものズバリの名前の,テキスト文字によるグラフ作成ライブラリを使ってみました。ライブラリのソースを読んでみたのですが,仕組みとしては事前に考えていた内容そのものであったものの,その表現が関数プログラミングの利点を活用してすごく簡素に書かれていてびっくり。ただ,機能がシンプルで,随分前に進化が止まっているようなので,カラー化とか凡例表示とか,Vector化とか,いろいろ改造していきたい。

今後の計画

ラズパイでの稼働

本来はMacBookAirなどノートパソコンではなく,ラズパイなど超小型コンピュータで稼働させたいところですが,大型ライブラリBrickを使うために,ラズパイで直接コンパイルすることは難しそう。Docker と QEMU でクロスコンパイル環境を用意しましたが,stack を利用してのコンパイルはまだ完了していません。これをなんとかしたい。

グラフ表示の改善

表示要素が多いと,グラフの把握が難しくなります。カラー機能自体は既に使っていますが,TextPlot側が対応していないので,要改造。
また,凡例表示や,X軸時刻表示(今は単なる相対時系列番号)も課題。

終わりに向かって

ハードの監視というきわめてHaskell向きではない分野で手続き的な表現を多用していましたが,少しづつ関数プログラミングらしい表現を取り入れています(FunctorやAplicativeFunctorな演算子の導入とか)。抽象化が進むので,機能を増やしてもそれほどソースの行数が増えず,実行速度もあまり遅くならないことに感動。

OLYMPUS DIGITAL CAMERA

stackとraspberry pi

raspberry pi で stack buildできなかった問題,解決

Rover Mini の ECUデータ読み出しプログラムを動作させるためにRaspberryPiを用意したのだが,Haskellのコンパイルがstackを使ってはできなかった。stackが使えないと,ライブラリの準備とかが大変。

発生していた問題

stack buildすると,アセンブラが,この機械語はARMでは使えないとのたまうエラー発生。

/tmp/ghc2452_0/ghc_6.s:44:0: error:
Error: selected processor does not support `movt r7,:upper16:stg_bh_upd_frame_info' in ARM mode
|
44 | movt r7, :upper16:stg_bh_upd_frame_info
| ^

原因と対策

原因はコンパイル時にCPUアーキテクチャがGHCに伝わらないstackのバグ

対策は海外サイトのブログを参考に,GHCの設定ファイルにアーキテクチャ指示オプションの追加。以下は上記の参考サイトに書いてあるものだが,実際にはGHCの8.6.3がインストールされていたので,適宜8.0.1を8.6.3に読み替え。

$ vi ~/.stack/programs/arm-linux/ghc-8.0.1/lib/ghc-8.0.1/settings
...
("C compiler flags", " -marm -fno-stack-protector -mcpu=cortex-a7"),
...

あとがき

しかし,一昨日,車室内で冷却液の噴出をやらかしてくれたRover Miniはあえなく修理にまわすことに…。当面,ラズパイによるECUのモニタリングソフトの出番は先です。

あとがきその2

古いラズパイ上でHaskellを走らせたりWiFiドングルを使ったりしているのですが,いくつか注意点がありました(現在は解決済みのものもある):
– apt-get で入れられる stack のバージョンが古い。現在はRaspberianのもとになるディストリビューションが変更されたためか,関係者のご尽力により普通に入れられます(ただし,前述のGHCのコンパイルオプションが渡されないバグに注意)。
– 大型のライブラリをコンパイルしたり,インストール直後の何もコンパイルされていない状態から大量のライブラリをコンパイルすると,メモリとディスク上のスワップ領域を使い切ってOSごと固まってしまう模様。恒久的にスワップファイルのサイズを変える方法恒久的にスワップファイルのサイズを変える方法その2一時的にスワップファイルのサイズを変える方法
– WiFiドングルにはドライバが必要(ただし,ヤマダ電機で購入したElecomのドングル(型式:●●)は最新のOSだと初期設定でそのまま動きました)。

車内ヒーターから冷却液噴出した92年新車登録のRover Mini,ただいま乾燥中。

(6次産業化事業者を含む)食品事業者HACCP対応について

五輪開催までに日本で食品を扱う全事業者をHACCP対応にするという政府の構想については、正直言って零細事業者も含めてHACCP化するって本当にできるのかなぁと懐疑的に見ていましたが、結局落とし所としてこんなふうになるんだねという姿がほぼ固まり、これならできそうかなと思っています。また、元食品メーカー品質管理担当としてHACCPやISOの認証に携わった者としては、これを機に食品衛生管理の水準を上げる一翼を担うべきかなとも思います。今回、業界団体の作成した手引書が重要な要素となりますが、業界団体に属していない事業者さんへの周知は関係者の大変な苦労が今後あろうかと思います。

というわけで最近は食品関係の生産・供給事業者さんに会うごとに説明しているのが以下。

 ただし、魚野が理解している内容と、行政や司法の見解が異なっていたり、
最新の情報をおっかけきれていない可能性はありますので、これらの説明に沿って
対応された結果、何らかの損害を受けたとしても、魚野は一切の責任を負えません
のであしからずご了承ください。必ず関係機関に最終的な確認をとってください。

小規模事業者さん向けに単純化して言えば、以下のとおりです。

  • 取り扱っている食品に応じて、該当する業界団体が作成し、厚生労働大臣が承認した手引書(厚生労働省のサイトに掲載)を参考に、
  • 自主的な衛生管理計画をたて、記録書式を定め、(計画・記録書式とも、例が上記手引書に掲載されています)
  • 日々の運用を記録してください。
  • これを機に、ぜひ衛生管理のレベル向上を図ってください。お金をかけなくてもできることはたくさんあります。
  • まずは厚生労働省のサイトでHACCPのパンフレットQ&A手引書を見てください。

計画のたて方がよくわからない、CCPをどこにするか、どのように管理すべきかがわからない、これを機に衛生管理の水準をあげたいがどうしたらいいか聞きたい、HACCP対応するための支援情報が聞きたい、など、詳しい話を聞いてみたいという方は、各地の保健所やよろず支援拠点(愛知県のよろず支援拠点名古屋豊橋の二箇所)、各都道府県や政令指定都市の農政課さんや,都道府県ごとに設置される6次産業化サポートセンター(愛知県の事業者さんの場合は愛知県6次産業化サポートセンター(ただし、年度初めは未設置。5月くらいから稼働?))や農林水産省が都道府県ごとに設置する農業経営相談所さんなどに相談してください。

0.基本情報

厚生労働省のHACCPのページをご覧ください。特に、Q&A手引書が参考になります。

1.新しい仕組みを知っておいていただきたい事業者さんの範囲

  • 本来のHACCPの思想からすれば、基本的には加工・流通・販売などで食品を扱う事業者さん全てです。従来、食品衛生法上の営業許可が必要なかったような事業者さんも対象になります。
  • ただし、農家さんなど一次事業者さんは、6次産業化や農商工連携など自ら加工したり小売したりしていなければ、管轄が農林水産省となるので、対象外。供給先がどのような知っておくのみでOK。有機JAS認証やGAP認証などをとられたか、とろうとされている事業者さんは、合理的に衛生計画をたて、第三者に説明できるようにするというHACCPの基本的な考え方はこうした認証規格と共通ですので、いろいろ参考になる情報が得られるかと思います。

2.求められるHACCP対応の内容

  • 大手・中規模事業者と小規模事業者では求められる水準が異なります。大手〜中規模は、「HACCPに基づく衛生管理」が行われているか、小規模は、「HACCPの考え方を取り入れた衛生管理」が行われているかを問われます。
  • 大小いずれにしても、自主的に、合理的な衛生管理計画をたて、それを実施し、記録することで、衛生管理の「最適化」、「見える化」をしていこうということになっています。
  • 衛生管理計画をたてる際は、HACCPの7原則・12手順に沿って行うことになります。具体的には商品説明書(扱っている食品がどのような材料を使い、どのように加工し、どのように流通し、どのように消費者が扱うかを想定して記述したもの)、加工プロセスや施設の配置図、商品や従事者の動線図などを準備し、何をどのように管理すれば食品衛生の事故(危害の発生)を防ぐことができるかを決めます。殺菌や密封など特に重要な管理はCCP(Critical Control Point;重要管理点)と呼ばれ、連続監視や記録が求められます。
  • 小規模事業者は、自主的に衛生管理計画をたてよとと言われても、殺菌や危害防止の知識・経験が乏しいことが多く、なかなか自主的にというわけにはいかないと思われます。そこで、今回の制度では、小規模事業者は、業界団体が作成し、厚生労働大臣が定めた手引書を参考にしながら計画づくりをしていくことになります。
  • 新たにHACCPの認証などをとる必要はありません。基本的には、営業許可の新規取得や更新などで、、HACCPに基づいているか、について、後述のような方法で点検するという形です。
  • 中小事業者と大手とでは異なります。小規模事業者の範囲は、まだ最終決定ではないようです(Q&A 問3参照)が、本日(2019年4月6日)時点では、Q&Aに以下のように記載されています。
① 小規模な製造・加工事業者、
② 併設された店舗で小売販売のみを目的とした菓子や豆腐などを製造・
加工する事業者(※1)、
③ 提供する食品の種類が多く、変更が頻繁な飲食店等の業種(※2)、
④ 低温保存が必要な包装食品の販売等一般衛生管理のみの対応で管理
が可能な業種
などを想定しています。
※1:菓子の製造販売、食肉の販売、魚介類の販売、豆腐の製造販売等
※2:飲食店、給食施設、そうざい・弁当の調理等

2 小規模事業者の規模に関しては、事業者団体が作成した手引書で想定され
ている規模等を踏まえ、「食品の製造又は加工を行う者のうち、一の 事業所
において、食品の製造及び加工に従事する者の総数が 50 人未満の者」とい
う案を提示し、「食品衛生管理に関する技術検討会」において検討を進めて
います。

3.対応しなければいけないのか

  • 全事業者対応必須です。ただし、小規模事業者さんが行わなければならない内容は、決して難しいものではありません。恐れず挑戦してください。
  • 小規模事業者の方でも、輸出に挑戦していたり、百貨店・高級スーパーで販売していたり、高級レストランに納品したりしている場合、手引書にかかれている以上の内容を目指されると良いと思います。ブランド化の一環として、是非挑戦してください。

4.支援してもらえるのか

  • 前述の通り、計画のたて方がよくわからない、CCPをどこにするか、どのように管理すべきかがわからない、これを機に衛生管理の水準をあげたいがどうしたらいいか聞きたい、HACCP対応するための支援情報が聞きたい、など、詳しい話を聞いてみたいという方は、各地の保健所やよろず支援拠点(愛知県のよろず支援拠点名古屋豊橋の二箇所)、各都道府県や政令指定都市の農政課さん,都道府県ごとに設置される6次産業化サポートセンター(愛知県の場合は愛知県6次産業化サポートセンターただし、年度初めは未設置。5月くらいから稼働?)や農林水産省が都道府県ごとに設置する農業経営相談所さんなどに相談してください。無料で相談にのってもらえます(但し、保健所はチェックするという立場上、説明されたことについて判断はしますが、助言はしてくれません)。
  • 資金面での支援については、2023年まではHACCP支援法(農林水産省管轄)に基づいた優遇融資制度があります(但し、高度化計画を作成して承認を受けるなど、いろいろな条件があります)。

きれいに制御されている

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ミリ秒単位では,現在出ているような瞬停みたいな現象や前触れのない回転数の低下の原因究明に役立つものでもなさそうですが…。まぁ工学部出身の元エンジニアとしては,こういう技術探求がしたくなるのです。

 

 

VisualStudio を使って Mac で F# の始め方(MSの資料の抄訳)

以下は,Microsoftのこちらのページ(Get started with F# in Visual Studio for Mac)の抄訳。原文は2017年2月13日版。

Visual Studio for Mac IDEは,F# および Visual F# をサポートしている。まずVisual Studio for Macをダウンロードする。この文書は,Visual Studio Community 2017 for Mac を使うことを前提にしている。

F#のインストール

Visual Studio for Mac のインストールでは,F# そのものは,初期設定のままでサポートされているので,特に何かをする必要はない。

コンソールアプリケーションの作成

Visual Studio for Mac で最も簡単なアプリケーションは,コンソールアプリケーションであるので,以下にその作成方法を示す:

  1. ファイルメニューからNew Solution を選択。
  2. New Project dialog が現れ,コンソールアプリケーション用には二種類のテンプレートが表示される。一つは,Other -> .NET にあり, .NET Framework である。もう一つは, .NET Core -> App にあり,こちらは .NET Core を想定している。この文書で書かれている内容に限っては,どちらを選んでもよい。console app を選ぶ際, C# から F# に切り替えてあるか,確認すること。
  3. プロジェクトに名前を設定し,必要なオプションを選択する。オプションの選択に応じて,プレビュー欄に表示されるディレクトリ(フォルダー)構造も変化する。
  4. Create をクリックして完了。F#プロジェクトがソリューションエクスプローラ内に表示される。

コードを書く

Program.fs という名前のファイルを開き,その中身を以下のように書き換えよう:

module HelloSquare

let square x = x * x

[<EntryPoint>]
let main argv =
    printfn "%d squared is: %d!" 12 (square 12)
    0 // Return an integer exit code

上記のコード例では, square 関数は x という引数を一つとり,それを自乗する関数として定義されている。F# は 型推論をするので,x の型を明示しなくともよい。F# コンパイラは,掛け算がどのような場合に有効であるかをわかっているので, square がどのような条件で呼び出されるかという情報を元に,x に適切な型を割り付けることができる。 square 関数名の上にマウスを動かすと,以下の情報が表示されるはずである。

val square: x:int -> int

これは,関数の型シグネチャである。意味するところは,「square は,整数型の引数 x をとり,整数型の結果を出力する関数」である。 square が int を出力すると特定されているのは,掛け算が特定のいくつかの型のみに有効な演算だとコンパイラがわかっているので,このことをもとに,この時点では int を選んでいる。だが,引数の型を別の型,例えば float に変えたとしたら,関数の型シグネチャも自動的に変わる。

別に,main 関数が定義されているが,これは EntryPoint 属性により,F#コンパイラはプログラムの開始位置をここからだと認識する。以下,コマンドライン引数がこの関数に渡され,返り値として(典型的には 0 なのだが,)整数値を出力するC言語タイプのプログラミング言語の作法に則った記述が続いている。

上記の例では,square 関数を呼び出すにあたって,引数に 12 をあてている。F#コンパイラは,これをもって square の型を,int -> int (つまり,この関数は int 型の引数を一つとり,int 型の返り値を出力する)としている。printfn は,フォーマット文字列を使用して,引数を埋め込んだ文字列と改行を出力する,C言語タイプのプログラミング言語ではおなじみの関数と同じ働きをする関数である。

コードを走らせる

メニューで表示されているRun の中の Start Without Debugging を選ぶと,プログラムが開始される。デバッグ機能は無効で,すぐに結果が表示されるはずだ。

Visual Studio for Mac が表示したコンソールウィンドウ内に,以下のように表示されただろうか:

12 squared is 144!

F# インタラクティブウィンドウを使う

F#インタラクティブウィンドウとは,コードを入力するとその場で結果が得られるコンソールウィンドウのことである。これを使うには,先程の square 関数の定義記述部分を選択し,メニューの Edit の中の Send selection to F# Interactive を選ぶ。これにより,選択したプログラムコードが F# インタラクティブウィンドウに送られる。別の方法としては,コード選択の後,右クリックで出てくる Send selection to F# Interactive を選ぶという方法もある。このように表示されるはずだ:

>
val square : x:int -> int
>

この表示は,先程見た square 関数の型シグネチャと同じ内容である。square 関数が F# インタラクティブプロセスの中であらためて定義されたので,以下のように別の値を引数として呼び出すことが可能となった:

> square 12;;
val it : int = 144
>square 13;;
val it : int = 169

上記の例では,関数が呼び出され,その結果が it に束縛され,it の型と内容が表示されている。各行を ;; で締めくくっているが,これは,F# インタラクティブ環境に対して関数呼び出しがここで終了していることを知らせている。F# インタラクティブ環境で新しい関数を定義することもできる:

> let isOdd x = x % 2 <> 0;;
val isOdd : x:int -> bool
> isOdd 12;;
val it : bool = false

上記の例では,新しい関数の isOdd を定義している。 int 型の引数を一つとり,奇数かどうかを判定する関数である。さまざまな引数で呼び出してみよう。関数の中で関数を呼び出すことも可能である:

> isOdd (square 15);;
val it : bool = true

パイプ演算子( pipe-forward operator )を使って,値を関数に流し込むこともできる:

> 15 |> square |> isOdd;;
val it : bool = true

パイプ演算子 ( The pipe-forward operator ) については後述する。インタラクティブ環境について,詳しくは Interactive Programming with F# を参照のこと。

次は…

F#言語の主要機能については,Tour of F# や F# Guide を参照のこと。

OmniFocus 3 for iOS – OmniFocus 2 for Macとのデータ互換性

OmniFocus 3 for iOS のデータがOmniFocus 2 for Mac のデータとして使えるかが公式サイトに出ていたので,自分のために要約。結論としては使える。但し,いくつか注意点あり。元になったOmni社のページ「Using OmniFocus 3 for iOS with OmniFocus 2 for Mac」はこちら。現地時間2018年6月7日版に基づく。 “OmniFocus 3 for iOS – OmniFocus 2 for Macとのデータ互換性” の続きを読む