Air terjun sangat memukau karena sifatnya, jadi tidak mengherankan jika para insinyur sedikit terobsesi dengan mereka. Standar DOD-STD-2167A lama direkomendasikan menggunakan model air terjun, dan latar belakang teknik warisan saya didasarkan pada model Fase-Gerbang , yang menurut saya sangat mirip dengan model air terjun. Di sisi lain, kita yang mempelajari ilmu komputer di universitas mungkin tahu bahwa model air terjun dalam beberapa cara anti-pola . Teman-teman kita di menara gading akademik memberi tahu kita tidak, tidak, AgileApakah jalan menuju sukses dan sepertinya industri telah membuktikan bahwa klaim itu benar.
Jadi, apa yang harus seorang pengembang pilih antara model air terjun penuaan dan Agile bermodel? Apakah persamaan berubah ketika datang untuk mengembangkan algoritma? Atau beberapa perangkat lunak keamanan penting?
Seperti biasa dalam hidup, jawabannya ada di antara keduanya.
Hibrid, spiral, dan V-pola
Pengembangan hibrida adalah jawaban yang berada di tengah. Di mana model air terjun tidak memungkinkan untuk kembali dan mengubah persyaratan, model hybrid melakukannya. Dan di mana Agile memiliki masalah dengan desain dimuka, pengembangan hibrida menyisakan ruang untuk itu. Selain itu, pengembangan hibrida bertujuan untuk mengurangi jumlah cacat pada produk akhir, yang mungkin kita inginkan saat merancang algoritme untuk aplikasi keamanan-kritis.
Kedengarannya bagus, tetapi seberapa efektif itu?
Untuk menjawab pertanyaan ini, kami bertaruh pada pengembangan hibrida sambil bekerja pada algoritma lokalisasi NDT.... Lokalisasi adalah bagian penting dari setiap tumpukan self-driving yang melampaui kontrol reaktif murni. Jika Anda tidak mempercayai saya atau tidak terbiasa dengan lokalisasi, saya sangat menyarankan Anda melihat beberapa dokumen desain yang telah dikembangkan melalui proses ini.
Jadi, apa sih perkembangan hibrida secara singkat? Dari sudut amatir pandang saya, saya akan mengatakan bahwa ini adalah ideal berbentuk V , atau model spiral . Anda merencanakan, merancang, mengimplementasikan dan menguji, dan kemudian mengulangi seluruh proses berdasarkan pelajaran yang dipetik dan pengetahuan baru yang Anda peroleh selama waktu itu.
Penggunaan praktis
Lebih khusus lagi, kami, dengan kelompok kerja NDT di Autoware.Auto, telah menyelesaikan penurunan pertama kami di kaskade kiri model-V (mis., Kami telah membuat iterasi pertama melalui fase desain) untuk persiapan Autoware Hackathon di London (dijalankan oleh Parkopedia !). Lulus pertama kami melalui fase desain terdiri dari langkah-langkah berikut:
- Tinjauan Literatur
- Tinjauan umum implementasi yang ada
- Merancang komponen tingkat tinggi, kasus penggunaan dan persyaratan
- Analisis kesalahan
- Definisi metrik
- Arsitektur dan desain API
Anda dapat melihat pada masing-masing dokumen yang dihasilkan jika Anda tertarik pada sesuatu yang serupa, tetapi untuk sisa posting ini saya akan mencoba untuk memecah beberapa dari mereka, dan juga menjelaskan apa dan mengapa itu terjadi pada masing-masing tahap ini.
Tinjauan literatur dan implementasi yang ada
Langkah pertama dalam setiap upaya yang layak (yang adalah bagaimana saya akan mengklasifikasikan implementasi NDT) adalah untuk melihat apa yang telah dilakukan orang lain. Bagaimanapun, manusia adalah makhluk sosial, dan semua pencapaian kita berada di pundak para raksasa.
Selain kiasan, ada dua bidang penting untuk dipertimbangkan ketika mempertimbangkan "seni masa lalu": literatur akademik dan realisasi fungsional.
Selalu membantu untuk melihat apa yang sedang dilakukan oleh mahasiswa pascasarjana yang miskin di tengah kelaparan. Paling-paling, Anda akan menemukan bahwa ada algoritma yang sangat sempurna yang dapat Anda terapkan alih-alih sendiri. Dalam kasus terburuk, Anda akan mendapatkan pemahaman tentang ruang dan variasi keputusan (yang dapat membantu arsitektur informasi), dan Anda juga akan dapat belajar tentang beberapa dasar teoretis dari algoritma (dan dengan demikian invarian apa yang harus Anda perhatikan ).
Di sisi lain, sama bermanfaatnya untuk melihat apa yang dilakukan orang lain - lagipula, selalu paling mudah untuk mulai melakukan sesuatu dengan prompt awal. Anda tidak hanya dapat meminjam ide-ide arsitektur yang baik secara gratis, tetapi Anda juga dapat menemukan beberapa tebakan dan trik kotor yang mungkin Anda perlukan agar algoritme berfungsi dalam praktiknya (dan Anda bahkan dapat mengintegrasikannya ke dalam arsitektur Anda).
Dari ulasan kami tentang literatur NDT , kami telah mengumpulkan informasi berguna berikut:
- Algoritma NDT keluarga memiliki beberapa variasi:
- P2D
- D2D
- Terbatas
- Semantik - Ada banyak trik kotor yang dapat digunakan untuk membuat algoritma berkinerja lebih baik.
- NDT biasanya dibandingkan dengan ICP
- NDT sedikit lebih cepat dan sedikit lebih andal.
- NDT beroperasi dengan andal (memiliki tingkat keberhasilan tinggi) dalam area yang ditentukan
Tidak ada yang luar biasa, tetapi informasi ini dapat disimpan untuk digunakan nanti, baik dalam desain dan implementasi.
Demikian juga, dari tinjauan umum kami terhadap implementasi yang ada, kami melihat tidak hanya langkah konkret tetapi juga beberapa strategi inisialisasi yang menarik.
Gunakan kasing, persyaratan dan mekanisme
Bagian integral dari setiap proses pengembangan desain-atau-rencana-pertama adalah untuk mengatasi masalah yang Anda coba selesaikan di tingkat tinggi. Dalam arti luas, dari sudut pandang keselamatan fungsional (yang, saya akui, saya jauh dari ahli), "pandangan tingkat tinggi masalah" diatur kira-kira sebagai berikut:
- Kasus penggunaan apa yang Anda coba selesaikan?
- Apa persyaratan (atau batasan) untuk solusi untuk memenuhi kasus penggunaan di atas?
- Mekanisme apa yang memenuhi persyaratan di atas?
Proses yang dijelaskan di atas memberikan pandangan tingkat tinggi yang disiplin tentang masalah dan secara bertahap menjadi lebih rinci.
Untuk mendapatkan gambaran seperti apa ini, Anda dapat melihat pada dokumen proyek pelokalan tingkat tinggi yang kami kumpulkan sebagai persiapan untuk pengembangan NDT. Jika Anda tidak ingin membaca sebelum tidur, baca terus.
Gunakan kasing
Saya suka tiga pendekatan pemikiran untuk menggunakan kasus (perhatian, saya bukan ahli keamanan fungsional):
- Apa yang harus dilakukan komponen? (ingat SOTIF !)
- Apa cara saya dapat memasukkan input ke dalam komponen? (menggunakan input case, saya suka menyebutnya upstream)
- Apa cara saya bisa mendapatkan output? (kasus penggunaan akhir pekan atau top-down)
- Pertanyaan bonus: Dalam arsitektur sistem apa seluruh komponen ini bisa berada?
Menyatukan semuanya, kami datang dengan yang berikut:
- Sebagian besar algoritma dapat menggunakan pelokalan, tetapi pada akhirnya mereka dapat dibagi menjadi citarasa yang bekerja baik secara lokal maupun global.
- Algoritme lokal membutuhkan kesinambungan dalam sejarah transformasi mereka.
- Hampir semua sensor dapat digunakan sebagai sumber data lokalisasi.
- Kami membutuhkan cara untuk menginisialisasi dan memecahkan masalah metode pelokalan kami.
Terlepas dari berbagai kasus penggunaan yang dapat Anda pikirkan, saya juga suka memikirkan beberapa kasus penggunaan umum yang sangat ketat. Untuk melakukan ini, saya memiliki pilihan (atau tugas) dari perjalanan off-road yang benar-benar tak berawak, melewati beberapa terowongan dengan lalu lintas di karavan. Ada beberapa gangguan dengan use case ini seperti akumulasi kesalahan odometri, kesalahan floating point, koreksi lokalisasi, dan pemadaman.
Persyaratan
Tujuan pengembangan use case, selain untuk menggeneralisasi masalah yang Anda coba selesaikan, adalah untuk menetapkan persyaratan. Agar use case terjadi (atau dipuaskan), mungkin ada beberapa faktor yang harus direalisasikan atau mungkin. Dengan kata lain, setiap use case memiliki serangkaian persyaratan khusus.
Pada akhirnya, persyaratan umum untuk sistem lokalisasi tidak terlalu menakutkan:
- Berikan transformasi untuk algoritma lokal
- Berikan transformasi untuk algoritma global
- Berikan mekanisme untuk inisialisasi algoritma pelokalan relatif
- Pastikan konversi tidak tumpah
- Pastikan kepatuhan REP105
Spesialis keselamatan fungsional yang berkualifikasi cenderung merumuskan lebih banyak persyaratan. Nilai dari karya ini terletak pada kenyataan bahwa kami dengan jelas merumuskan persyaratan tertentu (atau batasan) untuk desain kami, yang, seperti mekanisme, akan memenuhi persyaratan kami untuk pengoperasian algoritma.
Mekanisme
Hasil akhir dari segala jenis analisis harus berupa serangkaian pelajaran atau materi yang praktis. Jika sebagai akibat dari analisis kita tidak dapat menggunakan hasilnya (bahkan yang negatif!), Maka analisis itu sia-sia.
Dalam kasus dokumen teknik tingkat tinggi, kita berbicara tentang seperangkat mekanisme atau konstruksi yang merangkum mekanisme ini, yang cukup sesuai dengan kasus penggunaan kami.
Desain lokalisasi tingkat tinggi khusus ini memungkinkan untuk set komponen perangkat lunak, antarmuka, dan perilaku yang membentuk arsitektur sistem lokalisasi. Diagram blok sederhana dari arsitektur yang diusulkan ditunjukkan di bawah ini.
Jika Anda tertarik pada informasi lebih lanjut tentang arsitektur atau desain, saya sangat menyarankan Anda membacateks lengkap dokumen .
Analisis kesalahan
Karena kita sedang membangun komponen pada sistem yang kritis terhadap keamanan, kegagalan adalah sesuatu yang harus kita coba hindari, atau paling tidak mitigasi. Karena itu, sebelum kita mencoba mendesain atau membangun apa pun, kita setidaknya harus menyadari bagaimana hal-hal bisa pecah.
Saat menganalisis kesalahan, seperti dalam kebanyakan kasus, akan bermanfaat untuk melihat komponen dari berbagai sudut. Untuk menganalisis kegagalan algoritme NDT, kami mempertimbangkannya dalam dua cara berbeda: sebagai mekanisme lokalisasi (relatif) umum, dan secara khusus sebagai turunan dari algoritma NDT.
Jika dilihat dari sudut pandang mekanisme lokalisasi, mode kegagalan utama dirumuskan sebagai berikut - "apa yang harus dilakukan jika inputnya adalah data yang salah?" Memang, dari sudut pandang komponen individu, sedikit yang bisa dilakukan kecuali melakukan pemeriksaan dasar pada kecukupan sistem. Pada level sistem, Anda memiliki opsi tambahan (misalnya, mengaktifkan fitur keamanan).
Mempertimbangkan NDT sebagai suatu algoritma dalam isolasi, ini berguna untuk abstrak dari algoritma dengan menyoroti sejumlah aspek yang sesuai. Akan sangat membantu untuk memperhatikan versi algoritma pseudocode (ini akan membantu Anda, pengembang, memahami algoritma dengan lebih baik). Dalam hal ini, kami menganalisis algoritme secara terperinci dan mempelajari semua situasi yang dapat merusaknya.
Kesalahan implementasi adalah kegagalan yang sangat masuk akal, meskipun dapat diperbaiki dengan pengujian yang sesuai. Beberapa nuansa tentang algoritma numerik mulai muncul sedikit lebih sering dan lebih berbahaya. Secara khusus, kita berbicara tentang menemukan matriks terbalik atau, lebih umum, memecahkan sistem persamaan linear, yang dapat menyebabkan kesalahan numerik. Ini adalah skenario kegagalan yang sangat sensitif dan harus ditangani.
Dua kegagalan penting lainnya yang kami identifikasi adalah memverifikasi bahwa ekspresi tertentu tidak memiliki magnitudo tak terbatas (kontrol presisi titik mengambang), dan memverifikasi bahwa besarnya atau ukuran input terus-menerus dipantau.
Secara total, kami telah mengembangkan 15 rekomendasi... Saya akan merekomendasikan agar Anda membiasakan diri dengan mereka.
Saya juga akan menambahkan bahwa meskipun kami tidak menggunakan metode ini, analisis pohon kesalahan adalah alat yang sangat baik untuk menyusun dan menghitung masalah analisis kegagalan.
Definisi metrik
"Apa yang diukur dapat dikelola"Sayangnya, dalam pengembangan profesional, tidak cukup untuk mengangkat bahu dan mengatakan "selesai" ketika Anda lelah mengerjakan sesuatu. Pada dasarnya, setiap paket kerja (yang lagi-lagi merupakan pengembangan NDT) memerlukan kriteria penerimaan, yang harus disetujui oleh pelanggan dan pemasok (jika Anda adalah pelanggan dan penjual, lewati langkah ini). Semua yurisprudensi ada untuk mendukung aspek-aspek ini, tetapi sebagai insinyur, kami dapat memotong perantara dengan membuat metrik untuk menentukan ketersediaan komponen kami. Bagaimanapun, jumlahnya (sebagian besar) tidak ambigu dan tak terbantahkan.
- Ungkapan populer manajer
Sekalipun kriteria penerimaan tidak perlu atau tidak relevan, tetap menyenangkan memiliki serangkaian metrik yang terdefinisi dengan baik yang mengkarakterisasi dan meningkatkan kualitas dan kinerja proyek. Pada akhirnya, apa yang diukur dapat dikontrol.
Untuk implementasi NDT kami, kami membagi metrik menjadi empat grup besar:
- Metrik kualitas perangkat lunak umum
- Metrik Kualitas Firmware Umum
- Metrik umum dari algoritma
- Metrik khusus lokalisasi
Saya tidak akan membahas detail karena semua metrik ini relatif standar. Yang penting adalah bahwa metrik telah didefinisikan dan diidentifikasi untuk masalah khusus kami, yang kira-kira dapat kita capai sebagai pengembang proyek sumber terbuka. Pada akhirnya, bar untuk penerimaan harus ditentukan berdasarkan spesifik proyek oleh mereka yang menggunakan sistem.
Hal terakhir yang akan saya ulangi di sini adalah bahwa meskipun metrik fantastis untuk diuji, mereka bukan pengganti untuk memeriksa pemahaman implementasi dan persyaratan penggunaan.
Arsitektur dan API
Setelah dengan susah payah mendefinisikan masalah yang kami coba pecahkan dan membangun pemahaman tentang ruang solusi, kami akhirnya bisa menyelam ke area yang berbatasan dengan implementasi.
Saya adalah penggemar pengembangan yang digerakkan oleh tes akhir-akhir ini . Seperti kebanyakan insinyur, saya suka proses pengembangannya, dan gagasan untuk menulis tes tampaknya tidak praktis bagi saya. Ketika saya mulai pemrograman secara profesional, saya langsung maju dan melakukan pengujian setelah pengembangan (meskipun profesor universitas saya mengatakan kepada saya untuk melakukan yang sebaliknya). Penelitianmenunjukkan bahwa tes menulis sebelum implementasi cenderung menghasilkan bug lebih sedikit, cakupan tes lebih tinggi, dan kode umumnya lebih baik. Mungkin yang lebih penting, saya percaya bahwa pengembangan berbasis tes membantu mengatasi masalah besar implementasi algoritma.
Seperti apa bentuknya?
Alih-alih mengirimkan tiket monolitik yang disebut "Implementasikan NDT" (termasuk tes), yang akan menghasilkan beberapa ribu baris kode (yang tidak dapat dilihat dan dipelajari secara efektif), Anda dapat memecah masalah menjadi fragmen yang lebih bermakna:
- Tulis kelas dan metode publik untuk algoritme (buat arsitektur)
- Tulis tes untuk algoritma menggunakan API publik (harus gagal!).
- Menerapkan logika algoritma
Jadi langkah pertama adalah menulis arsitektur dan API untuk algoritme. Saya akan membahas langkah-langkah lain di pos lain.
Sementara ada banyak pekerjaan di luar sana yang berbicara tentang bagaimana "membuat arsitektur", bagi saya tampaknya merancang arsitektur perangkat lunak ada hubungannya dengan ilmu hitam. Secara pribadi, saya suka berpikir tentang arsitektur perangkat lunak sebagai menggambar batas antara konsep dan mencoba untuk mengkarakterisasi derajat kebebasan dalam mengajukan masalah dan bagaimana menyelesaikannya dalam hal konsep.
Lalu, apa derajat kebebasan di NDT?
Sebuah tinjauan literatur memberitahu kita bahwa ada berbagai cara penyajian scan dan pengamatan (misalnya P2D-NDT dan D2D-NDT). Demikian juga, makalah teknik tingkat tinggi kami mengatakan bahwa kami memiliki beberapa cara untuk mewakili peta (statis dan dinamis), jadi ini juga merupakan derajat kebebasan. Literatur yang lebih baru juga menunjukkan bahwa masalah optimisasi dapat ditinjau kembali. Namun, membandingkan implementasi praktis dan literatur, kami melihat bahwa bahkan detail dari solusi optimasi mungkin berbeda.
Dan daftarnya terus bertambah.
Berdasarkan hasil desain awal, kami menetapkan konsep-konsep berikut:
- Masalah optimasi
- Solusi optimasi
- Tampilan pindai
- Tampilan peta
- Sistem pembuatan hipotesis awal
- Algoritma dan antarmuka simpul
Dengan beberapa pembagian di dalam item ini.
Harapan utama dari sebuah arsitektur adalah bahwa arsitektur itu harus diperluas dan dipelihara. Apakah arsitektur yang kami usulkan memenuhi harapan ini, hanya waktu yang akan menjawab.
Lebih lanjut
Setelah desain, tentu saja, saatnya untuk implementasi. Pekerjaan resmi tentang implementasi NDT di Autoware.Auto dilakukan di hackathon Autoware yang diselenggarakan oleh Parkopedia .
Harus ditegaskan kembali bahwa apa yang telah disajikan dalam teks ini hanyalah tahap pertama yang melewati tahap desain. Diketahuibahwa tidak ada rencana pertempuran untuk menghadapi musuh, dan hal yang sama dapat dikatakan untuk desain perangkat lunak. Kegagalan akhir dari model air terjun dilakukan dengan asumsi bahwa spesifikasi dan desainnya sempurna. Tidak perlu dikatakan, baik spesifikasi maupun desainnya tidak sempurna, dan seiring implementasi dan pengujian berlangsung, kelemahan akan ditemukan dan perubahan harus dilakukan pada desain dan dokumen yang diuraikan di sini.
Dan itu tidak masalah. Kita, sebagai insinyur, bukan pekerjaan kita atau mengidentifikasi dengan itu, dan semua yang bisa kita coba lakukan adalah beralih dan berjuang untuk sistem yang sempurna. Setelah semua yang telah dikatakan tentang pengembangan NDT, saya pikir kami telah membuat langkah pertama yang baik.
Berlangganan saluran:
@TeslaHackers — Tesla-, Tesla
@AutomotiveRu — ,
: