そのため、インフォテインメントシステムの分野で車の機能を拡張するという課題に直面しました。 本当にしたかっただけです。 車は良いが、古い。 mp3でさえ広く使用されていないときに作成されました。 したがって、多くの現代の便利さが奪われています。 さらに、私の頭の中には追加のアイデアがあり、それを実装して自分の個性を強調することができます。
インフォテインメントシステムは、プログラムが埋め込まれたコントローラーに基づいたデバイスで実行されます。 ここでは、これらのデバイスをコントロールユニットと呼びます。 このような各制御ユニットは、室内温度の維持、座席の位置の調整、音楽やビデオの再生、ナビゲーションなど、独自の機能負荷を担っています。 コントロールユニットのこのセット全体は、相互作用し、運転席と助手席から制御され、診断データを送信する必要があります。 この目的のために、I-busネットワークが開発されました。 その後、技術的に同一のKバスネットワークとそれらのI / Kバスネットワークが登場しました。
Iバスネットワークのアーキテクチャは、「共通バス」スキームに従って作成されます。つまり、ノード（制御ユニット）からのデータパルスは、1点で接続された従来の銅線を介して送信されます。 したがって、ノードは共通の伝送媒体を共有し、データを順番に伝送する必要があります。 このキューまたは優先度の決定方法はわかりませんが、バスが可用性のためにタップされ、ガードインターバルとバスがアイドル状態であることを考慮して、転送を決定します。 「サイレント」状態では、ハウジングに対するバスの電位レベルは7 Vから車両電圧までです。 ドミナントビットがバスに印加されると、電位は2 V以下に低下します。 ノード間の相互作用のビットレートは一定で、9600 bpsになります。 番号はUARTでよく知られています。 しかし、伝送速度に類似性があるだけでなく、I-busの文字の形式はUARTで利用可能なバリエーションの1つに対応しています。 シンボルは、スタートビット、8データビット、パリティビット、ストップビットの11ビットで構成されます。 これらの機能により、UARTまたはRS-232を介してバスに物理的に接続できます。 単純な回路または既製のコンバータを使用して、信号レベルの変換のみを行う必要があります。 この目的には、診断インターフェースで知られているk-lineアダプターが非常に適しています。 物理レベルでは、完全に互換性があります。 ところで、私はそれを使用します。
一般にIバスネットワークの物理層について説明しましたが、マルチレベルOSIモデルのシーケンスに従う場合、リンク層について簡単に説明します。 したがって、より論理的になります。 前述したように、送信には共通のメディアが使用されます。これは時間的に分割され、データはさまざまな宛先に送信される必要があります。 ここで、イーサネットとの類似性を引き出すことができます。データは、送信者アドレス、受信者アドレス、ペイロード（データ）、チェックサムを含むフレームで送信されます。 フレームのサイズは固定されておらず、5〜37文字以内です。 以下に描いたフレーム形式：
ここで、TX IDは送信者アドレス、1文字です。
LEN-フレームサイズから最初の2文字、1文字を引いたもの。
RX ID-受信者アドレス、1文字。
DATA-ペイロード、1〜33文字。
CK SUM-チェックサム、1文字。
受信したフレームの正確さは、チェックサムシンボルによって決まります。 送信者は、受信者が受信したフレームの正確性を検証しません。 おそらく、これは独自のフレームを受信するレベルで行われます。 バスで衝突やその他の障害が発生しなかった場合、送信者は独自のフレームを正しく受け入れ、再送信を試行しません。 World Wide Webで見つけた情報によると、送信者は受信者からの100ミリ秒の肯定的な受信を待っていると言われています。 悲しいかな、実際には私はこれを見ていません。 おそらくこれは、特に重要なメッセージや、より高いレベルのプロトコルに当てはまります。
フレームのペイロードに含まれるものは、次のレベルのプロトコルを指します。 このプロトコルを使用した作業をアプリケーション層に割り当て、アプリケーションで使用することをお勧めします。 もう一度繰り返しますが、LinuxカーネルオペレーティングシステムでのI / Kバスネットワーク相互作用のアプリケーションを探しています。 コントロールユニットの機能は、ユーザースペースのアプリケーションによって実行されます。 オペレーティングシステム内のアプリケーション間の対話を整理することは難しくありません;プロセス間通信（IPC）のメカニズムがあります。 しかし、主なタスクは、それらを車のコントロールユニットのプロセスに接続することです。 例として、コントローラー相互作用ネットワークのより有名なバージョンであるCANを見てみましょう。 Linuxでは、この技術はSocketCANとcan4linuxの2つのプロジェクトで開発されています。 最初のプロジェクトは、ネットワークデバイスドライバーと、フレームの前処理を実行し、ネットワークデバイスをソケットインターフェイスに接続するプロトコルに基づいています。 2番目のオプションは、キャラクターデバイスに基づいています。このプロジェクトの実装の詳細は、私が操作しなかったためわかりません。 しかし、I / Kバス用のcan4linuxアナログはttyドライバーだと思います。 速度、シリアルポートの文字形式を設定するだけで十分です。ttySファイルを読み書きすることにより、データがバスに送受信されます。 もちろん、アダプターによってシリアルポートに接続されている場合。
SocketCANオプションは私にとってより魅力的であるように思えたので、私は同じ方法で進みました。 理由を説明します。 ドライバーは、ネットワークデバイスとネットワークプロトコルの2つの独立した部分で構成されています。 ネットワークデバイスは、ハードウェアとの相互作用やマルチアクセス、ネットワークプロトコルモジュールでのメッセージのフィルタリング、ユーザープロセスとの相互作用の問題を解決します。 アプリケーションはソケットを介してI / Kバスネットワークに接続し、複数のアクセスとフィルタリングのタスクは削除されます。 原則として、ttyデバイスに接続されたサーバーにフィルタリングとマルチアクセスを割り当てて、カーネルに入ることはできません。 一般に、はい。ただし、プロセス間通信なしでは実行できません。これは同じソケットオプションです。 さらに、Linuxネットワークスタックでは、サーバーに実装する必要があるメッセージキューを持つ多くのタスクが解決されました。 さらに、ネットワークデバイスの使用は、オペレーティングシステムを管理するという哲学に調和しています。 たとえば、ifconfigはインターフェイスのステータスを表示、停止、または起動できます。
SLIPベースのslcanベースのI / Kバス用のネットワークデバイスドライバーを実行しました。 シリアルポート上のコンピューター間でIPパケットが送信された時間は見つかりませんでした。 この方法で送信できるようになりましたが、これは関係ありません。 ただし、この方法でI / Kバスフレームを転送することは適切なオプションです。 ttyドライバーは複雑であり、回線制御を介してアクセスできます。 これは、slibusドライバーを作成したときに行ったように、SLIPとslcanで行われます。 作成された回線制御がttyデバイスを介してアクティブ化されると、ibusNネットワークデバイスがシステムに表示されます（Nは0,1,2 ...）。わかりやすくするために、図を示します。 その中で、正方形は緑色でマークされ、その機能はslibusカーネルモジュールによって実行されます。
オレンジ色は、ネットワークプロトコルモジュールの機能を示しています。 繰り返しますが、私は自転車を発明しませんでした。canおよびcan_rawモジュールと同様に、af_ibus_rawモジュールを作成しました。 ロード時に、このモジュールは新しいプロトコルファミリPF_IBUSを登録し、フレームへのフルアクセス用のRAWソケットも実装します。 setsockoptを呼び出すことにより、送信者と受信者の識別子による受信メッセージのフィルターを有効にできます。 デフォルトでは、ソケットはバスからのすべてのメッセージを受け入れます。
1つ問題があると言わざるを得ません。それは、これらのモジュールをロードできるようにするには、カーネルにパッチを適用する必要があるという事実にあります。
それでは、すべての仕組みを見てみましょう。 カーネルモジュールをロードし、slibusに対応する番号で回線制御を初期化し、ibus0ネットワークインターフェイスを上げます。 ターミナルのifconfigコマンドは、次のようなものを表示します。
ご覧のとおり、ネットワークインターフェイスが正常に起動され、トラフィックの統計情報があります。 スクリーンショットを撮る前に、インターフェイスを介してデータを具体的に運転しました。 私は数ヶ月間作られたドライバーを使用しましたが、失敗はありませんでした。 しかし、まだ修正されていない欠陥があります。 後でそれらに戻りますが、私は自由時間があるので今のところアプリケーションに取り組んでいます。
このアプローチの強みは、多くの側面にあります。 オペレーティングシステムで実行されているアプリケーションは、バスに完全にアクセスし、バスを介して相互にやり取りします。 私の車の構成にCDチェンジャーがないとしましょう。 このデバイスをエミュレートするアプリケーションを作成するだけで十分です。 同時に、さまざまなファイル形式とオンラインラジオを再生します。 それから、電話モジュールの人員不足にしたいのですが、それは私が持っていないか、普通の電話モジュールが好きではありません。 ブルートゥース経由でスマートフォンに接続し、音声と情報の入出力を通常の場所で行う別のプログラムを作成します。 または、電子照明器具を使用したゲームなど、独自の何かを作成します。 したがって、アプリケーションは互いに独立して開発され、所有者の要求に応じてインストールおよびアンインストールできます。
以下の図は、ibusdumpとibussendの動作を示しています。 これらのチームは何をするのか、名前から明らかだと思います。 ibusdumpの最後の2行は、ibussendを介して送信したメッセージがバスを介して送信されたことを示しています。
おそらくこれについて説明します。 フレームのペイロードで何が送信され、どのコントロールユニットに対して何を送信するのかについては、後で説明します。