Manufaktur industri
Industri Internet of Things | bahan industri | Pemeliharaan dan Perbaikan Peralatan | Pemrograman industri |
home  MfgRobots >> Manufaktur industri >  >> Industrial Internet of Things >> Teknologi Internet of Things

Taksonomi untuk IIoT

Raja Bermain Catur Di Kursi Kaca Halus. Ada yang ingat ini?

Bagi sebagian besar, itu mungkin omong kosong. Tapi tidak untuk saya. Mnemonic ini membantu saya mengingat taksonomi kehidupan:Kingdom, Phylum, Class, Order, Family, Genus, Species.

Luas dan dalamnya serta keragaman kehidupan di Bumi sangat banyak. Taksonomi secara logis membagi jenis sistem berdasarkan karakteristiknya. Ilmu Biologi tidak akan mungkin tanpa taksonomi yang baik. Hal ini memungkinkan para ilmuwan untuk mengklasifikasikan tumbuhan dan hewan ke dalam tipe logis, mengidentifikasi kesamaan, dan membangun aturan untuk memahami seluruh kelas sistem kehidupan.

Luas dan dalamnya serta keragaman Industrial Internet of Things (IIoT) juga luar biasa. Ilmu Sistem IIoT membutuhkan taksonomi jenis aplikasi yang terorganisir serupa. Hanya dengan demikian kita dapat melanjutkan untuk membahas arsitektur dan teknologi yang sesuai untuk mengimplementasikan sistem.

Masalah pertama adalah memilih divisi tingkat atas. Di Kerajaan Hewan, Anda dapat melabeli sebagian besar hewan sebagai hewan "darat, laut, atau udara". Namun, deskripsi lingkungan itu tidak banyak membantu dalam memahami hewan. "Arsitektur" paus tidak seperti gurita, tetapi sangat mirip beruang. Untuk dipahami, hewan harus dibagi berdasarkan karakteristik dan arsitekturnya.

Juga tidak berguna untuk membagi aplikasi berdasarkan industri mereka seperti "medis, transportasi, dan listrik." Meskipun lingkungan ini penting, arsitektur dan teknologi yang berlaku tidak hanya terbagi di sepanjang garis industri. Di sini sekali lagi, kita membutuhkan pemahaman yang lebih mendalam tentang karakteristik yang menentukan tantangan utama, dan tantangan tersebut akan menentukan arsitektur.

Saya menyadari bahwa ini adalah klaim yang kuat, bahkan mengejutkan. Ini menyiratkan, misalnya, bahwa standar, protokol, dan arsitektur yang dipesan lebih dahulu di setiap industri bukanlah cara yang berguna untuk merancang arsitektur sistem IIoT masa depan . Meskipun demikian, ini adalah fakta yang jelas dari sistem di lapangan. Seperti dalam transformasi yang menjadi Internet perusahaan, teknologi generik akan menggantikan pendekatan tujuan khusus. Untuk menumbuhkan pemahaman kita dan mewujudkan janji IIoT, kita harus meninggalkan pemikiran lama spesifik industri kita.

Jadi, apa yang bisa kita gunakan untuk pembagian? Karakteristik penentu apa yang dapat kita gunakan untuk memisahkan Mamalia dari Reptil dari Serangga IIoT?

Ada beribu-ribu kebutuhan, baik fungsional maupun non-fungsional, yang bisa digunakan. Seperti pada hewan, kita perlu menemukan beberapa persyaratan yang membagi ruang menjadi kategori utama yang berguna.

Tugas disederhanakan dengan kesadaran bahwa tujuannya adalah untuk membagi ruang sehingga kita dapat menentukan arsitektur sistem . Dengan demikian, kriteria pembagian yang baik adalah a) tidak ambigu dan b) berdampak pada arsitektur. Itu mungkin terdengar mudah, tetapi sebenarnya sangat tidak sepele. Satu-satunya cara untuk melakukannya adalah melalui pengalaman. Kami berada di awal pencarian kami. Namun, kemajuan signifikan ada dalam genggaman kita bersama.

