> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md).

# Komunikasi dalam kendaraan: CAN, FlexRay, dan MOST

Jaringan di kendaraan menggunakan CAN, FlexRay, MOST, dan Ethernet untuk komunikasi ECU. Setiap protokol menargetkan kebutuhan kecepatan, keandalan, dan bandwidth yang berbeda.

CAN, FlexRay, dan MOST adalah semua protokol komunikasi otomotif yang digunakan untuk menghubungkan electronic control units (ECUs), transmission control units (TCUs), dan body controlled modules (BCMs) pada kendaraan:

* **CAN**\
  Protokol berbasis pesan yang awalnya dirancang untuk menghemat tembaga dengan memultiplex pengkabelan listrik di mobil. CAN memiliki bandwidth sekitar 125 kpbs.
* **FlexRay**\
  Protokol komunikasi serial berkecepatan tinggi, tahan galat, dan deterministik yang dapat mentransfer data dengan kecepatan hingga 10 Mbit per detik melalui dua kabel berpilin. FlexRay sering digunakan dalam aplikasi kritis keselamatan, seperti modul power train. Muatan FlexRay, atau frame data, dapat memiliki panjang hingga 127 kata (254 byte), yang lebih dari 30 kali lebih panjang daripada muatan CAN.
* **MOST**\
  Standar bus untuk jaringan multimedia kendaraan yang memungkinkan transfer audio, video, dan data berkualitas tinggi. MOST tersedia dalam tiga kecepatan transmisi: MOST25, MOST50, dan MOST150.

CAN (Controller Area Network) saat ini merupakan jaringan dalam kendaraan yang paling banyak digunakan. Namun, dengan pengembangan berkelanjutan dalam kendaraan otonom dan teknologi terkait, ada permintaan tinggi untuk bandwidth dan konektivitas yang lebih besar. Dalam dokumen ini, kami secara singkat menjelaskan CAN dan opsi konektivitas kendaraan lainnya, termasuk CAN nirkabel, MOST, FlexRay, dan ethernet otomotif.

## Bus CAN: beberapa prinsip di baliknya

Dalam arti luas, CAN-bus (Controller Area Network-bus) sebenarnya adalah seperangkat standar yang memungkinkan berbagai perangkat untuk berkomunikasi satu sama lain. Ini adalah sistem bus serial asinkron (bergeser waktu), yang dikembangkan pada tahun 1983 oleh Robert Bosch GmbH dengan tujuan menghubungkan electronic control units (ECU) pada kendaraan bermotor.

CAN dibagi menjadi berbagai lapisan, mengikuti model ISO/OSI untuk mencapai fleksibilitas dan transparansi desain. Untuk komunikasi dalam praktik, bus CAN menggunakan dua kabel khusus: CAN low dan CAN high, yang melaluinya pengendali CAN terhubung ke semua komponen jaringan. CAN memungkinkan menggantikan pengkabelan yang cukup kompleks dengan bus dua kabel. CAN menggunakan sinyal diferensial, yang membuatnya lebih tahan terhadap derau, dengan dua keadaan logika: resesif dan dominan. Saat ini bus CAN digunakan hampir di semua bidang, mulai dari mesin kopi hingga [pengelolaan Armada](https://navixy.com/en/fleet-management/) dan aplikasi antariksa. Selanjutnya kami secara singkat menjelaskan prinsip kerja bus CAN.

Protokol komunikasi CAN ISO-11898: 2003 menjelaskan bagaimana informasi diteruskan antara perangkat pada jaringan berdasarkan model Open Systems Interconnection (OSI) yang disajikan sebagai seperangkat lapisan pada gambar di bawah. Dua lapisan terendah dari model OSI/ISO tujuh lapis adalah lapisan fisik dan lapisan taut data. Lapisan fisik mendefinisikan komunikasi antara perangkat yang terhubung oleh media fisik.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-d50f3bc11d78b83e05bfefe9d3ac7d582dec1855%2Fcan-bus-principles-1.jpg?alt=media)

