Ernie_Legのブログ一覧

たまにはユルいネタを。

私のレガシィは、現行モデルのNAエンジン搭載車では3.0Rと並びビルシュタイン・ダンパーが使用されているグレードである。私がNAエンジン搭載グレードのなかからこのモデルを選んだ理由は、ほとんどコレにあった。カヤバの純正ダンパーもなかなかいい味をだしているという話ではあったが、折角レガシィに乗るのだから、黄色いダンパーに乗ってみたいなぁー、と思った訳だ。

で、ビル足使用の証として例のエンブレムが付いてくるのかと思ったら、レガシィはこの４代目からグレード・エンブレムを廃止した（オプション扱い）そうで、しかもＥ型のオプションカタログにはビルシュタイン・エンブレムの紹介すら無くなってしまった。補修部品扱いで購入は可能のようだが、スバル純正品はビルシュタイン純正品より少し小さめで、しかも最近、ビルシュタイン自身がダンパーだけでなくスプリングも扱うようになって、総合サスペンションメーカーとなった証としてシンボルマークを変更したそうで、折角だからその新ロゴのエンブレムを付けてみたいと思った。あまりゴテゴテとドレスアップするのは好きではないのだが、このロゴだけは、私にとって格別なのだ。

ということで、少し前に某所より入手してあったものを、このたびようやく貼り付けることができた。すぐに貼り付けられなかったのはちょっとした小細工を考えていたからだが、それも併せて、近々フォトギャラリーの方にでも画像をアップしてみたい。

SSMのいじり方をいろいろ検討してみたのだが、結局、ATの動作をモニタするにはAT制御ユニットであるTCMという装置と通信をする必要があるということが分かり、そのためにはどうやってアクセスすればいいのか分からず断念。でも、ECUをモニタするSSMプログラムを自分で書けるくらいには勉強したつもり。こんなの、どうやって解析してプロトコルを見付けるんだろうな・・・・結構凄い。人柱で討ち死に（笑）したチャレンジャーもさぞ沢山いらっしゃることであろう。そういった多くの人の努力の上に、こういったプログラムは成り立っている訳で、ただただ有り難いばかりである。

で、本当は何をやりたかったかというと、アクティブトルクスプリットAWDの走行時の動作を解析したかったのだ。トルクを伝達する多板クラッチを制御するソレノイドのdutyがSSMでもモニタできる筈なのだが、上記のごとくTCMにアクセスしないといけないようなので、いまのところどうにもならない。

ということで、この件は物理的手段（爆）に訴えることにした。といっても大したことではなく、TCMから出力されているMP-T制御ソレノイド行きの制御信号を電圧計でモニタするのである。SSMが無い場合の診断方法として整備マニュアルでも認められている方法らしいので、それを拠り所にチャレンジである。

調べ方をここに書くと長くなるのでそれはいずれ整備手帳の方に書くことにして、とりあえず結果の解釈だけ報告しておく。私の結果の解釈が正しければ、通常時の公称トルク配分F:R=60:40 というのは概ね正しいようである。なぜ「概ね」かというと、モニタしているものはトルクそのものではなく、多板クラッチをドライブしているソレノイドの負荷量（電圧）だからである。巡航時のソレノイド負荷は概ね50%前後で、フルに働いている＝完全直結状態からすればかなり“緩い”結合ではあるが、多板クラッチによる結合であることを考えると、まぁこんなものなのかな？というところであった。

加速時にはさらにリア側にトルクが配分されるが、アクセルを結構派手に踏んでも、ソレノイド負荷は60～70%程度までであった(１速での、停止状態からの加速の場合を除く)。マックスと思われる電圧(～4V)に達するのは一瞬だけで、通常の走行時は常にクラッチが半結状態となっているようだ。しかし、逆に街中での低速コーナリングでは負荷が減少することもなく、ほぼ常時50%程度のソレノイド負荷でAWD状態を維持しているようである。ということで、以前の記事に「(曲がるときは)FF車のような挙動と思えばいい」と書いたのは言い過ぎで、曲がっている間もやはりAWD車だと思って運転しなければいけないということが解った。

また、もう一つの新たな発見として、強制FF状態ではソレノイドには全く電圧が掛からない、ということが分かった。以前のモデルでは強制FF状態にするとソレノイド負荷が100%になる仕様だった筈で、つまり、ソレノイドの動作方向がいつのまにか逆になっているようだ。

現行モデルの方式はある意味合理的である。例えば、万一ソレノイドが故障（断線など）した場合でも、FF状態にはなるがとりあえずの走行に支障は出ない。ところが以前のモデルの場合では、ソレノイドが故障したら常時“完全直結”状態になってしまい、タイトコーナーブレーキング現象などが発生して走行に支障が出ることになるだろう。

そういえば、（前の記事にも書いたように）以前のモデルではタイヤチェーン装着時には強制FF状態にしなければならなかった、という話を聞いたが、今のモデルでその必要がないのは、この動作モードの違いによるものかもしれない。以前のモデルだと、回転差を吸収するためにはソレノイドが常時フルに近い状態で働き続けるような状態になってしまうが、現行モデルでは逆にソレノイドが働かない方向の動作となるので、問題が出にくいということではないだろうか？もっとも、以前のモデルで強制FF状態にすると、ソレノイドには常時フルの負荷が掛かることになるのだが・・・。今ひとつよくわからないところではある。

ところで、ここまでに書いたことがもし正しければ、これはある種の「設計思想の逆転」を示している気がする。というのも、以前のモデルは“デフォルトがＡＷＤ，ソレノイド動作時にＦＷＤ”という設計であるのに対して、現行モデルでは“デフォルトがＦＷＤ，ソレノイド動作時にＡＷＤ”という設計だからだ。中間的な状態ではどちらも大差はないが（そしてこのＡＷＤ機構はほとんどその状態で動作しているようだが）、デフォルトの状態が真逆というのは基本的な設計変更である。もちろんおそらくは、様々な問題を検討した結果なのであろう。

もともと初期MP-Tの時代から、多板クラッチはATの油圧で動かしていた（だから、アクセルオフで油圧が下がると自然にクラッチが抜ける→トルクが抜けることでＦＦ状態になるという仕組みだったそうだ）。油圧を使ってクラッチの結合状態を制御しているのは今でも変わっておらず、ソレノイドの動作を電子制御にしたというだけのことなので、この変更はあくまでもソレノイドバルブの動作方向の変更に過ぎないが、細かいところでチョコチョコと仕様変更がなされているのは興味深い。

いずれにせよ、もう少し測定を続けて様子をみてみたい。

スバル・セレクトモニタ（SSM）の仕様を調べていたら、段々混乱してきた。

現在のところなんとかlogは取れている Enginuity の logger、一瞬だけデータが取得できるのにすぐ固まってしまう ECU Exproler、これら以外のプログラムではいまのところ全くデータが取得できない。実はこれ、SSM の場合はレベル・コンバート(TTL→RS232C)だけで済む（あとはＰＣ側で制御する）のだが、一般的なOBDプログラムの場合は、例えばこんなチップを使ったり(旧OBD-II信号の場合)、CAN-BUSだとこんな装置を使ったりして接続する必要があるらしい。うーん、ちょっと勘違いしていた・・・・。

ということで、EnginuityとECU Exprolerのソースを見比べながらどういう通信をしているのか見ていたのだけれど、いまのところ核心部分にたどり着けていないため、timeoutしてしまう理由は不明のまま。しかも、前者はJavaだし後者はC++と、どちらもあまりよく知らない言語だし・・・。しかし、loggingする項目をデフォルトから増やしたり減らしたりする方法はだいたい掴めたので、ちょこっといじりながら調べてみたい。

コネクタのピン配列等については、自分のメモ書きの意味で整備手帳にまとめてみたが、こんな感じで合っているのだろうか？

トライアルはまだまだ続く・・・。

整備手帳に、街路走行状態のlogを解析したものをアップしておいたが、簡単にまとめておくと、

１）ATは、ドライバーのアクセル要求量や（エンジン回転数だけでなく）エンジン負荷から適切なギアを選択しているようにみえる。
２）太いトルクが立ち上がってくると思われる2000～2300rpm付近では、エンジン負荷によっては４速より３速の方が効率よく使える領域がある。

の２点が私にとっての“発見”であった。逆に言えば、やはり最近のAT制御ロジックはよくチューニングされていて、ECUと協調して最適な制御がなされているものだとつくづく感心する。ドライバーがギアの制御面で燃費やパフォーマンスを改善する余地は、ほとんど残っていないといっても良いくらいである。ドライバーができることは、やはり「余計な加速をしない」「使ったエネルギーはなるべく使い切る」「近くの用事は歩いていく（笑）」などの、“本質的な省エネ”だけなのかもしれない。

その反面、エンジン負荷量をリアルタイムにモニタできるわけではないＭＴ車の場合は、省燃費に適切な回転数とギアの選択には多少の「腕」を必要とするだろう。乗り手次第でどうにでもなる余地が、かなり残されているのだ。しかも、トルコンでトルクを増幅伝達するＡＴ車とは異なり、エンジンの使い方がよりピーキーになるＭＴ車の場合は、特に加速時のギア選択が省燃費運転に効いてくるものと推測される。メカの効率でいえば、ＡＴよりＭＴの方が１０％程度は有利な筈だが、使い方を誤れば、そのアドバンテージはすぐに帳消しになるだろう。その意味では、ＭＴ車の方が「運転し甲斐がある」のかもしれない。

どうせ人柱だと思ってあまり深く考えずにケーブルを調達してしまったのだが、ECUとの通信があまりうまくいかないのはやっぱり何かおかしいぞ？と思い、OpenECUのForumを覗いてみたら、とんでもないことが発覚。レガシィは2007年モデルから、ODB-IIポートの仕様がCAN対応のものに変更されていたのだ。

互換性維持のためか、従来のSSM用信号ピンも残されてはいるようだが（だからloggingはかろうじて出来たのだ）、少なくとも調達したケーブルそのままではおそらくECUのreflashなどは出来ないだろう。なんとかloggingが出来るのも、実は片肺飛行のようなものなんだな・・・・。

しかも、いくつかのloggingプログラムを試したが、結局使えたのはEnginuityのloggerだけ。一通りのlogは取れるから文句はないのだが、どうやらCOMポートの制御がシビアで、Tactrix製ケーブルを使うことを前提としているEnginuityしかうまく動かない、ということみたいだ。まぁ、動くだけマシか・・・実はケーブルの不良も疑って、ちょっとバラし掛かったのだけど、ガッチリ組まれていてとてもばらせそうになかったので途中で諦めた。お陰でケーブルは既にキズモノになってしまった。（悲）

とまぁ、思っていた以上にloggingの段階で既に苦戦しているのだが、とりあえず燃料消費情報も一緒にloggingしたデータをちょこっと解析してみた。グラフを見ながら説明した方が分かり易いと思うので、詳しくは整備手帳に書くことにしたい。