The Swamp of ECU Development

以下から申し込みをお願いします。

https://docs.google.com/forms/d/e/1FAIpQLSeJ2xXwRtezP-qLQEg4eKmIySv-nM6jwXYurKrM4qCPRsBzAQ/viewform?usp=dialog

本稿ではAUTOSARにおけるタスクの制御について説明します．

タスクの周期実行制御

タスクの周期実行はAUTOSARに限らずあらゆるソフト開発において使われ得る実装方法です．これの動作原理とAUTOSAR CPでの設計について説明します．

動作原理

一旦AUTOSARは抜きにして，何かの処理を周期実行する仕組みを考えてみます．これは単純で，何が必要になるかを考えれば良いです．経過時間を測定し，指定時間になったら指定処理(すなわちタスク)を呼出す機構があれば良いことが分かります．このような基本的で精度の要求される制御はハードウェアで備わっていないとおかしいですし，実際にそのようになっています．この時間はタイマと呼ばれ，マイコンのタイマモジュールで管理されます．

AUTOSAR CPでのタイマでのタスクの周期実行

AUTOSARではタイマモジュールをOsTimer，カウンタはOsCounterと呼びます．またOsCounterが指定値になったら指定処理を実行する機構をOsAlarmと呼びます．指定処理はアクションと呼ばれ，ここではタスクの周期実行を考えるので，OsAlarmのアクションにはタスクを実行させます．このアクションの名前はOsAlarmActivateTaskと呼ばれています．

機能安全についてかじりたく調べています．

https://www.youtube.com/watch?v=8o3JaVR1w1Y

Driverのうち電源側にあるものをHigh Side Driver，グラウンド側にあるものをLow Side Driverといいます．次の図のようにDriverおよびLoad(ここではBlub)にかかる電圧に違いがあります．

米国ミシガン州に駐在をした時のメモです．住んでみれば分かることなのですが，事前に知っておくとトラブルを回避できたり金銭的に有利なことがあります．そこで失敗するのも経験や楽しみではありますが，より円滑に駐在準備を進めたい人向けに紹介します．

渡航してからの流れ

渡航後に実際に行った流れを次の表にまとめました．物件探しや内覧のアポイントメントなどを渡航前に行うなど手際よくやれば7-10日くらいに収まりそう．

0日目	・空港到着 ・会社手配のタクシーでホテルへ
1日目	・会社にてオリエンテーションの後，車入手 ・会社にて必要手続きを色々実施 ・銀行にて手続きをして，銀行口座の入手 (住所は会社名義) ・ホテルにて私用スマートフォンのeSIMを契約 (即時利用可能) ⇒ (1) 参照
2日目	・所定センターに向かい社会保障番号(SSN)の手続き ・アパート探しと電話でのアポイントメント ⇒ (2) 参照
3日目 – 7日目	・物件の内覧，最終決定 (入居日決定)
8日目 – 10日目	・物件の審査期間 ・審査終了後，契約時書類や必要金額の受領 ・必要金額が全く足りなかったので会社から急遽の融資申請
11日目	・銀行でCashier’s Checkの購入 (私の場合は$3,000程度でした) ・クレジットカード申請 (住居が決まったため) ⇒ (3) 参照
12日目	・入居

(1) 現地での通信環境 (格安SIMなど)

スマートフォン向けと自宅の通信環境を用意するガイド．

スマートフォン向けの通信環境はAT&TまたはVerizonが一般的．立ち位置はDocomo, Au, Softbank．格安SIM向けの扱いのものはMinto Mobileなどがあります．料金は契約プランで異なりますが，2023年時点で4G $15/10G $20/15G $25/UNLIMITED $30．今の時代はeSIMが使えるため，物理SIMは不要で，契約後にすぐに使えるようになります．住所の入力欄があるがホテルの住所とした．

(2) 住所探し

アパートについて

