Bagaimana fungsional kolaborasi antarmuka otomotif multimedia telematika?

Nama          : WIKE RESTU AYU VIRDIANA

NPM           : 12109232

Kelas           : 4KA24

Mata Kuliah : TUGAS PENGANTAR TELEMATIKA

Dosen                   : RIFKI AMALIA

Bagaimana fungsional kolaborasi antarmuka otomotif multimedia telematika?

Antarmuka Otomotif Multimedia Telematika yang dimaksud disini adalah Automotive Multimedia Interface Collaboration atau yang lebih dikenal dengan singkatan AMI-C, adalah suatu bentuk pengembangan dan stadarisasi yang umum multimedia dan telematika otomotif untuk kendaraan antarmuka jaringan komunikasi. Adapun tujuan dari adanya AI-C ini adalah :

1.      Untuk menyediakan interface yang berstandar, sehingga memungkinkan seorang pengendara kendaraan (mobil) dapat menggunakan perangkat lain melalui berbagai media, komputer, perangkat komunikasi dari sistem navigasi dan handsfreeyang biasa digunakan pada telepon selular.

2.     Untuk meningkatkan berbagai macam pilihan yang dapat digunakan oleh user dan juga untuk mengurangi keusangan sistem elektronik kendaraan.

3.   Untuk memotong biaya yang dikeluarkan untuk keseluruhan informasi kendaraan dan juga peralatan hidubran dengan meningkatkan ukuran pasar yang efektif dan memperpendek waktu pengembangan  industri otomotif efektif. Karena banyak jumlah kendaraan yang sering mengandung berbagai adat mengembangkan komponen dan platfor yang khas hanya sekitar 50.000 unit.

4.      Untuk menawarkan standar terbuka dan spesifikasi bagi informasi interface dalam kendaraan dan antara kendaraan dengan dunia luar.

Pada dasarnya kolaboasi antarmuka otomotif multimedia itu sendiri adalah sebuah organisasi yang mana organisasi ini dibentuk guna menciptakan standarisasi dunia yang digunakan dalam mengatur bagaimana sebuah perangkatelektronik dapat bekerja sebagaimana yang diharapkan. Dimana setiap alat elektronik ini harus dapat bekerja dengan selaras sehingg kendaraan dapat lebih handal ketika digunakan. Sebelum memasang perangkat ini, alangkah baiknya untuk terlebih dahulu mencocokkan dengan jenis atau tipe kendaraan yang digunakan, karena pada dasarnya belum tentu perangkat yang akan dipasang akan selalu cocok dengan kendaraan yang digunakan, karena itulah perlu dibuat standarisasi kolaborasi antarmuka multimedia.

Sudah terdapat beberapa anggota yang aktif dalam organisasi Automotive Multimedia Interface Collaboration (AMI-C), diantaranya adalah : Fiat, Ford, General Motors, Mitsubishi, Nissan, PSA Peugeot-Cotroen, dan Renault.

5. Bagaimana arsitektur dari open service gateway initiative (OSGI)

The OSGi Arsitektur

