バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
たぶん最終回。
簡単に振り返りをやってみる。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
最終回?
というわけで、車両診断通信の話はおおよそ終わり。
ということは今回が最終回か。
いや、しかし100回も続くとは思わなかったなー。
通信上のレイヤーを一個ずつ語っていったからねー。
シミュレーションもしたし。
シミュレーションとはいえ、
実際に動かすとイメージ湧きやすいよねー。
簡単に振り返り
で、振り返ってみるとどうだった?
うーん、
CAN自体の難しさと、診断通信としての難しさと、診断サービスとしての難しさがミックスされてた感じだねー。
一応レイヤーとして分かれてはいるんだけど、
どうしても下位レイヤも意識してないといけないというか・・・。
そうだね。
TCP/IPとかと比較すると下位レイヤの都合が上位に強く影響はしてるかもねー。
診断サービスあたりになると、それに加えて実際の運用まで考えることになるから、さらに難しい。
診断サービスはやりたいことそのものなんで、
車両ライフサイクルを密接なことは多い。
開発中はもちろん、生産時、市場、廃棄なんかでも使用されるしね。
そうそう。
同じ車両通信でXCPってのがあったと思うけど、
こっちは開発特化でまだ分かり易いんだけど、
車両診断通信は範囲が一気に広がった感があったよ。
XCP関連のシリーズ
ちなみにXCP関連の話は別のシリーズのここらへんでやってたね。
一旦終了
(XCP関連も随分長いシリーズだったんだな。まぁ今回のシリーズは更に輪をかけてヤバイ感じだったけど。)
何はともあれ、一旦このシリーズも終了!!
新ネタ出てきたら、続きがでるかもしれないけど。
まとめ
まとめだよ。
- 簡単に振り返り。
- 車両診断通信はユースケースが多岐に分かれるという特性上話もその分広くなる。
- 反面。XCPなどは開発に特化している。
- 本シリーズは一旦終了。
バックナンバーはこちら。
コメント