Dari pengalaman luas RTI dengan hampir 1000 aplikasi IIoT dunia nyata, saya menyarankan beberapa divisi awal di bawah ini. Agar sejelas mungkin, saya juga memilih "metrik" untuk setiap divisi. Garis-garisnya, tentu saja, tidak terlalu mencolok. Tetapi angka-angka itu memaksa kejelasan, dan itu sangat penting; tanpa tolok ukur numerik (meteran?), artinya terlalu sering hilang.

Proposal Taksonomi IIoT

Keandalan [Metrik:Ketersediaan berkelanjutan harus lebih baik dari “99,999%”]

Kami tidak bisa puas dengan basa-basi "sangat dapat diandalkan." Hampir semuanya “membutuhkan” itu. Agar bermakna, kita harus lebih spesifik tentang tuntutan arsitektur untuk mencapai keandalan itu. Itu membutuhkan pemahaman tentang seberapa cepat kegagalan menyebabkan masalah dan seberapa buruk masalah itu.

Kami telah menemukan bahwa cara paling sederhana dan paling berguna untuk mengkategorikan keandalan adalah dengan bertanya:"Apa konsekuensi dari kegagalan tak terduga selama 5 menit per tahun?" (Kami memilih 5 menit/tahun di sini hanya karena itu adalah spesifikasi emas “5-9 detik” untuk server kelas perusahaan. Banyak sistem industri tidak dapat mentolerir bahkan beberapa milidetik waktu henti yang tidak terduga.)

Ini merupakan karakteristik penting karena sangat mempengaruhi arsitektur sistem. Sebuah sistem yang tidak dapat gagal, bahkan untuk waktu yang singkat, harus mendukung komputasi yang berlebihan, sensor, jaringan, dan banyak lagi. Ketika keandalan benar-benar penting, dengan cepat menjadi — atau mungkin — penggerak arsitektur utama.

Waktu Nyata [Metrik:Respons <100 md]

Ada ribuan cara untuk mencirikan "waktu nyata". Semua sistem harus "cepat". Namun agar bermanfaat, kita harus secara khusus memahami persyaratan kecepatan mana yang mendorong arsitektur.

Arsitektur yang dapat memuaskan pengguna manusia yang tidak mau menunggu lebih dari 8 detik untuk sebuah situs web tidak akan pernah memuaskan kontrol industri yang harus merespons dalam 2 ms. Kami menemukan "lutut dalam kurva" yang sangat berdampak pada desain terjadi ketika kecepatan respons diukur dalam beberapa puluh milidetik (ms) atau bahkan mikrodetik (µs). Kami akan memilih 100ms, hanya karena itu tentang potensi jitter (latensi maksimum) yang dikenakan oleh server atau broker di jalur data. Sistem yang merespon lebih cepat dari ini biasanya harus peer-to-peer, dan itu adalah dampak arsitektural yang sangat besar.

Skala Kumpulan Data [Metrik:Ukuran kumpulan data> 10.000 item]

Sekali lagi, ada ribuan dimensi untuk diskalakan, termasuk jumlah “node”, jumlah aplikasi, jumlah item data, dan banyak lagi. Kita tidak dapat membagi ruang dengan semua parameter ini. Dalam praktiknya, mereka terkait. Misalnya, sistem dengan banyak item data mungkin memiliki banyak node.

Terlepas dari ruang yang luas, kami telah menemukan bahwa dua pertanyaan sederhana berkorelasi dengan persyaratan arsitektur. Yang pertama adalah "ukuran kumpulan data", dan lutut di kurva adalah sekitar 10 ribu item. Ketika sistem menjadi sebesar ini, tidak praktis lagi mengirim setiap pembaruan data ke setiap penerima yang memungkinkan. Jadi, mengelola data itu sendiri menjadi kebutuhan arsitektur utama. Sistem ini memerlukan desain "sentris data" yang secara eksplisit memodelkan data sehingga memungkinkan pemfilteran dan pengiriman selektif.

Skala Tim atau Aplikasi [Metrik:jumlah tim atau aplikasi yang berinteraksi>10]