Teknologi yang OSGi adalah seperangkat spesifikasi yang mendefinisikan sistem komponen dinamis untuk Java. Spesifikasi ini memungkinkan suatu model pengembangan aplikasi di mana (dinamis) terdiri dari banyak berbeda (reusable) komponen. Spesifikasi yang memungkinkan komponen OSGi untuk menyembunyikan implementasi dari komponen lain saat berkomunikasi melalui layanan, yang merupakan objek yang secara khusus dibagi antara komponen. Mengherankan model sederhana ini telah mencapai jauh efek untuk hampir semua aspek dari proses pengembangan perangkat lunak.
Meskipun komponen telah di cakrawala untuk waktu yang lama, sejauh ini mereka gagal untuk membuat baik pada janji-janji mereka. OSGi adalah teknologi pertama yang benar-benar berhasil dengan sistem komponen yang memecahkan banyak masalah nyata dalam pengembangan software. Adopter dari teknologi OSGi melihat kerumitan berkurang secara signifikan di hampir semua aspek pembangunan. Kode lebih mudah untuk menulis dan menguji, menggunakan kembali meningkat, membangun sistem menjadi sangat sederhana, penyebaran lebih mudah dikelola, bug terdeteksi lebih awal, dan runtime memberikan wawasan yang sangat besar apa yang sedang berjalan. Paling penting, ia bekerja seperti yang dibuktikan oleh adopsi yang luas dan populer digunakan dalam aplikasi seperti Eclipse dan Spring.
Kami mengembangkan teknologi OSGi untuk menciptakan sebuah lingkungan perangkat lunak kolaboratif. Kami tidak mencari kemungkinan untuk menjalankan beberapa aplikasi dalam satu VM. Aplikasi server sudah melakukan itu (walaupun mereka belum sekitar ketika kita mulai tahun 1998). Tidak, masalah kita lebih sulit. Kami ingin aplikasi yang muncul dari menyatukan berbagai komponen dapat digunakan kembali yang tidak memiliki pengetahuan a-priori satu sama lain. Bahkan lebih keras, kita ingin bahwa aplikasi untuk merakit secara dinamis muncul dari seperangkat komponen. Sebagai contoh, Anda memiliki rumah server yang mampu mengelola lampu dan peralatan Anda. Sebuah komponen dapat memungkinkan Anda untuk menghidupkan dan mematikan lampu di atas halaman web. Komponen lain bisa memungkinkan Anda untuk mengontrol peralatan mobile melalui pesan teks. Tujuannya adalah untuk mengizinkan fungsi-fungsi lain tersebut akan ditambahkan tanpa memerlukan bahwa pengembang telah rumit pengetahuan satu sama lain dan membiarkan komponen ini akan ditambahkan secara independen.
Layering
Yang berlapis-lapis OSGi memiliki model yang digambarkan dalam gambar berikut.
Daftar berikut berisi definisi singkat dari istilah:

·         Kumpulan – Kumpulan adalah komponen OSGi yang dibuat oleh pengembang.

·         Jasa – Layanan bundel menghubungkan lapisan dalam cara yang dinamis dengan menawarkan menerbitkan-menemukan-model mengikat Jawa lama untuk menikmati objek.

·         Life-Siklus – The API untuk instalasi, start, stop, update, dan menghapus bundel.

·         Modul – Lapisan yang mendefinisikan bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode.

·         Keamanan – Lapisan yang menangani aspek keamanan.

·         Pelaksanaan Lingkungan – Tetapkan apa yang metode dan kelas-kelas yang tersedia dalam platform tertentu.

Konsep ini lebih luas dijelaskan dalam bagian berikut.

