Rabu, 26 Desember 2012

Bagaimana fungsional kolaborasi antarmuka otomotif multimedia telematika



Automotive Multimedia Interface Collaboration adalah sebuah kelompok yang dibuat oleh pembuat/pabrik automotive untuk menciptakan standar umum untuk mengatur bagaimana perangkat elektronik, seperti computer dan unit-unit hiburan berkomunikasi dengan kendaraan.
Tapi kenapa perlu ada Automotive Multimedia Interface Collaboration? Ternyata para pembuat/pabrik automotive mengkhawatirkan bahwa perangkat elektronik dan multimedia akan tidak cocok/tidak kompatibel dengan kendaraan; bahwa perangkat tersebut dapat mengganggu elektronik yang mengontrol sistem keselamatan dan bahwa organisasi standar yang ada tidak akan bergerak cukup cepat. Oleh karena itu terbentuklah Automotive Multimedia Interface Collaboration.

Atau dengan kata lain Automotive Multimedia Interface Collaboration (AMI-C) adalah organisasi global yang mewakili mayoritas dunia produksi kendaraan.
AMIC didirikan pada Oktober 1998 dengan tujuan untuk mengembangkan serangkaian spesifikasi umum untuk multimedia. Automotive Multimedia Interface Collaboration (AMI-C) sudah memiliki anggota : Fiat, Ford, General Motors, Honda, Mitsubishi, Nissan, PSA Peugeot-Citroen, Renault. AMI-C mengembangkan dan men-standarisasi antarmuka multimedia dan telematika otomotif yang umum untuk jaringan komunikasi kendaraan. Dan 40 pemasok elektronik mendaftarkan diri untuk menulis standar. Mereka berpendapat untuk menulis standar diperlukan waktu selama 2 tahun. Tapi dua tahun adalah masa di telematika. Penyelenggara elektronik, ponsel, komputer dan peralatan video yang akan menggunakan koneksi dapat melewati beberapa generasi dalam waktu itu.
Dua bagian penting dari spesifikasi AMI-C adalah Vehicle Service Interface (VSI) API dan Human Machine Interface (HMI) API. VSI API yang menyediakan cara seragam mengakses informasi tentang status kendaraan, seperti tingkat bahan bakar atau informasi diagnostik, serta kontrol menyediakan fungsi-fungsi kendaraan tertentu, seperti kunci pintu. HMI API yang menyediakan aplikasi perangkat lunak dengan metode untuk mengirim dan menerima informasi ke atau dari sopir atau penumpang kendaraan tanpa aplikasi memiliki pengetahuan sebelum kendaraan khusus perangkat HMI, seperti speaker, display, tombol dan switch.
Tujuan utamanya adalah untuk:

·         Menyediakan interface standar untuk memungkinkan pengendara mobil untuk menggunakan berbagai media, komputer dan perangkat komunikasi - dari sistem navigasi dan hands-free telepon selular, melalui manusia maju / mesin sistem antarmuka, termasuk pengenalan suara dan sintesis, untuk dipersembahkan komunikasi jarak dekat ( DSRC) sistem untuk kendaraan untuk infrastruktur komunikasi dan sistem mobil seperti airbag, pintu kunci dan diagnostik input / output;
·         Meningkatkan pilihan dan mengurangi keusangan sistem elektronik kendaraan.
·         Memotong biaya keseluruhan informasi kendaraan dan peralatan hiburan dengan meningkatkan ukuran pasar yang efektif dan memperpendek waktu pengembangan - industri otomotif efektif terdiri dari banyak pasar yang kecil karena setiap platform kendaraan sering mengandung berbagai adat-mengembangkan komponen dan platform yang khas hanya sekitar 50.000 unit
·         Menawarkan standar terbuka dan spesifikasi untuk informasi interface dalam kendaraan dan antara kendaraan dan dunia luar.