日本のアパートというと，高くても3階建てでちょっと古い1棟の集合住宅を想像します．一方でアメリカのアパートは階層は2階程度だが，何棟か点在した建物群及びその敷地(Apartment Complex)を指すようです．例えばNovi周辺のSaddle Creek (https://www.saddlecreekapts.net/) の地図を引用します．

近隣住民は全て同じアパートの居住者となるため，アパートの規模によるが定期的なイベントなどが開催されることがあります．

住居の探し方

1. Apartments.comから目ぼしい物件を見つける．
2. Apartments.com経由でのメッセージ(メール)か，もしくは電話してアポをとる．メッセージは返信がとても遅いことがあるので，電話でのアポを推奨．
3. アポをとった先のアパートの敷地内にあるLeasing Centerに出向く．

住居探しと契約の注意点

• Furnishedの物件を探しも電化製品以外の家具はついていない．Apartments.comなどの写真は物件にもよるが基本全て見本．家具は現地購入するか日本から送ることになる．なお家具レンタル(https://cort.com/)は高いので長期滞在するなら非推奨．

• 契約時の支払いはCashier’s Check(現金購入)が必要 ($1500 – $3000程度)．アメリカはカード社会だが慣習上，契約時の支払いに限りCashier’s Checkの購入が必要で，カードでの支払いはできない．Cashier’s Checkは銀行で現金購入する．但し持ち込みするには多い額だし，日本の口座からの送金は手数料や日数がかかる．そこで会社からの融資制度があれば融資を受けることを推奨．振込みに日数がかかるかもしれないので，早めが良いと思います．

• お金にシビアなら家賃以外でかかるコストと家賃補助の範囲とを確認．通常，家賃以外に保険料($20程度)，駐車料金($10程度)，ゴミ廃棄手数料($20程度)，その他手数料(RentPlusと呼ばれる)($10程度)などがかかる．会社によってはこれらの費用も負担してくれる．例えば家賃補助が$1400であれば，家賃は$1300程度にしておき，合計$1360のため，全額会社負担とできる．また通常家賃は翌年に上がるため，この分の余裕をもっておくと更に良い．

(3) クレジットカード

結論だけ書くとANA USAまたはJAL USAのクレジットカードを作成して，後から他に乗り換えるのが一般的のようです．

日本のクレジットカードはレート換算上少し不利なためアメリカのクレジットカードを作成することになりますが，日本人は通常アメリカでのクレジットヒストリーがないため作成できません．ですが日本人駐在者向けであるANA USAまたはJAL USAクレジットカードであれば作成できます．ここで1年くらいヒストリーを貯めてから他に乗り換えるのが一般的なようです．

Youtubeでバッテリのコンタクタ制御について学んでいます．

コンタクタはスイッチです．電気自動車においてはバッテリとモータ制御装置(Inverter)の間に配置して，バッテリに繋いで電源を供給するかどうかの制御に主に使われます．電気自動車のバッテリは高電圧のため正しく制御することが重要です．

コンタクタは回路内でマイナス側(Negative Contactor)，プラス側(Positive Contactor)の両方に配置します．これに加えて安全のためPre-Chargeコンタクタというのもあります．

Pre-Chargeコンタクタ

Pre-ChargeコンタクタはPre-Charge回路においたコンタクタです．
次の動画のおじさんに教えてもらいました．

Pre-Charge Circuits for Lithium-Ion Battery Packs

Pre-Charge回路はメイン回路を繋ぐ前に繋ぐ回路で，メイン回路での突入電流(Inrush Current)の影響を減らすための仕組みです．突入電流とは回路を繋いだ時に3相インバータのようなコンデンサ機器が繋がっていると，それを充電しようと通常より多い電流が流れてしまうことです．これによりコンタクタは溶着(weld)して閉じることがあり危険です．

動画ではPre-Charge回路の抵抗値がいくつの抵抗を使い，どの程度の時間充電するのが良いかも解説されていました．

また，Pre-Charge回路をつける位置ですが，どの動画を見てもプラス側にあるようでした．動作上どちらが良いか気になった調べてみたところ，次の資料はマイナス側にも取り付けられるとのことでした．

The precharge circuit is commonly found on
the positive leg, but it could just as easily be installed on the negative leg.

https://www.sensata.com/sites/default/files/a/sensata-how-to-design-precharge-circuits-evs-whitepaper.pdf

コンタクト制御の順番

上記の記事にてコンタクタ制御の順番についても紹介されていました．

ISO15765-2は大きいデータを分割し，下位のプロトコルで許容できるサイズに分割してメッセージを送受信するためのトランスポート層のプロトコルです．

車両においては主に診断に用いられます．例えば診断ツールとECUがCAN-FDで繋がった環境で，診断ツールからECUに対して「故障一覧」コマンドを送付しその応答をしたとします．そのデータは200バイトとか，大きいサイズになるかもしれない一方で，CAN-FDの最大サイズは64バイトです．この時に，この200バイトを適当なサイズに分割して送受信する必要があり，その時のやり取りを規定したプロトコルがISO15765-2です．

なおAUTOSAR CPにおいては本プロトコルはCanTpで処理されます．

はじめに

本稿ではAutosar CPのCanIfとCANのバッファ機能について紹介します．

CAN Diverは通常Canと表記されますが，混乱防止のためCanDrvと表記します．CanIfの上位モジュールは，Upper Layerとして表記します．

バッファに関する用語の定義

Hardware Object (HWO)	CAN Controller内にある1つのPDUに対応するRAM領域． 主に以下の4つの設定項目が存在する: 　- ID 　- データ長 　- Handle Type (FullCAN or BasicCAN) 　- Object Type (Transmission or Reception)
FullCAN	HWOの種類の1つ．1つのHWOに対して1つのPDUを割当てる．
BasicCAN	HWOの種類の1つ．1つのHWOに対して複数のPDUを割当てる．
Hardware Transmission Handle (HTH)	送信に用いるHWOを指すポインタ．1つのPDUに対して複数のHWOを割当てることもできる(SWS_Can_00403)．
Hardware Reception Handle (HRH)	受信に用いるHWOを指すポインタ．

Autosarより引用して参考図を示します．次の図では8個のHWOが存在し，4つのHWOが4つのHRHと，2つのHWOが1つのHTHと割当たっています．この構成はOuter Priority Inversionを回避するために用いられます．

受信の際も同様です．

なお割当てる数はHTH, HRHにおいて，割当てるHWOの数はCanHwObjectCountと呼ばれます．

送信フロー

基本的な送信フロー次の通りです．

1. UpperLayerは，CanIfに対して，CanIf_Transmitを呼出す．渡す情報は，CanIf上のIDととPduTye*の2つ．
2. CanIfは，CanIf上のIDから，該当するHTHを探す．
3. CanIfは，CanDrvに対して，Can_Writeを呼出す．渡す情報は，HTHとPduType*の2つ．
4. CanDrvは，HTHから書込むMailboxを探し，データを書込む．書き込みに失敗した場合，CAN_BUSYを返す．
5. CanIfは，Can_Writeの返戻値がCAN_BUSYであれば，バッファリング処理を行うことがある (当該節を参照)

CanDrvnの処理は割込み(Interrupt)でもタスク処理(Polling)でも処理できます．割込みの時のシーケンス図を，Autosar仕様から引用して示します．

送信完了通知

送信が完了すると，CanDrvは送信完了通知(TxConfirmation)を受取り，CanIfに通知します．CanDrvの送信完了通知の受取りは，割込み(Interrupt)かタスク処理(Polling)かを選択することができます．割込みの時のシーケンス図を，Autosar仕様から引用して示します．

送信完了通知を利用すれば，CanBusのレベルで正しく送信されたかを知ることができます．

このため，CanIfのコンフィグでは各フレームに対して，どのUpper Layerに対して送信完了通知を行うかや，その呼出し関数を指定することができるようになっています．

補足. CANの物理層のプロトコルでは，送信者がAckSlotをRecessiveにしておいて送信しておき，その部分を受信者がDominantに書換えることによって，受信者のうち少なくとも誰か一人が正しく受信したことが分かる仕組みとなっていました．送信完了通知はこれを利用します．従ってここでの「送信完了」とはAckSlotがDominantとなった，即ち受信者のうち誰か一人に正しく受信されたことことを意味します．

送信フレームのバッファリング

CanDrvのMailboxの書込みはCAN_BUSYで失敗するケースがあります．その原因は，例えば当該Mailboxに書込む瞬間において，より優先度の低いIDが多数あるケースです．この時，あるフレームに対する1回目のCan_Writeでは，該当するMailboxに書込まれるが，そのフレームはチャネルがBusyのため送信されず，同じフレームに対する2回目のCan_Writeでは，1つ目のフレームがまだ送信中の状態のためCAN_BUSYとなります．但しCAN Controllerによっては，Mailboxが上書きができ，CAN_BUSYとならないケースもあるので注意が必要です．

Can_Writeの返り値がCAN_BUSYであった時，CanIfは当該フレームがBasicCANに割当てられていれば，CanIfのバッファ(CanIfTxBuffer)にバッファリングを行います．なおバッファに既に前のフレームが存在する場合，最新のものに上書きされます．

バッファリングされたフレームの送信は送信完了通知の時に行います．「送信完了通知」の節で述べたように，送信完了通知は割込み(Interrupt)かタスク処理(Polling)が選べますが，Interruptの時の例をAutosar仕様書から引用して示します．

BasicCANに割当てられたフレームのバッファリングの具体例

1つの同一のBasicCANに割当てられたフレームA, Bが存在し，Upper Layerがシグナルの内容を変えてA1, B1, B2と送信要求を行うとします．この時，他の優先度の高いフレームによってバスが占有されているとします．

1. A1送信時のCan_Writeの処理では，MailboxにA1を書込み，正常終了する．但しバスは占有されているため，A1はバス上に送信されない．
2. B1送信時のCan_Writeの処理では，MailboxにまだA1が残っているため，CAN_BUSYとして応答する．
3. CanIfはB1をCanIfTxBufferに保存する．
4. B2送信時のCan_Writeの処理では，MailboxにまだA1が残っているため，CAN_BUSYとして応答する．
5. CanIfはB2をCanIfTxBufferに保存する．B1は上書きされる．

バスの占有が解除されると，ECUはA1, B2の順にバス上に送信する．

FullCANに割当てられたフレームのバッファリング

FullCANに割当てられたフレームは，CanIfTxBufferが存在しません．このため，Can_Writeの戻り値がCAN_BUSYとなった場合は，バッファリング処理は存在せず破棄します．

但しMailboxには保存されるため，他のフレームによるバスの占有が起きた場合，その解除後にはMailboxのフレームのみ送信される形となります．この例を次に示します．

FullCANに割当てられたフレームCが存在し，Upper Layerがシグナルの内容を変えてC1, C2, C3と送信要求を行うとします．この時，他の優先度の高いフレームによってバスが占有されているとします．

1. C1送信時のCan_Writeの処理では，MailboxにC1を書込み，正常終了する．但しバスは占有されているため，C1はバス上に送信されない．
2. C2送信時のCan_Writeの処理では，MailboxにまだC1が残っているため，CAN_BUSYとして応答する．
3. CanIfはC2を破棄する．
4. C3送信時のCan_Writeの処理では，MailboxにまだC2が残っているため，CAN_BUSYとして応答する．
5. CanIfはC3を破棄する．

バスの占有が解除されると，ECUはC1のみバス上に送信します．

受信フロー

CanDrvの処理は割込み(Interrupt)でもタスク処理(Polling)でも処理でき，フレームによって切替えることもできます(Mixed)．Pollingでの処理フローは次の通りです．

1. CanDrvは，CanIfに対して，CanIf_RxIndicationを呼出す．
2. CanIfは，UpperLayerに対して，UpperLayer_RxIndicationを呼出す。

Pollingでのシーケンス図を示します．

はじめに

CAN，CAN-FD通信にあたり，コントローラは通信相手のコントローラとビットタイミングを同期する必要があります．このためにコントローラは1ビットあたりのタイミングを元に，これをより細かい単位に分解して定義して，所定の方法で調整します．どれくらい細かい単位で管理できるかは，どのクロック数で動作するかという話に他なりません．そこで本稿ではビットタイミングの調整方法と，必要なクロック数について説明します．

なお本稿では特に記載がない限り，コントローラとはCAN，CAN-FDコントローラの両方を指すものとします．

管理する時間の最小構成

コントローラ内で管理する時間の最小単位をTime Quantum(TQ)と呼びます．コントローラは入力クロック数に対してBaudRate Prescaler(BRP)で分周したものを実際に使用するクロック数として扱います．TQはその1クロックあたりの時間です．

例を示します．コントローラへの入力クロック数が40 MHz，BRPが2であれば，実際に使用するクロック数は20 MHzであり，従って1TQ = 0.5 usとなります．

1ビット時間の構成

コントローラ内では，1ビットの時間をより細かい4つのセグメントに区分します．これらをSYNC_SEG, PROP_SEG, PHASE_SEG1, PHASE_SEG2と呼びます．その単位はTQです。SYNC_SEGのみ1TQであると定義されています．

それぞれのセグメントの役割は次の通りです．

名称	説明
SYNC_SEG	・バス上の各ノードの同期がとれているかの判定に使われる ・各ビットの立下りがSYNC_SEGに入っていれば同期がとれていると判定
PROP_SEG	・ネットワークの物理的な遅延時間を補正する期間
PHASE_SEG1 PHASE_SEG2	・PHASE_SEG1とPHASE_SEG2の境界がサンプリングポイントとなる

なおCAN-FDにおいては調停とデータ転送の2種類の転送モードがありますので，ビットタイミングはそれぞれ別々で定義されます．

同期タイミングの調整

上述の通りコントローラはSYNC_SEGの立下りで同期を判断します．SYNCが同期されなかった時に，このタイミングの調整に使用するパラメータをSJW(reSynchronization Jump Width)呼びます．同期方法は以下の通りです．

• ビットの立下りがSYNC_SEGより後の時，PHASE_SEG1にSJWを増加
• ビットの立下りがSYNC_SEGより前の時，PHASE_SEG2からSJWを減少

1ビット時間の構成と必要クロック数

通常CANの転送レートは500 KHzです．また通常CAN-FDでは調停に500 KHz、データ転送には2.0 MHzを転送レートに使用します．

先述の通り，コントローラではこれらの1ビットあたりに対して，より細かいTQに分解して管理します．従って(プロトコルの転送レート) * (1ビットあたりのTQの数) のクロック数が最低限必要となることが分かります．

具体例

CAN-FDの調停、データ転送時における適当なビットタイミングの設定例を示します．コントローラへの入力クロック数は40 MHzとします．

項目	調停	データ転送
転送ビットレート	500 KHz	2.0 MHz
PROP_SEG	23 TQ	5 TQ
PHASE_SEG1	8 TQ	2 TQ
PHASE_SEG2	8 TQ	2 TQ
1ビットあたりの時間 (TQ)	40 TQ	10 TQ
1ビットあたりの時間 (us)	80 us	5 us
サンプリングポイント	80 %	80 %
最低限必要なクロック数	20.0 MHz	20.0 MHz
PBR	2	2

MutationObserverではDOMのイベントを検知し指定のコールバックを呼出すための組込みオブジェクトです．

https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

MutationObserverは変更を検知しないものがあるようで詰まりました．

例えば次のコードです．

<!DOCTYPE html>
<html>
   <head></head>
   <body>
      <div id="testId" class="testClass">testText</div>

      <script>
         var targetNode = document.getElementById("testId");
         console.log(targetNode);
         var observer = new MutationObserver((mutations, observer) => {console.log(mutations);});
         observer.observe(targetNode, {attributes: true, childList: true, subtree: true} );

         targetNode.innerHTML = "foo";
      </script>
   </body>
</html>

Chrome97において，上記コードでのMutationObserverは次の挙動になりました．

1. コード内のinnerHTMLの変更を検知する．
2. デバッガ上でdivのclassを変更した時，その変更を検知する．
3. デバッガ上でdiv内の文字列(testText)を変更した時，その変更を検知しない．

Javascriptを久々に書いてますが，AJAXの時代はとっくに終わったようで色々と新しいです．

非同期通信にはXMLHttpRequestではなくPromiseパターンのFetchが使われるようでした．これについてメモします．

Promiseの状態とメソッド呼び出し

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

処理の説明

対象とするコードは次の3行です。

fetch('http://theater.com/movies.json')
.then(response => response.json())
.then(data => console.log(data));

　1行目．fetch関数により指定URLを入力として，Promiseオブジェクト(状態: Pending)を得ます．指定URLのアクセス及びダウンロードの処理は非同期で行われ，結果に応じてPromiseオブジェクトを変更します．成功すれば状態をFulfilledとして，fulfillment valueにHTTP Response Bodyが格納されます．

　2行目．FetchのPromiseオブジェクトに対して，thenメソッドによりFulfilledになった時の処理を予約し，新しいPromiseオブジェクト(状態: Pending)を得ます．Fulfilledになった時の処理は，返ってきたResponse Bodyに対してjsonメソッドを使用し，結果に応じてPromiseオブジェクトを変更します．成功すればFulfilledとして，fulfillment valueにJSONの値が格納されます．なおreturn文がないのはアロー関数の記法で省略されているため．

　3行目．2行目のthenメソッドの戻り値のPromiseオブジェクトに対して，thenメソッドによりFulfilledになった時の処理を予約します．Fulfilledになった時の処理は，JSONフォーマットのResponse Bodyを出力するだけです．

　以上のように非同期で行う処理の内容を，同期処理で予約していくような形で使用します。