Modul
Konsep dasar yang memungkinkan sistem seperti ini adalah modularitas. Modularitas, simplistically berkata, adalah tentang dengan asumsi kurang. Modularitas adalah tentang menjaga hal-hal lokal dan tidak berbagi. Sulit untuk keliru tentang hal-hal yang tidak memiliki pengetahuan dan tidak membuat asumsi tentang mereka. Oleh karena itu, modularitas merupakan inti dari spesifikasi OSGi dan diwujudkan dalam konsep bundel. Dalam istilah Jawa, sebuah kemasan adalah dataran JAR tua. Namun, di mana di Jawa standar segalanya dalam JAR benar-benar dapat dilihat oleh semua guci lain, OSGi menyembunyikan segala sesuatu dalam JAR, kecuali secara eksplisit diekspor. Sebuah bundel yang ingin menggunakan JAR lain harus secara eksplisit mengimpor bagian-bagian yang dibutuhkan. Secara default, tidak ada berbagi.
Meskipun kode bersembunyi dan berbagi eksplisit memberikan banyak manfaat (misalnya, yang memungkinkan beberapa versi dari library yang sama yang digunakan dalam satu VM), kode berbagi hanya ada untuk mendukung layanan OSGi model. Model layanan tentang kumpulan yang berkolaborasi.
Layanan
Alasan kita membutuhkan layanan model ini adalah karena Jawa menunjukkan betapa sulitnya menulis model kolaboratif dengan kelas hanya berbagi. Solusi standar di Jawa adalah dengan menggunakan pabrik-pabrik yang menggunakan kelas dinamis pemuatan dan statika. Sebagai contoh, jika Anda ingin DocumentBuilderFactory, Anda memanggil metode DocumentBuilderFactory pabrik statis. NewInstance (). Di balik façade, metode yang newInstance setiap kelas loader mencoba trik dalam buku (dan beberapa yang tidak) untuk membuat sebuah instance dari sebuah implementasi DocumentBuilderFactory subkelas dari kelas. Mencoba mempengaruhi pelaksanaan apa yang digunakan adalah non-sepele (model jasa, properti, konvensi di nama kelas), dan biasanya global untuk VM. Juga itu adalah model pasif. Kode pelaksanaan tidak bisa berbuat apa-apa untuk mengiklankan ketersediaannya, atau dapat daftar pengguna yang mungkin memilih implementasi dan implementasi yang paling cocok. Juga tidak dinamis. Setelah tangan keluar penerapan sebuah contoh, ia tidak bisa menarik objek. Terburuk, pabrik mekanisme konvensi digunakan di ratusan tempat di VM di mana setiap pabrik unik memiliki API dan mekanisme konfigurasi. Tidak ada tersentralisasi ikhtisar implementasi yang terikat kode Anda.
Solusi untuk semua masalah ini adalah layanan OSGi registri. Sebuah bundel dapat menciptakan sebuah benda dan mendaftarkannya dengan layanan OSGi registri di bawah satu atau lebih interface. Kumpulan lain bisa pergi ke registri dan daftar semua objek yang terdaftar di bawah antarmuka khusus atau kelas. Sebagai contoh, sebuah kemasan memberikan pelaksanaan DocumentBuilder. Ketika dijalankan, itu menciptakan sebuah instance dari kelas dan mendaftarkan DocumentBuilderFactoryImpl dengan registri di bawah kelas DocumentBuilderFactory. Sebuah bundel yang memerlukan DocumentBuilderFactory bisa pergi ke registri dan meminta untuk semua layanan yang tersedia yang memperpanjang DocumentBuilderFactory kelas. Bahkan lebih baik, sebuah kemasan dapat menunggu untuk layanan tertentu untuk muncul dan kemudian mendapatkan panggilan kembali.
Sebuah bundel demikian bisa mendaftar layanan, itu bisa mendapatkan layanan, dan dapat mendengarkan layanan untuk muncul atau menghilang. Sejumlah bundel dapat mendaftar jenis layanan yang sama, dan sejumlah bundel bisa mendapatkan layanan yang sama.

Ini digambarkan dalam gambar berikut.

Apa yang terjadi bila beberapa kumpulan objek mendaftar di bawah antarmuka yang sama atau kelas? Bagaimana ini dapat dibedakan? Jawabannya adalah properti. Setiap layanan registrasi memiliki seperangkat standar dan adat properti. Sebuah bahasa filter ekspresif tersedia hanya untuk memilih layanan yang Anda minati. Sifat dapat digunakan untuk mencari layanan yang tepat atau dapat memainkan peran lain di tingkat aplikasi.