Lapisan Taut Data, antara lain, juga menangani pengorganisasian bit menjadi frame dan mencakup dua protokol: CAN klasik (pertama kali digunakan pada 1988) dan CAN FD (diluncurkan pada 2012).

Lapisan aplikasi pada dasarnya adalah lapisan pengguna akhir dan menyediakan akses ke sumber daya jaringan. Ada dua jenis format pesan/frame: standar dan diperluas. Keduanya hanya berbeda pada panjang pengidentifikasi — yang standar 11 bit, sedangkan yang diperluas 29 bit.

Struktur pesan standar dapat dibagi menjadi 8 bagian seperti ditunjukkan pada gambar di bawah. Bagian-bagian itu adalah: Start of Frame (SOF - awal transmisi frame), CAN-ID (pengidentifikasi frame, pengidentifikasi prioritas pesan), Remote Transmission Request (RTR, menunjukkan apakah suatu node meminta data dari node lain atau mengirim data), Control (memberi tahu panjang data dalam byte), Data (nilai data aktual yang perlu diskalakan/dikonversi), The Cyclic Redundancy Check (CRC, memastikan integritas data), ACK (acknowledge, menunjukkan apakah data diterima dengan benar) dan EOF (End of Frame) yang menandai akhir pesan/frame CAN.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-eba86e7aeb438081d966dd3c6b187558c624ddfd%2Fcan-bus-principles-2.png?alt=media)

Bus CAN menggunakan bentuk logika terbalik dengan dua keadaan: dominan dan resesif. Gambar di atas menunjukkan diagram input-output sederhana dari transceiver CAN: aliran bit yang menuju dari/ke pengendali CAN dan/atau mikrokontroler. Ketika pengendali mengirimkan aliran bit, bit tersebut dilengkapi komplemennya dan ditempatkan pada jalur CANH.

Jalur CANL selalu merupakan komplemen dari CANH. CAN harus memantau baik apa yang saat ini ada di bus maupun apa yang sedang dikirimkannya. Untuk aplikasi, kedua ujung bus CAN harus diakhiri karena setiap node pada bus dapat mengirim data.

Setiap ujung tautan memiliki resistor terminasi yang sama dengan impedansi karakteristik kabel. Biasanya nilai yang direkomendasikan untuk resistor terminasi adalah 120 Ω (dalam rentang 100 Ω - 130 Ω). Seharusnya tidak ada lebih dari dua resistor terminasi dalam jaringan, karena terminasi tambahan memberi beban ekstra pada Supir.

Gambar di bawah menunjukkan bus uji CAN. Node-node tersebut dapat mewakili pengiriman pesan dari teknologi penginderaan cerdas dan pengendali motor. Contoh aplikasi yang umum adalah sensor suhu.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-a5cb2689542e48625d481f44b3a3939a738f7b8f%2Fcan-bus-principles-3.png?alt=media)

Jika node sensor lain perlu mengirim pesan secara bersamaan, arbitrasi memastikan bahwa pesan itu dikirim. Misalnya, node A selesai mengirim pesannya saat node B dan C mengakui bahwa pesan yang benar telah diterima. Node B dan C pada gilirannya memulai arbitrasi dan jika node C menang arbitrasi maka ia mengirim pesan. Node A dan B mengakui pesan dari node C, lalu node B kemudian melanjutkan pesannya.

Polaritas yang berlawanan pada input dan output Supir di bus harus diingat. Bus CAN saat ini tersebar luas pada mobil. Bus ini ada pada hampir semua kendaraan yang diproduksi. Mobil di dunia modern pada dasarnya merupakan produk pasar global, sehingga semua kendaraan cenderung memiliki bus CAN. Bus CAN diakses melalui port OBD, yang ditunjukkan pada gambar di bawah bersama dengan contoh resistor terminasi 120 Ω, disolder ke konektor DB9 dengan pengkabelan CAN, yang terletak di rumah cangkang DB9.