Parameter skala kedua yang kami pilih adalah jumlah tim atau aplikasi yang dikembangkan secara independen pada "proyek", dengan titik henti sekitar 10. Ketika banyak grup pengembang independen membangun aplikasi yang harus berinteraksi, kontrol antarmuka data mendominasi tantangan interoperabilitas. Sekali lagi, ini sering menunjukkan perlunya desain data-sentris yang secara eksplisit memodelkan dan mengelola antarmuka ini.

Tantangan Penemuan Data Perangkat [Metrik:>20 jenis perangkat dengan kumpulan data multi-variabel]

Beberapa sistem IIoT dapat (atau bahkan harus) dikonfigurasi dan dipahami sebelum runtime. Ini tidak berarti bahwa setiap sumber data dan sink diketahui, melainkan hanya konfigurasi ini yang relatif statis.

Namun, ketika sistem IIoT mengintegrasikan rak dan rak mesin atau perangkat, mereka harus sering dikonfigurasi dan dipahami selama operasi. Misalnya, pengontrol pabrik HMI mungkin perlu menemukan karakteristik perangkat dari perangkat atau rak yang terpasang sehingga pengguna dapat memilih data untuk dipantau. Pilihan "20" perangkat yang berbeda adalah sewenang-wenang. Intinya:ketika ada banyak konfigurasi yang berbeda untuk perangkat di rak, "introspeksi" ini menjadi kebutuhan arsitektur yang penting untuk menghindari senam manual. Sebagian besar sistem dengan karakteristik ini memiliki lebih dari 20 jenis perangkat.

Fokus Distribusi [Metrik:Penyebaran> 10]

Kami mendefinisikan "keluar" sebagai jumlah penerima data yang harus diinformasikan pada perubahan item data tunggal. Ini berdampak pada arsitektur karena banyak protokol bekerja melalui koneksi 1:1 tunggal. Sebagian besar dunia perusahaan bekerja dengan cara ini, seringkali dengan TCP, protokol sesi 1:1. Contohnya termasuk menghubungkan browser ke server web, aplikasi telepon ke backend, atau bank ke perusahaan kartu kredit.

Namun, sistem IIoT seringkali perlu mendistribusikan informasi ke lebih banyak tujuan. Jika satu item data harus pergi ke banyak tujuan, arsitektur harus mendukung beberapa pembaruan yang efisien. Saat fan out melebihi 10 atau lebih, menjadi tidak praktis untuk melakukan percabangan ini dengan mengelola satu set koneksi 1:1.

Fokus Koleksi [Metrik:Aliran data satu arah dengan kipas di> 100]

Sistem yang pada dasarnya terbatas pada masalah pengumpulan tidak berbagi data yang signifikan antar perangkat. Mereka malah mengirimkan banyak informasi untuk disimpan atau dianalisis di server tingkat yang lebih tinggi atau cloud.

Ini memiliki dampak arsitektur yang besar. Sistem pengumpulan sering kali dapat menggunakan "konsentrator" hub-and-spoke atau bahkan desain server berbasis cloud.

Manfaat Taksonomi

Mendefinisikan taksonomi IIoT tidak akan sepele. Blog ini hanya menggores permukaan. Namun, manfaatnya sangat besar. Menyelesaikan kebutuhan ini akan membantu arsitek sistem memilih protokol, topologi jaringan, dan kemampuan komputasi. Hari ini, kita melihat desainer berjuang dengan masalah seperti lokasi atau konfigurasi se

[1] [2] 下一页

Teknologi Internet of Things

  1. Memantau Kesehatan Sistem IIoT Anda
  2. Membangun Sistem Manufaktur yang Fleksibel untuk Industri 4.0
  3. Menangani Lanskap Ancaman yang Berkembang dari ICS dan IIoT
  4. Manfaat mengadaptasi IIoT dan solusi analisis data untuk EHS
  5. Prospek pengembangan IoT Industri
  6. Manfaat Menggunakan Visi Robotik untuk Aplikasi Otomasi
  7. Apa yang Akan Dilakukan 5G untuk IoT/IIoT?
  8. Terima kasih atas Kenangannya!
  9. Sistem Kompresor Udara:Tip untuk Liburan Musim Dingin
  10. Sistem Hidraulik &Kebutuhan Pemeliharaan