Layanan bersifat dinamis. Ini berarti bahwa sebuah kemasan dapat memutuskan untuk menarik layanan dari registri sementara kumpulan lain masih menggunakan layanan ini. Kumpulan menggunakan layanan tersebut kemudian harus memastikan bahwa mereka tidak lagi menggunakan layanan objek dan jatuhkan referensi apapun. Kami tahu, ini terdengar seperti kompleksitas yang signifikan, tetapi ternyata bahwa kelas penolong seperti Tracker Layanan dan kerangka kerja seperti iPOJO, Spring, dan Layanan deklaratif dapat membuat rasa sakit yang minimal, sementara keuntungan yang cukup besar. Dinamika layanan ditambahkan sehingga kami dapat menginstal dan menghapus buntalan on the fly sementara kumpulan lain bisa beradaptasi. Itu adalah, sebuah kemasan dapat tetap memberikan fungsionalitas bahkan jika layanan http pergi. Namun, kami mengetahui dari waktu ke waktu bahwa dunia nyata yang dinamis dan banyak masalah yang jauh lebih mudah untuk model dengan layanan dinamis daripada statis pabrik. Sebagai contoh, sebuah layanan Device dapat mewakili salah satu perangkat pada jaringan lokal. Jika perangkat hilang, mewakili layanan ini tidak terdaftar. Dengan cara ini, ketersediaan model-model layanan ketersediaan entitas dunia nyata. Ini berhasil sangat baik dalam, misalnya, model OSGi terdistribusi di mana layanan ini dapat ditarik jika koneksi ke mesin remote hilang. Hal ini juga ternyata bahwa dinamika memecahkan masalah inisialisasi. OSGi aplikasi tidak memerlukan memulai tertentu memesan dalam bundel.

Efek dari registri layanan telah banyak API khusus bisa jauh model layanan dengan registri. Hal ini tidak hanya menyederhanakan aplikasi secara keseluruhan, hal itu juga berarti bahwa alat-alat standar dapat digunakan untuk debug dan melihat bagaimana sistem kabel atas.

Meskipun registri layanan menerima objek apapun sebagai layanan, cara terbaik untuk mencapai adalah dengan mendaftar menggunakan kembali objek-objek ini di bawah (standar) antarmuka untuk decouple pelaksana dari kode klien. Ini adalah alasan Aliansi OSGi menerbitkan spesifikasi Compendium. Spesifikasi ini mendefinisikan jumlah besar layanan standar, dari Layanan log ke Negara Pengukuran dan spesifikasi. Semua layanan standar ini dijelaskan dengan sangat rinci.
Deployment
Kumpulan dikerahkan pada kerangka OSGi, bungkusan lingkungan runtime. Ini bukan sebuah wadah seperti Java Application Server. Ini adalah sebuah lingkungan kolaboratif. Bundel menjalankan VM yang sama dan dapat benar-benar berbagi kode. Kerangka menggunakan eksplisit impor dan ekspor untuk memasang sebuah buntalan sehingga mereka tidak perlu menyibukkan diri dengan kelas loading. Kontras lain dengan aplikasi server adalah bahwa pengelolaan kerangka kerja standar. API sederhana memungkinkan kumpulan untuk menginstal, start, stop, dan memperbarui kumpulan lainnya, serta pencacahan buntalan dan penggunaan layanan mereka. API ini telah digunakan oleh banyak agen manajemen untuk mengendalikan kerangka OSGi. Manajemen agen sangatlah beragam sebagai Knopflerfish desktop dan manajemen Tivoli IBM server.

Implementasi
Spesifikasi OSGi proses yang membutuhkan referensi spesifikasi implementasi untuk masing-masing. Namun, karena spesifikasi pertama selalu ada perusahaan komersial yang telah menerapkan spesifikasi serta implementasi open source. Saat ini, terdapat 4 open source implementasi dari kerangka dan terlalu banyak untuk menghitung implementasi dari layanan OSGi. Industri perangkat lunak yang terbuka telah menemukan teknologi OSGi dan semakin banyak proyek artefak menyampaikan sebagai kumpulan.

Spesifikasi OSGi License, Versi 1.0.

