Dalam artikel tersebut, terlepas dari kenyataan bahwa itu, tentu saja, PR murni dan berbicara tentang produk keren kami (pendapat penulis), saya mencoba menggambarkan pengalaman kami yang bermanfaat.
Masalah apa yang kami dan klien kami temui ketika mengatur pengembangan perangkat lunak untuk perangkat jarak jauh, bagaimana mereka dipecahkan, dan di mana Redd, kompleks perangkat lunak dan perangkat keras pengembangan perangkat lunak jarak jauh untuk sistem tertanam, "tumbuh kaki" dari. Mengapa "kotak" ini muncul, dan bagaimana kehidupan (sekali lagi, pendapat penulis) mengubah jutaan pengembang sistem embedded, Internet perangkat hal-hal, peralatan untuk mobil, pesawat terbang, komunikasi.
Saya bekerja untuk perusahaan yang secara sederhana disebut
MIR . Jangan bingung dengan sistem pembayaran, kami tidak ada hubungannya dengan sistem pembayaran.
WORLD dalam kasus kami adalah singkatan dari Workshop of Development Tools.
Kami mengembangkan perangkat lunak sistem untuk pelanggan Rusia dan asing. Klien tipikal adalah produsen mikrokontroler dan mikroprosesor, biasanya dengan beberapa non-standar, diperluas relatif terhadap standar, dan mungkin dengan arsitekturnya sendiri.
Bagi mereka, kami mengembangkan alat pengembangan: IDE, kompiler, sistem operasi waktu-nyata, debugger, simulator, profiler, dan komponen SDK lainnya.
Secara paralel, kami juga mengambil pengembangan perangkat lunak untuk sistem tertanam. Misalnya, untuk pembuat mobil Jerman kami membuat perangkat lunak untuk dasbor modern. Kami juga melakukan proyek-proyek di bidang avionik, mengembangkan perangkat lunak untuk mengatur jaringan mesh "smart meter" dan drone, membuat perangkat lunak khusus untuk sistem kontrol akses, dan bekerja di pasar IoT (soket pintar, misalnya). Secara umum, ada banyak proyek menarik di mana ternyata mendapatkan pengalaman yang tidak standar dalam memecahkan masalah yang muncul.
Untuk pelanggan, kami adalah pengembang eksternal. Selain itu, kami berlokasi di St. Petersburg, Veliky Novgorod, dan Krasnoyarsk, dan klien kami berada di Moskow, Zelenograd, Tula, Voronezh, Jerman dan Korea.
Pada saat yang sama, kami mengembangkan perangkat lunak untuk perangkat. Dan untuk memprogram perangkat tertentu, programmer perlu memiliki perangkat ini.
Jika seseorang tiba-tiba tidak terbiasa dengan "teknologi": Anda memerlukan komputer yang berfungsi di mana alat pengembangan yang diperlukan, seperti IDE, diinstal. Perangkat harus terhubung ke komputer yang sama: papan debug, dasbor (jika kita berbicara tentang pengembangan mobil). Itu terlihat seperti pada gambar:
Pengembang menulis kode di komputer dan mengunduhnya ke perangkat tempat dieksekusi.
Jelas bahwa tanpa perangkat itu sendiri tidak mungkin untuk memeriksa operabilitasnya, tidak mungkin untuk men-debug atau mengoptimalkan. Selain itu, penting bagi programmer untuk melihat apa yang terjadi dengan perangkat secara fisik: LED mana yang berkedip, apa yang ditampilkan pada layar, di mana roda berputar.
Masalah Pengembang
Dan di sini masalahnya dimulai.
Yang pertama kami temui adalah ketersediaan peralatan.
Banyak perusahaan membuat karya-karya unik pada tahap awal produksi. Mereka hanya secara fisik di dunia ini ada satu, dua atau lima potong. Mentransfer mereka ke pengembang eksternal (kepada kami) adalah masalah besar dan tugas yang sulit bagi pelanggan. Mungkin tidak ada perangkat gratis.
Sebagai contoh, seperti halnya dengan prosesor baru 1967044 dari JSC PKK Milander. Itu masih dalam kondisi penyelesaian OCD, tetapi alat pengembangan untuk itu harus dilakukan sekarang.
Masalah kedua , ketika ada beberapa produk, banyak masalah perangkat keras muncul di dalamnya. Dan, jika produk datang kepada kami dari Moskow, dan kami menemukan kesalahan dalam perangkat keras, kami dapat mentransfer produk ke produsen untuk koreksi dalam satu hari. Dan apakah produk tersebut berasal dari Jerman? Anda perlu mengirim produk kembali ke pengembang, menunggu koreksi dan kembali. Semua ini tidak cepat atau mahal. Dan masih ada downtime untuk programmer dan tenggat waktu proyek bergeser sementara kami menunggu perangkat yang diperbaiki. Dan juga ada pelanggan yang mengangkut perangkat hanya secara pribadi untuk alasan keamanan. Namun, kesalahan perangkat keras biasanya jauh lebih umum daripada yang bisa terjadi.
Secara umum, kehadiran perbatasan di dunia adalah salah satu kendala serius yang terus-menerus menimbulkan ketidaknyamanan. Pengiriman peralatan bahkan dari Eropa yang dekat dengan kita berubah menjadi sebuah pencarian, tetapi dari Korea atau Amerika Serikat ... Saya tidak akan merinci masalah yang muncul dan bagaimana menyelesaikannya, saya hanya bisa mengatakan bahwa semuanya meningkatkan waktu dan biaya proyek untuk pelanggan. Itu berarti mereka mengurangi daya saing kita.
Masalah lain adalah peralatan itu bisa pecah. Transportasi adalah peningkatan risiko kerusakan peralatan, ditambah hilangnya waktu dan biaya logistik. Peralatan harus diputuskan, dikemas, ditransfer, dibongkar, dihubungkan dan dikonfigurasikan, termasuk dalam stand.
Sekarang bayangkan Anda sedang mengembangkan alat analisis gas, yang dilengkapi dengan beberapa silinder besar dan berat ...
atau sistem semprotan untuk helikopter.
Sekarang debugging sistem seperti itu harus dilakukan pada emulator, meskipun akan jauh lebih nyaman untuk memeriksa beberapa hal dari jarak jauh (misalnya, kontrol PID dari mesin semprot, ketika pelanggan pada awal musim percobaan dengan memasang mesin injeksi atau karburator, atau memutar resistor variabel dalam sistem kontrol mereka) .
Tetapi masalah muncul bahkan jika programmer berada di gedung yang sama.
Peralatan dapat "hilang" jika tidak ada proses transfer formal dan terjadi di antara programmer dalam proyek. Atau peralatan bisa "pergi" ke pengembang untuk waktu yang lama, jika ada proses formal, tetapi birokratis. Saya tidak bisa mengatakan bahwa kami benar-benar kehilangan peralatan pelanggan, tetapi ada situasi ketika tidak jelas siapa yang sebenarnya memiliki papan debugging saat ini, dan berapa lama itu masih sibuk. Situasinya tidak kritis, diselesaikan dalam lima menit, tetapi ada banyak proyek. Mengapa menghabiskan waktu ekstra?
Masalahnya diperparah oleh fakta bahwa programmer adalah orang yang sangat kecanduan. Akibatnya, jika ada persaingan di antara mereka untuk biaya yang sama (dan ini sering terjadi, karena kami terutama bekerja dengan perangkat keras yang unik), maka "overlay" sementara dan waktu henti bagi karyawan yang menunggu tidak bisa dihindari.
Dan bahkan jika Anda seorang pemimpin yang brilian dan membangun proses dan logistik yang sangat baik, Anda masih akan kehilangan efisiensi dengan memecahkan solusi pemrograman jarak jauh tanpa bergerak.
Misalnya, dalam kasus seperti itu. Pada tahap akhir pengembangan, pengujian dimulai. Dan itu tidak terjadi setelahnya, tetapi seiring dengan perkembangan, dalam sebuah siklus. Penguji memeriksa fungsi yang dibuat, menemukan kesalahan, kemudian programmer memperbaiki bug, kemudian pengujian diperlukan, dan sebagainya. Peralatan dalam proyek yang sama dibutuhkan oleh pengembang dan penguji. Dan jika kantor Anda berlokasi, misalnya, di Krasnoyarsk dan di Veliky Novgorod, peralatan dapat bekerja hampir sepanjang waktu. Siang dan malam (di Moskow), programmer dari Novgorod menulis kode, dan kemudian di pagi hari (karena perbedaannya adalah 4 jam), penguji Krasnoyarsk terhubung dan sepenuhnya menguji pada peralatan yang sama selama jam kerja mereka.
Solusi tradisional
Kesimpulannya jelas - bekerja dengan besi dari jarak jauh bisa sangat menguntungkan. Anda perlu meletakkan semua perangkat keras di satu tempat dan memberikan akses jarak jauh tim.
Pengembang bergantian menyambung ke perangkat, bekerja dengannya, menyelesaikan tugas dan memutuskan koneksi, membebaskan ruang untuk yang berikutnya.
Dan segala sesuatu dalam skema ini akan bagus, tetapi menggunakan akses jarak jauh standar ke komputer yang terhubung ke produk tidak berfungsi.
Paling sering,
tidak mungkin untuk menggunakan antarmuka yang berbeda untuk menghubungkan perangkat keras: biasanya komputer memiliki perangkat yang terbatas, dan tidak mungkin untuk terhubung langsung ke papan debug tanpa adaptor. Misalnya, Anda perlu membeli seorang programmer yang memungkinkan koneksi jarak jauh.
Jika Anda masih dapat terhubung, pengembang masih
tidak akan dapat mengontrol pengaturan daya perangkat: itu norak untuk tidak me-reboot perangkat. Untuk menekan tombol on / off atau mencabut steker kabel listrik, Anda harus memanggil seorang kolega di kantor sehingga ia pergi dan melakukannya dengan tangan.
Dan kemudian seorang kolega yang pemrogramnya "merobohkan pikiran" harus kembali ke sana selama 5-10 menit, ini tidak termasuk waktu dia berjalan dan dia diberitahu di telepon yang beralih untuk menarik. Jadi jalankan jam kerja dan puluhan jam kerja sekaligus di beberapa proyek yang tidak terkait dengan saat ini.
Selain itu,
tidak jelas apa yang terjadi pada perangkat secara fisik . Apa yang ditampilkan di layar atau indikator perangkat yang dikembangkan, bagaimana LED berkedip. Itu tidak selalu perlu, tetapi kebutuhan seperti itu biasanya muncul pada saat yang paling tidak tepat.
Tentu saja, ada opsi untuk mencoba menghindari batasan-batasan ini. Beli relay yang dikendalikan dari jarak jauh sehingga dimungkinkan untuk me-reboot perangkat, webcam untuk memantau, me-mount semuanya dan mengonfigurasi. Lebih lanjut, jika kita berhasil menyampaikan kepada semua orang bagaimana bekerja dengan ini, ke mana harus "masuk" dan apa yang harus dilakukan dalam urutan yang benar, maka kita akan mendekati solusi ...
Kecuali bahwa ketika ada lebih banyak pengembang daripada perangkat, tidak
ada organisasi proses akses yang terpusat dan jelas . Dan ketika bekerja dengan tim, Anda harus menyetujui secara terpisah siapa dan kapan bekerja dengan peralatan tersebut.
Redd - kompleks pemrograman jarak jauh
Gagasan untuk menyelesaikan semua masalah yang disuarakan secara komprehensif ada di permukaan, dan bahkan pada awalnya kami tidak dapat memahami mengapa tidak ada yang melakukan hal seperti ini ketika kami mulai mencari pesaing. Kami menemukan beberapa solusi, tetapi lebih rendah, di beberapa bagian. Semua orang melakukan sesuatu di bidangnya: seseorang murni men-debug JTAG, seseorang meniru, tetapi Anda juga perlu men-debug, dan berdiri untuk menjadi, dan mengamati, dan kekuatan, dan kontrol akses. Di kompleks, tidak ada yang melakukannya, dan tidak ada solusi yang berfungsi penuh.
Oleh karena itu, kami mulai mengembangkan Redd (singkatan dari Remote development device). Ini adalah kompleks perangkat keras-perangkat lunak yang mengatur akses ke peralatan mikroelektronik melalui Internet atau jaringan lokal menggunakan sejumlah protokol komunikasi standar dan kustom.
Kami tidak mengejar "inovasi nano". Sebenarnya, Redd hanya bisa dimengerti dan teknologi sederhana digabungkan dalam satu perangkat, yang secara total memberikan solusi untuk masalah yang saya jelaskan di atas.
Redd dapat terhubung ke perangkat melalui berbagai antarmuka, yang menghilangkan masalah bekerja dengan sejumlah besar perangkat, mampu mengelola daya, dan sekarang Anda dapat reboot perangkat tanpa bantuan. Ada kamera video di mana pengembang melihat apa yang terjadi dengan perangkat secara real time.
Plus, bagian server dari produk memungkinkan Anda memesan peralatan melalui antarmuka kalender dan mengontrol akses.
Secara teknis, Redd terdiri dari dua komponen tergantung: "terminal jarak jauh" dan perangkat lunak server.
Terminal jarak jauh adalah komputer yang kompatibel dengan PC yang berbasis pada prosesor Intel, dilengkapi dengan papan ekspansi antarmuka, yang kami sendiri kembangkan. Dalam versi pertama (pada bulan Maret) Ethernet dan USB Host (JTAG) akan tersedia. Dalam yang kedua (pada bulan Juni) - UART, Ethernet, GPIO, SPI (+ SPI flash), SDIO (dengan adaptor untuk emulator kartu SD), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, sakelar daya untuk switching daya dan logis tombol untuk aktivasi, misalnya, tombol.
Perangkat ini memiliki set antarmuka yang paling umum digunakan, ditambah ada FPGA untuk mengimplementasikan hal-hal yang tidak standar. Karena sistem dirancang dalam kompleks, tidak adanya konflik timbal balik dijamin. Dan antarmuka akan berubah dari proyek ke proyek bersama dengan kompleks, tanpa perlu membeli sesuatu yang tambahan.
UPD: seperti inilah tampilan papan eksternal dengan konektor antarmuka Redd. Ini "menempel" ke konektor di panel depan dan memungkinkan penggunaan antarmuka standar. Meskipun varian juga dimungkinkan, yang ditampilkan di foto lain, tanpa papan.
Peralatan yang dikembangkan seringkali tidak mungkin untuk terus-menerus diuji dalam kondisi pertempuran. Sebuah helikopter hanya membayar 50 Euro untuk pengiriman dukungan untuk tinggal landas dan mendarat. Mengemudi mobil sepanjang waktu itu tidak realistis. Kapal tidak selalu melaut. Secara umum, kita membutuhkan emulator.
Bagaimana sistem berkomunikasi dengan dunia luar? Melalui sensor yang terhubung ke berbagai bus. Nah, sinyal ke aktuator juga dikeluarkan di bus. Kisaran ban saat ini cukup lebar. Ini bisa berupa CAN, UART (dalam versi CMOS, RS232, RS485), Ethernet, MODBUS (melalui UART atau Ethernet yang sama), saluran digital dengan level yang berbeda dan seterusnya, seterusnya, seterusnya.
Solusi tipikal adalah membuat emulator sensor dan aktuator dengan menghubungkannya ke bus. Peralatan yang sedang dikembangkan akan mempertimbangkan bahwa ia menerima informasi nyata, dan pengembang akan meniru berbagai skenario kerja nyata, men-debug algoritma kerja. Tentu saja, untuk setiap proyek, Anda dapat membeli pengontrol berbagai antarmuka dan menghubungkannya.
Atau Anda dapat menghubungkan Redd alih-alih sensor dan pemain ini, menulis simulator dari pekerjaan mereka (yaitu, mereka, yaitu, kami mensimulasikan lingkungan eksternal), dan kemudian men-debug perangkat yang sedang dikembangkan yang berpikir itu ada di dalam mobil atau di tempat lain, dan kami melakukannya debugging target logic. Dan penguji melalui mekanisme ini akan dapat memeriksa batas dan bahkan situasi yang salah sengaja yang sangat sulit atau sama sekali tidak mungkin untuk mereproduksi dalam pengujian biasa.
Bagian server dari kompleks terletak langsung di terminal. Pengembang melalui web dapat melihat perangkat mana dan kapan waktu tersedia baginya. Dapat memesannya di kalender sehingga ia secara otomatis diberikan akses. Ia terhubung melalui protokol ssh ke terminal, dan dengannya, ke debugger dan pengelolaan emulator perangkat. Selain itu, mode operasi Redd bisa tidak hanya multi-pengguna, tetapi juga dengan koneksi simultan dari beberapa perangkat.
Dengan demikian, Redd memungkinkan mengatur akses jarak jauh dari pengembang internal atau eksternal ke perangkat (atau sekelompok perangkat, dimungkinkan untuk menghubungkan beberapa perangkat ke satu terminal), merencanakan dan mengelola akses dari waktu ke waktu, tanpa gerakan fisik.
Bonus tambahan - Redd juga dapat digunakan untuk menunjukkan produk kepada pelanggan eksternal dan pelanggan tanpa transfer yang sebenarnya. Atau untuk mengatur pemrograman perangkat pembelajaran jarak jauh, yang mungkin menarik bagi produsen mikroprosesor atau untuk lembaga pendidikan.
Apa sekarang?
Sekarang kami sedang menyelesaikan pengembangan versi pertama, itu akan dirilis pada awal Maret, dan sudah
tersedia untuk pre-order (tentu saja, dengan syarat preferensial).
Tujuan utama artikel ini (kecuali untuk iklan) adalah untuk mengumpulkan umpan balik.
Tulis jika Anda tidak setuju bahwa ada masalah yang dijelaskan dalam artikel, atau Anda dapat menyebutkan masalah yang saya lupa.
Mungkin Anda tahu solusi yang belum kami temukan, atau Anda memecahkan masalah ini dengan cara Anda sendiri.
Atau mereka siap mendukung kami dengan kata yang baik (atau mungkin tidak hanya) dalam pengembangan produk.
Saya akan senang berkomentar.