Membawa produk dari prototipe ke ribuan unit: memahami design for manufacturing, menghitung yield dan biaya produksi, merancang production test dan provisioning firmware, serta menyusun rencana scale-up yang realistis, ditutup praktik menyusun production plan

Semua yang kalian pelajari — firmware, RTOS, security, safety, TinyML — teruji pada satu momen: saat produk diproduksi massal. Satu prototipe yang bekerja di meja kerja bisa menjadi mimpi buruk saat 1.000 unit gagal boot, atau satu dari sepuluh unit lolos QC dengan firmware salah versi.
Produksi adalah disiplin tersendiri: manufacturing (bagaimana barang dibuat), yield (berapa persen lolos), production test (memastikan tiap unit benar), dan provisioning (memberi identitas & kunci ke tiap unit). Episode ini membangun pemahaman praktisnya — dan mentalitas "desain untuk produksi" yang membedakan engineer prototype dari engineer produk.
Keputusan yang dibuat di meja desain menentukan kemudahan produksi. Prinsip DFM yang paling berdampak:
| Prinsip | Contoh praktis |
|---|---|
| Standardisasi komponen | Satu keluarga MCU/connector untuk semua produk |
| Availability | Komponen yang bisa didapat bulan depan, bukan cuma hari ini |
| Testability | Test point untuk probe produksi di PCB |
| Programming hook | Pin/programming header yang mudah diakses |
| Redundansi sourcing | Komponen bisa dari 2+ supplier |
Kesalahan klasik: mendesain PCB yang "cantik" tapi komponennya lead time 52 minggu, atau programming pad yang berada tepat di bawah heatsink sehingga tidak bisa dijangkau probe. Keputusan desain yang terlihat sepele di lab menjadi biaya dan keterlambatan di produksi.
Yield adalah persentase unit yang lolos seluruh tes produksi. Ini angka paling penting di produksi:
Produksi 1.000 unit, biaya per unit $10
Yield 98% -> 980 unit lolos, 20 unit gagal
Biaya efektif = $10.000 / 980 = $10,20/unit
Yield 90% -> 900 unit lolos, 100 unit gagal
Biaya efektif = $10.000 / 900 = $11,11/unitYield 98% vs 90% terdengar dekat, tapi perbedaan biaya efektifnya nyata — apalagi saat volume puluhan ribu. Yield yang rendah hampir selalu berakar dari desain, bukan keberuntungan: komponen di luar spek, timing marginal, atau test yang menolak unit sehat.
Dua istilah yang wajib dibedakan:
Note
Ketika yield turun, reaksi yang benar bukan menyalahkan operator, melainkan menelusuri ke akar desain. Analisis data failure (fail di tes apa, komponen mana, batch mana) hampir selalu mengarah ke satu komponen atau satu keputusan desain. Umpan balik produksi→desain inilah yang membuat generasi berikutnya jauh lebih murah.
Setiap unit yang keluar harus terbukti benar — tidak boleh "sepertinya jalan". Inilah pekerjaan production test. Rangkaian tes khas:
Kunci suksesnya adalah test fixture: jig yang menekan board, menyuntikkan sinyal, dan membaca hasil. Dan setiap tes harus menghasilkan log yang tersimpan — audit trail untuk tiap unit. Jangan sampai dua tahun kemudian tidak bisa menjawab "unit ini firmware versi berapa?"
Alur produksi khas:
SMT/assembly -> ICT test -> Flash + provisioning -> Functional test
-> Burn-in (opsional) -> Packing + label -> QC akhirProvisioning adalah proses memberi tiap unit identitas yang unik dan aman — bagian yang sering dilupakan sampai produksi dimulai. Tiap unit biasanya butuh:
| Item | Contoh | Cara aman |
|---|---|---|
| Serial number | SN-2026-000123 | Ditulis saat produksi |
| Kunci perangkat | Device certificate | Digenapkan di secure element |
| Sertifikat OTA | Client cert | Ditulis ke flash terproteksi |
| Konfigurasi pabrik | Kalibrasi, region | Ditanam saat test |
Aturan emasnya: kunci jangan pernah hardcode di firmware (episode 18) — kunci unik tiap unit dibangkitkan di provisioning. Ini melindungi: jika satu unit di-bobol, kunci yang lain tidak ikut jatuh.
Infrastruktur provisioning yang baik juga memberi inventory: database unit dengan serial, versi firmware, hasil test, dan tanggal produksi — bahan audit yang dipakai episode 17 (OTA) dan 26 (ekosistem).
Scale-up bukan sekadar "produksi lebih banyak" — ia mengubah segalanya:
| Aspek | Prototipe (10 unit) | Produksi (10.000 unit) |
|---|---|---|
| Programming | Manual, satu per satu | Automated, mass programming |
| Test | Debug manual | Test fixture otomatis + log |
| Provisioning | Serial ditulis manual | Otomatis, unique key per unit |
| Firmware update | Flash manual | OTA + provisioning awal |
| Dokumentasi | Cukup lab | Traceability penuh per unit |
Pola yang wajib disiapkan sejak prototipe: firmware yang menulis serial/identitas saat tes pertama, test yang bisa dijalankan otomatis, dan log yang bisa di-query. Mempersiapkan ini di awal jauh lebih murah daripada merombak saat produksi sudah berjalan.
Susun production plan satu halaman untuk produk kalian:
Warning
Jangan pernah mengunci keamanan produksi (RDP, secure element, kunci provisioning) sebelum alur tes dan OTA benar-benar bekerja di skala nyata. Di episode 18 kita membahas kenapa. Di skala 10.000 unit, kesalahan urutan ini berarti ribuan unit yang tidak bisa diperbaiki — dan itu bukan teoretis, itu sudah terjadi berkali-kali di industri.
Inti yang harus dibawa pulang:
Di episode 26 selanjutnya kita menengok ke masa depan: ekosistem & tren modern 2026 — TinyML tercepat, Rust mainstream, security-by-design, Matter, dan edge computing, lengkap dengan peta gaji dan arah industri. Ini kompas yang akan memandu pilihan karier kalian. Sampai jumpa di episode 26!