The OSGi Alliance ( “OSGi Alliance”) dengan ini memberikan kepada Anda dibayar penuh, non-eksklusif, tidak dapat dialihkan, di seluruh dunia, lisensi terbatas (tanpa hak untuk mensublisensikan), di bawah Aliansi OSGi hak kekayaan intelektual yang berlaku untuk melihat, mendownload, dan mereproduksi OSGi Spesifikasi ( “Spesifikasi”) yang mengikuti Perjanjian Lisensi ini ( “Perjanjian”). Anda tidak diizinkan untuk menciptakan karya turunan dari Spesifikasi. OSGi Alliance yang juga memberikan kepada Anda terus-menerus, non-eksklusif, di seluruh dunia, disetor penuh, bebas royalti, lisensi terbatas (tanpa hak untuk mensublisensikan) di bawah hak cipta yang berlaku, untuk menciptakan dan / atau mendistribusikan pelaksanaan Spesifikasi bahwa:

(i)       benar-benar mengimplementasikan Spesifikasi termasuk semua antarmuka dan fungsionalitas yang diperlukan,

(ii)     tidak mengubah, subset, superset atau memperpanjang Nama OSGi Space, atau menyertakan publik atau dilindungi setiap paket, kelas, Jawa antarmuka, ladang atau metode dalam Ruang Nama yang OSGi selain yang dibutuhkan dan disahkan oleh Spesifikasi. Penerapan yang tidak memuaskan keterbatasan

(iii)    (i) – (ii) tidak dianggap sebagai pelaksanaan Spesifikasi, tidak mendapatkan keuntungan dari lisensi ini, dan tidak boleh digambarkan sebagai pelaksanaan Spesifikasi. Sebuah pelaksanaan Spesifikasi tidak boleh mengklaim sebagai pelaksanaan sesuai Spesifikasi kecuali melewati Pengujian Kepatuhan Aliansi OSGi untuk Spesifikasi sesuai dengan proses OSGi Alliance. “Nama OSGi Space” akan berarti kelas publik atau deklarasi interface yang namanya dimulai dengan “org.osgi” diakui atau penggantinya atau penggantian daripadanya.

SUMBER:

http://adhek09.wordpress.com/2009/11/30/open-service-gateway-initiative-osgi/

4. Bagaimana spesifikasi dari open service gateway initiative (OSGI)

The OSGi Alliance (sebelumnya dikenal sebagai Open Services Gateway inisiatif, sekarang nama kuno) adalah organisasi standar yang didirikan pada Maret 1999. Aliansi dan anggota-anggotanya telah ditentukan yang berbasis Java layanan platform yang dapat dikelola dari jarak jauh. Inti bagian dari spesifikasi adalah sebuah kerangka kerja yang mendefinisikan suatu manajemen siklus hidup aplikasi model, layanan registry, sebuah lingkungan Eksekusi dan Modul. Berdasarkan kerangka ini, sejumlah besar OSGi layers, API, dan Java telah ditetapkan. OSGi teknologi adalah sistem modul dinamis untuk Java.

OSGi teknologi menyediakan layanan berorientasi, komponen berbasis lingkungan untuk para pengembang dan menawarkan cara-cara standar untuk mengelola siklus hidup perangkat lunak. Kemampuan ini sangat meningkatkan nilai berbagai komputer dan perangkat yang menggunakan platform Java. Pengadopsi teknologi OSGi manfaat dari peningkatan waktu ke pasar dan mengurangi biaya pengembangan karena teknologi OSGi menyediakan integrasi pra-dibangun dan pra-komponen subsistem diuji. Teknologi ini juga mengurangi biaya pemeliharaan dan kemajuan aftermarket baru peluang unik karena jaringan dapat dimanfaatkan untuk secara dinamis mengupdate atau memberikan layanan dan aplikasi di lapangan.

