MANUFACTURING / JAPAN SOURCING
Peralatan komunikasi industri: port yang cocok baru pemeriksaan awal
Berikan protokol, peran perangkat, versi, dan kebutuhan data kedua sisi kepada pemasok. Koneksi fisik atau balasan yang berhasil belum membuktikan aplikasi penerima dapat memakai informasinya.
Kabel cocok, tetapi aplikasi belum mendapat nilai yang berguna
Bayangkan penggantian gateway yang mengirim data suhu ke pengendali yang ada. Gateway usulan memiliki konektor Ethernet yang sama. Kabel cocok, tetapi permintaan pembelian hanya menyebut “kompatibel Ethernet”. Dalam contoh fiktif ini, pengendali memerlukan layanan dan definisi data tertentu, bukan sekadar soket yang cocok. Identifikasi model lengkap yang ada dan yang diusulkan, opsi perangkat keras, versi firmware, dan aplikasi pengendali sebelum membandingkan kandidat.
Pisahkan antarmuka fisik, protokol, dan cara aplikasi memakai data. NI menjelaskan Modbus sebagai lapisan aplikasi dengan jaringan di bawahnya, termasuk implementasi serial dan TCP/IP.[1] Untuk contoh Modbus TCP, tentukan sisi klien dan server, fungsi yang diperlukan, serta dukungan sebenarnya pada masing-masing sisi. Label port tidak memberikan jawaban itu.
Sepakati arti data sebelum menerima balasan sebagai bukti
Dalam contoh gateway, angka yang diterima berguna hanya jika pengendali menafsirkan item yang dimaksud dengan benar. Minta peta data perangkat beserta revisinya. Identifikasi notasi alamat, operasi yang diizinkan, tipe data, satuan, penskalaan, dan representasi data yang tidak tersedia atau tidak valid.
NI menyebut dokumentasi Modbus dapat memakai konvensi penomoran alamat berbeda dan aplikasi perlu menafsirkan data lintas register, termasuk perbedaan urutan.[1] Cocokkan dokumen perangkat persis dengan konfigurasi klien. Jangan menyalin alamat model lain atau menganggap nilai yang tampak masuk akal membuktikan pemetaan.
Tentukan perilaku pembaruan yang diperlukan dan respons aplikasi penerima saat batas waktu terlampaui, perangkat dimulai ulang, atau komunikasi terputus. Minta tim teknis menetapkan waktu dan kriteria penerimaan sistem sebenarnya. Sertakan kebutuhan jaringan dan akses dalam permintaan, tetapi jangan memasukkan kata sandi, kunci, atau rincian jaringan pribadi dalam pertanyaan publik.
- 1Kedua sisi: identifikasi gateway dan pengendali, termasuk versi
- 2Definisi data: petakan item, representasi, dan perilaku yang diharapkan
- 3Catatan uji: simpan pasangan persis, konfigurasi, dan hasil pengamatan
Gateway dan pengendali fiktif. Garis utuh menunjukkan koneksi jaringan fisik; garis putus-putus mengaitkan kedua sisi dengan definisi data yang disepakati. Bukan diagram pengawatan, pasangan produk yang telah diuji, atau petunjuk menghubungkan jaringan produksi.
Minta bukti untuk produk dan lingkup persis
Jika pemasok mengutip sertifikasi atau logo protokol, tanyakan produk persis, versi, dan profil yang dicakup. OPC Foundation menjelaskan sertifikasi berdasarkan profil dan membedakan implementasi referensi bersertifikat dari aplikasi yang dibangun menggunakan SDK-nya; aplikasi hasilnya perlu pengujian sertifikasi sendiri agar bersertifikat resmi.[2] Ini contoh lingkup OPC UA, bukan aturan yang menyertifikasi setiap protokol atau otomatis menerima pemasangan Anda.
Pisahkan demonstrasi pemasok, sertifikasi produk, dan uji penerimaan yang disepakati sebagai bukti berbeda. Pemasok mungkin menguji pengendali, firmware, atau rangkaian fitur lain. Tanyakan apa yang diuji dan simpan perbedaannya dari pasangan yang Anda rencanakan.
| Batas | Informasi sistem yang ada | Bukti kandidat yang diminta |
|---|---|---|
| Antarmuka fisik | Informasi sistem yang adaKonektor, jenis antarmuka, daya, dan kondisi pemasangan | Bukti kandidat yang dimintaModel persis dan opsi; dokumen antarmuka |
| Protokol dan peran | Informasi sistem yang adaProtokol, peran klien/ | Bukti kandidat yang dimintaFungsi, profil atau lisensi yang didukung serta batasan |
| Interpretasi data | Informasi sistem yang adaRevisi peta data, alamat, tipe, satuan, dan penskalaan | Bukti kandidat yang dimintaKonfigurasi yang cocok dan contoh hasil item yang diperlukan |
| Versi dan dependensi | Informasi sistem yang adaAplikasi pengendali, firmware, driver, dan pengaturan terkait | Bukti kandidat yang dimintaKombinasi yang didukung; perbedaan dan perubahan yang diperlukan |
| Operasi dan pemulihan | Informasi sistem yang adaKebutuhan pembaruan, batas waktu, mulai ulang, dan putus koneksi | Bukti kandidat yang dimintaUji yang disepakati, respons teramati, dan kondisi tersisa |
| Bukti penerimaan | Informasi sistem yang adaPasangan perangkat persis, konfigurasi, dan pihak yang menyetujui | Bukti kandidat yang dimintaHasil, pengecualian, pekerjaan tersisa, dan lingkup yang disetujui |
Uji pasangan yang diusulkan dan simpan konfigurasinya
Sepakati lingkungan uji terkendali dan rencana uji bersama pemilik sistem. Untuk gateway fiktif ini, periksa item data dan artinya, perilaku pembaruan, dan kondisi pemulihan. Catat model persis, firmware, aplikasi, dan konfigurasi yang dipakai beserta hasil serta pengecualian. Jangan mengubah uji meja menjadi izin mengubah proses yang sedang berjalan.
Jika diperlukan gateway, konverter, lisensi, atau perubahan aplikasi, masukkan ke lingkup pekerjaan dalam penawaran. Tentukan pihak yang mengembangkan pemetaan, mengonfigurasi sistem, melakukan penerimaan, dan mendukung perubahan berikutnya. Adaptor yang membuat konektor cocok tidak menyediakan logika aplikasi yang belum ada.
Nyatakan pekerjaan integrasi dalam permintaan pembelian
Kirimkan kepada HAM model yang ada dan yang diusulkan jika diketahui, protokol serta peran perangkat, gambaran data yang tidak rahasia, jumlah, tujuan, dan kondisi yang belum terselesaikan. Kami dapat membantu menyusun pertanyaan kepada pemasok Jepang tentang kandidat dan lingkup penawaran.
Minta peralatan, lisensi, konfigurasi atau pengembangan, pekerjaan uji, dan dokumentasi sebagai item yang dapat diidentifikasi. Sebelum memesan, sepakati bukti untuk penerimaan dan pihak yang menyelesaikan persoalan integrasi tersisa. Simpan konfigurasi yang diterima untuk pembaruan firmware dan pembelian berulang.
Pertanyaan untuk dikirim kepada pemasok
Buka contoh pertanyaan untuk pemasok
Nomor model lengkap yang ada dan yang diusulkan serta opsi perangkat keras: Versi firmware, aplikasi pengendali, dan driver terkait: Antarmuka fisik, daya, dan persyaratan pemasangan: Protokol, peran kedua sisi, fungsi, dan lisensi yang diperlukan: Revisi peta data, notasi alamat, tipe, satuan, dan penskalaan: Perilaku pembaruan dan data tidak valid yang diperlukan: Persyaratan batas waktu, mulai ulang, dan putus komunikasi: Persyaratan jaringan/akses yang tidak rahasia; jangan sertakan informasi rahasia: Pasangan uji persis, konfigurasi, kriteria, dan penanggung jawab penerimaan: Lingkup sertifikasi atau demonstrasi dan perbedaan yang tersisa: Lingkup peralatan, lisensi, integrasi, uji, dan dokumentasi: Jumlah, tujuan, dan penggunaan produksi yang dimaksud: Mohon identifikasi fungsi yang tidak didukung, asumsi, perubahan yang diperlukan, dan bukti sebelum penerimaan.
Sumber
- NI — Application development with Modbus
Membaca ikhtisar HTML, penomoran tag, dan ketersediaan tipe. Digunakan untuk membedakan aplikasi/transport, alamat terdokumentasi, dan interpretasi lintas register. Bukan implementasi protokol atau uji interoperabilitas langsung.
- OPC Foundation — Certification overview and benefits
Membaca lingkup sertifikasi, profil, dan perbedaan SDK/implementasi referensi. Tidak memverifikasi sertifikat produk tertentu atau pasangan perangkat yang kompatibel.