The Automotive Multimedia Interface Colaboration (AMI-C) mengumumkan hak cipta seluruh dunia penugasan dari otomotif 1394, spesifikasi teknis kepada Asosiasi Perdagangan 1394. Berikut document AMI-C yang sekarang milik 1394TA :
· AMI-C 3.023 Power Management Spesifikasi
· AMI-C 3.013 Power Management Arsitektur
· AMI-C 2001 1.0.2 common Pesan Set Power Management
· AMI-C Uji 3.034 Document Manajemen Power
· AMI-C 4.001 Revisi Spesifikasi Fisik

Arsitektur dari open service gateway initiative (OSGI)



Ada kerangka OSGI yang menyediakan suatu lingkungan untuk modularisasi aplikasi ke dalam kumpulan yang lebih kecil. Setiap bundel adalah erat – coupled, dynamically loadable kelas koleksi, botol, dan file-file konfigurasi yang secara eksplisit menyatakan dependensi eksternal mereka (jika ada).

Kerangka kerja konseptual yang dibagi dalam bidang-bidang berikut:

1. Bundel
Kumpulan jar normal komponen dengan nyata tambahan header. Sebuahbundel adalah sekelompok kelas Java dan sumber daya tambahan yang dilengkapi dengan rincian file pada MANIFEST.MF nyata semua isinya, serta layanan tambahan yang diperlukan untuk memberikan kelompok termasuk kelas Java perilaku yang lebih canggih, dengan tingkat deeming seluruh agregat sebuah komponen.

2. Layanan
Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan, menerbitkan dan menemukan model dapat mengikat Java lama untuk menikmati objek (POJO). Siklus hidup menambahkan lapisan bundel dinamis yang dapat diinstal, mulai, berhenti, diperbarui dan dihapus. Buntalan bergantung pada lapisan modul untuk kelas loading tetapi menambahkan API untuk mengatur modul – modul dalam run time. Memperkenalkan lapisan siklus hidup dinamika yang biasanya bukan bagian dari aplikasi. Mekanisme ketergantungan luas digunakan untuk menjamin operasi yang benar dari lingkungan.

3. Layanan Registrasi (Services-Registry)

API untuk manajemen jasa (ServiceRegistration, ServiceTracker dan ServiceReference).
OSGi Alliance yang telah ditentukan banyak layanan. Layanan yang ditentukan oleh antarmuka Java. Kumpulan dapat mengimplementasikan antarmuka ini dan mendaftarkan layanan dengan Layanan Registri. Layanan klien dapat menemukannya di registri, atau bereaksi ketika muncul atau menghilang.

4. Siklus Hidup (Life-Cycle)

API untuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.

5. Modul
Lapisan yang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).

6. Keamanan
Layer yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra didefinisikan kemampuan.

7. Pelaksanaan Lingkungan

Mendefinisikan metode dan kelas apa yang tersedia dalam platform tertentu. Tidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa. Namun, set berikut saat ini didukung oleh sebagian besar OSGI implementasi:

· CDC-1.0/Foundation-1.0

· CDC-1.1/Foundation-1.1

· OSGi/Minimum-1.0

· OSGi/Minimum-1.1

· JRE-1.1

· Dari J2SE-1.2 hingga J2SE-1,6

Sumber:
http://kikitamie25.blogspot.com/2012/11/arsitektur-dari-open-service-gateway.html

spesifikasi dari open service gateway initiative (OSGI)



The OSGi Alliance (sebelumnya dikenal sebagai Open Services Gateway inisiatif, sekarang nama kuno) adalah terbuka organisasi standar yang didirikan pada Maret 1999. Aliansi dan anggota-anggotanya telah ditentukan yang Java berbasis layanan platform yang dapat dikelola dari jarak jauhInti 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 Jasa 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 OSGiOSGi Allianceyang memiliki kepatuhan program yang hanya terbuka untuk anggota. Pada Oktober 2009, daftar bersertifikat OSGi implementasi berisi lima entri.
http://bluewarrior.files.wordpress.com/2009/12/osgi-penempatan.jpg?w=468
Arsitektur:
http://bluewarrior.files.wordpress.com/2009/12/osgi-arsitektur.jpg?w=468
Setiap kerangka yang menerapkan standar OSGi menyediakan suatu lingkungan untuk modularisasi aplikasi ke dalam kumpulan yang lebih kecil. Setiap bundel adalah erat-coupled, dynamically loadable kelas koleksi, botol, dan file-file konfigurasi yang secara eksplisit menyatakan dependensi eksternal mereka (jika ada).  Kerangka kerja konseptual yang dibagi dalam bidang-bidang berikut:

1.     Bundles
Bundles adalah normal jar komponen dengan nyata tambahan header
2.     Services
Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan menerbitkan-menemukan-model mengikat Jawa lama untuk menikmati objek (POJO).
3.     Services
API untuk jasa manajemen (ServiceRegistration, ServiceTracker dan ServiceReference).
4.     Life-Cycle
API untuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.
5.     Modules
Lapisan yang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).
6.     Security
Layer yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra-didefinisikan kemampuan.
7.     Execution Environment
Mendefinisikan metode dan kelas apa yang tersedia dalam platform tertentuTidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa. Namun, set berikut saat ini didukung oleh sebagian besar OSGi implementasi:
•    CDC-1.1/Foundation-1.1 CDC-1.1/Foundation-1.1
•    OSGi/Minimum-1.0 OSGi/Minimum-1.0
•    OSGi/Minimum-1.1 OSGi/Minimum-1.1
•    JRE-1.1 JRE-1.1
•    From J2SE-1.2 up to J2SE-1.6 Dari J2SE-1.2 hingga J2SE-1,6
•    CDC-1.0/Foundation-1.0 CDC-1.0/Foundation-1.0
 SUMBER : 
http://bluewarrior.wordpress.com/2009/12/01/open-services-gateway-initiative-osgi/
http://kikitamie25.blogspot.com/2012/11/spesifikasi-dari-open-service-gateway.html

Manajemen Database Sistem 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.

Pesatnya perkembangan bagi komunikasi bergerak mendorong para operator layanan berlomba untuk memperkaya macam layanannya guna menambah pemasukan bagi perusahaanya. Komunikasi data bergerak, misalnya untuk akses internet. Pengenalan WAP (Wireless Application Protocol) telah menunjukkan potensi sebagai layanan internet nirkabel/ WAP merupakan protocol global terbuka yang memungkinkan para pengguna mengakses layanan-layanan on-line dari layar kecil pada telepon genggam dengan menggunakan built-in browser. WAP bekerja pada berbagai teknologi jaringan bergerak, yang memungkinkan pasar missal bagi penciptaan layanan data bergerak.
Contoh dari layanan bergerak adalah GPRS. GPRS merupakan system transmisi berbasis paket untuk GSM yang menggunakan prinsip 'tunnelling'. GPRS tidak menawarkan laju data tinggi yang memadai untuk multimedia nayata, tetapi GPRS merupakan kunci untuk menghilangkan beberapa batas pokok bagi layanan-layanan data bergerak.
Beberapa faktor yang menjadi pertimbangan bahwa GPRS merupakan teknologi kunci untuk data bergerak :
    Memperkaya utility investasi untuk perangkat GSM yang sudah ada.
    Merupakan teknologi jembatan yang bagus menuju generasi ke 3.
    Mampu memanfaatkan kemampuan cakupan global yang dimiliki GSM.
  Menghilangkan atau mengurangi beberapa pembatas bagi akses data bergerak.
   Memiliki laju data sampai 115 kbps yang berarti dua kali lipat daripada koneksi 'dial up' 56 kbps yang berlaku.
    Menampakan diri sebagai komunikasi yang 'selalu' terhubung sehingga memiliki waktu sesi hubungan yang pendek dan akses langsung ke internet.

Sumber:
http://abanktama.wordpress.com/2010/03/08/manajemen-sistem-basis-data-pada-perangkat-bergerak/
http://bhobob.blogspot.com/2012/11/manajemen-database-sistem-perangkat.html
 http://kikitamie25.blogspot.com/2012/11/manajemen-database-sistem-perangkat.html