Untuk menghubungkan port OBD ke perangkat CAN DB9, diperlukan kabel yang dapat dibeli atau dibuat. Untuk membuatnya sendiri, diperlukan soket D-sub 9-pin (female) dan plug OBD (male). Soket DB9 harus sesuai dengan plug untuk perangkat CAN.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-29b9ba1c692a1a89298cfff4fc27af89c58b318a%2Fcan-bus-principles-4.png?alt=media)

Contoh pengkabelan plug OBD ke DB9 CAN termasuk resistor terminasi opsional juga ditunjukkan pada skema di bawah.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-dbd222d423e905257463eec2576d2c20fd970e83%2Fcan-bus-principles-5.png?alt=media)

Untuk membangun jaringan sensor, antarmuka ke bus CAN, dan melihat sinyal CAN dari kendaraan ada banyak pilihan. Berbagai mikrokontroler saat ini memiliki dukungan protokol CAN dan dapat diantarmukakan ke CAN melalui chip transceiver CAN.

Solusi seperti Raspberry Pi, Texas Instruments Launchpad, dan Arduino juga tersedia dan dapat diantarmukakan ke CAN dengan beberapa add-on. Jaringan komunikasi CAN pada kendaraan modern dapat menyediakan volume data yang sangat besar yang dapat dimanfaatkan dalam [pengelolaan Armada](https://navixy.com/en/fleet-management/) untuk meningkatkan keselamatan Supir, mengurangi biaya keseluruhan, memperbaiki proses Pemeliharaan, dan mendukung tanggung jawab lingkungan.

Mengaktifkan data bus CAN memberi pemilik Armada berbagai peluang untuk mengakses beragam informasi termasuk Konsumsi bahan bakar, pembacaan odometer, putaran per menit, posisi throttle, beban/torsi mesin, suhu mesin, dan level bahan bakar.

## CAN nirkabel

CAN pada sepasang kabel tembaga berpilin menjadi standar ISO pada 1994. Permintaan yang terus meningkat akan konektivitas yang lebih besar memicu pengembangan teknologi alternatif dan pelengkap. Misalnya, beberapa opsi untuk transmisi CAN nirkabel mengandalkan standar radio berbasis protokol seperti WLAN atau Bluetooth.

Dalam skenario seperti itu, data CAN di pemancar harus dikonversi ke protokol nirkabel dan diatur ulang di penerima. Transmisi transparan dan real-time dalam pengertian jaringan CAN tidak mungkin dilakukan dengan cara ini. Oleh karena itu, koneksi radio berfungsi sebagai gateway antara dua jaringan CAN.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-364944e1412069e50e4b64a745a959920a8b82de%2Fwireless-can-diagram.png?alt=media)

CAN nirkabel berbasis radio mode ganda memungkinkan peserta CAN diintegrasikan secara nirkabel ke dalam jaringan CAN, meningkatkan Keamanan dan kegunaan. Namun, sistem semacam itu memerlukan antena khusus yang membutuhkan ruang dan penyelarasan tertentu yang membatasi radiasi omnidireksional.

## MOST, FlexRay, dan ethernet otomotif secara singkat

Alternatif yang menjanjikan untuk CAN adalah ethernet otomotif. Beberapa estimasi memperkirakan pasar ethernet otomotif tumbuh lebih dari 21,6% selama periode prakiraan 2019-2026.

Manfaat utama ethernet untuk konektivitas kendaraan adalah bandwidth tinggi dan efisiensi biaya. Ethernet menerapkan strategi Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Kolisi dapat diabaikan melalui pembagian dalam jaringan dalam kendaraan. Beberapa tantangan ethernet otomotif adalah jumlah derau RF yang signifikan, ketidakmampuan menyediakan latensi hingga kisaran mikrodetik rendah, dan tidak adanya cara untuk menyinkronkan waktu antarperangkat.