Spesifikasi:

                OSGi spesifikasi yang dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk umum secara gratis di bawah Lisensi Spesifikasi OSGi. OSGi Alliance yang memiliki kepatuhan program yang hanya terbuka untuk anggota. Pada Oktober 2009, daftar bersertifikat OSGi implementasi berisi lima entri. Spesifikasi OSGi yang dimulai pada tahun 1998 dan ditujukan untuk pasar otomatisasi rumah, mencoba untuk memecahkan masalah bagaimana membangun aplikasi dari komponen independen. Dalam dekade terakhir ini, industri perangkat lunak itu berubah secara mendasar karena ledakan di proyek-proyek open source. Sepuluh tahun yang lalu, sebuah aplikasi terdiri sebagian besar kode khusus ditulis. Saat ini, sebagian besar perangkat lunak sebagian besar kabel sampai artefak open source yang sering tidak dirancang untuk bekerja bersama-sama. Hal ini mirip dengan masalah yang OSGi dirancang untuk memecahkan. Banyak proyek open source karena itu mengadopsi spesifikasi OSGi karena mereka melihat bahwa mereka dapat fokus pada masalah nyata dan khawatir kurang tentang infrastruktur, serta menjadi lebih mudah untuk digunakan dalam proyek-proyek lainnya. Tren ini mempercepat.

Sumber :

1.http://gaptechnology.wordpress.com/2009/12/29/middleware-telematika-teknologi-osgi-dan-automotive-multimedia-interface-colaboration/

2.http://www.osgi.org/Technology/WhyOSGi

3.http://fitrinurhayati91.blogspot.com/2012/11/bagaimana-spesifikasi-dari-open-service.html

3. Manajeman data base system perangkat bergerak

RDBMS ( Manajemen database pada perangkat bergerak )

Sebuah sistem manajemen basisdata relasional atau dalam bahasa Inggrisnya dikenal sebagai relational database management system (RDBMS) adalah sebuah program komputer (atau secara lebih tipikal adalah seperangkat program komputer) yang didisain untuk mengatur/memanajemen sebuah basisdata sebagai sekumpulan data yang disimpan secara terstruktur, dan melakukan operasi-operasi atas data atas permintaan penggunanya. Contoh penggunaan DBMS ada banyak sekali dan dalam berbagai bidang kerja, misalnya akuntansi, manajemen sumber daya manusia, dan lain sebagainya. Meskipun pada awalnya DBMS hanya dimiliki oleh perusahaan-perusahaan berskala besar yang memiliki perangkat komputer yang sesuai dengan spesifikasi standar yang dibutuhkan (pada saat itu standar yang diminta dapat dikatakan sangat tinggi) untuk mendukung jumlah data yang besar, saat ini implementasinya sudah sangat banyak dan adaptatif dengan kebutuhan spesifikasi data yang rasional sehinggal dapat dimiliki dan diimplementasikan oleh segala kalangan sebagai bagian dari investasi perusahaan. Keluhan yang muncul dan dikenal secara umum terhadap keberadaan RDBMS adalah kenyataan bahwa implementasi yang ada saat ini dipandang sebagai terlalu “statis”. Spekulasipun bermunculan terhadap kemungkinan untuk membuat sebuah sistem basisdata generasi baru yang menggunakan model “relasional secara dinamis” dengan kolom yang bisa dibuat secara dinamis, ukuran yang berkembang secara dinamis, didefinisikan secara dinamis. Setiap baris dapat diimplementasikan sebagai map (kamus ataupun larik asosiatif) dan kolom-kolom yang tidak dikenal secara sederhana disajikan sebagai field kosong. Beberapa kalangan menganggap hal ini menyalahi model relasioal murni, namun kalangan lain menyanggah bahwa sebuah penggunaan map hanyalah sebagai detil implementasi saja. Sehingga dalam pandangan ini, sebuah “kolom yang tidak ditemukan/tidak ada” secara sederhana hanyalah dipandang sebagai perihal interpretasi dan dianggap sebagai pilihan cara penyajian saja.

Sumber:

http://kawai-tiramisu.blogspot.com/2010/11/manajemen-data-telematika_8032.html