MOST (Media Oriented System Transport) adalah sistem komunikasi serial untuk mengirimkan data kontrol, video, dan audio dengan menggunakan serat optik [http://cables.It](http://cables.it) menyediakan pertukaran informasi suara dan video point-to-point dengan kecepatan 24,8 Mbps. MOST dibuat oleh MOST association dan mendefinisikan lapisan protokol, perangkat lunak, dan perangkat keras yang diperlukan untuk memungkinkan transportasi data kontrol, real-time, dan paket secara efisien dan berbiaya rendah menggunakan satu medium / lapisan fisik. Jaringan MOST dapat disajikan secara skematis dalam bentuk cincin yang dapat mencakup hingga 64 perangkat MOST. Berkat fungsionalitas plug\&play-nya, menambah atau menghapus perangkat MOST seharusnya cukup mudah.

FlexRay pada gilirannya pada dasarnya adalah standar jaringan otomotif berdasarkan sistem bus deterministik berkecepatan tinggi, dengan laju data tinggi, tahan galat, dan fleksibel. Ini digunakan sebagai bagian dari topologi bintang atau garis dengan tembaga atau serat optik. Konfigurasi kanal ganda pada FlexRay menawarkan toleransi galat yang ditingkatkan dan/atau bandwidth yang lebih besar. Fitur jaringan komunikasi FlexRay membuatnya menguntungkan bagi industri otomotif generasi berikutnya.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-e4b95247fd9568333d6e0f8ea1f3299162d25d40%2Fflexray_wiring.jpg?alt=media)

Sebagian besar jaringan FlexRay generasi pertama biasanya menggunakan satu kanal untuk memangkas biaya pengkabelan, tetapi pengembangan aplikasi lebih lanjut dan persyaratan Keamanan yang menyertainya akan menyebabkan penggunaan dua kanal yang lebih besar. Faktor pembatas bagi penggunaan FlexRay secara luas adalah harga, tingkat tegangan operasi yang lebih rendah, dan asimetri tepi, yang menyebabkan tantangan dalam memperpanjang panjang jaringan. Beberapa fitur utama protokol yang terdaftar dibandingkan dengan karakteristik CAN disajikan pada tabel di bawah.

![CAN dan alternatif](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-5ab41e0328dddbe4f3671312560eba5fbf5e5f33%2Fmost-flexray-diagram.png?alt=media)

Perbandingan langsung protokol konektivitas yang tercantum menunjukkan bahwa ada trade-off yang jelas dalam bandwidth dan toleransi galat versus biaya rata-rata dan kompleksitas sistem. Walaupun CAN dan MOST tetap menjadi semacam protokol fundamental, FlexRay dan Ethernet adalah solusi yang lebih menjanjikan untuk memenuhi permintaan pasar yang terus tumbuh dan aplikasi beban tinggi. Pada kendaraan modern, protokol tersebut sering digunakan sebagai solusi pelengkap.

## Tujuan protokol komunikasi dalam kendaraan

Bus CAN memang merupakan standar konektivitas kendaraan yang terkenal dan mapan. Ini digunakan untuk powertrain, sasis, jaringan backbone, dan sistem bodi. Ethernet pada gilirannya umum digunakan sebagai protokol diagnostik untuk unit kontrol koneksi elektronik mesin, sasis, dan bodi yang digunakan untuk koneksi jaringan.

FlexRay saat ini menjadi dasar pengembangan teknologi aktif di seluruh dunia, dan banyak aplikasinya mencakup sistem X-by-Wire generasi berikutnya dan sistem backbone. MOST adalah standar bus untuk jaringan multimedia kendaraan yang dirancang untuk memungkinkan transfer audio, video, dan data berkualitas tinggi. Ini memungkinkan interkoneksi yang mudah dari berbagai komponen multimedia kendaraan.

Semua protokol dan teknologi yang disebutkan di atas memenuhi sebagian besar persyaratan diagnostik dan komunikasi multimedia untuk komunikasi modern dalam kendaraan dan antarkendaraan, dan dapat digunakan untuk sistem mengemudi otonom tingkat lanjut. Namun, integrasi yang akurat dari teknologi tersebut sambil memenuhi kendala real-time masih menjadi bagian yang menantang.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
