Memastikan perilaku pengaturan waktu perangkat lunak dalam sistem tertanam berbasis multicore yang penting
Mendapatkan suatu tempat dengan aman bergantung pada lebih dari sekadar rem yang baik, lampu belakang yang berfungsi, dan seseorang dengan refleks yang sangat baik di belakang kemudi. Semakin, komponen yang menjaga mobil Anda di jalan dan pesawat Anda di udara tidak hanya manusia, atau bahkan hanya mekanik. Mereka adalah bagian canggih dari perangkat lunak tertanam yang berjalan pada prosesor multicore heterogen yang kompleks, mengendalikan segalanya mulai dari sistem manajemen penerbangan hingga power steering, dan mengeksekusi hingga tenggat waktu yang ketat yang diukur dalam mikrodetik.
Di sinilah letak tantangannya. Perilaku pengaturan waktu perangkat lunak dalam sistem multicore tidak hanya dipengaruhi oleh perangkat lunak yang berjalan di dalamnya dan inputnya, tetapi juga oleh perangkat lunak lain yang berjalan pada inti lain.
Sistem tertanam yang kritis memerlukan upaya dan investasi yang sangat besar (jutaan euro/dolar dan upaya rekayasa bertahun-tahun) untuk dikembangkan. Keselamatan harus menjadi inti dari arsitektur dan desain, sejak tahap paling awal dari proses pengembangan perangkat lunak. Secara khusus, perancang sistem harus memahami perilaku pengaturan waktu perangkat lunak mereka, untuk memastikannya dapat dijalankan dalam kerangka waktu yang aman.
Meskipun kapasitas komputasi yang luar biasa dari prosesor multicore seharusnya (secara teori) membuat sistem tertanam lebih kuat dan efisien, perangkat lunak yang dijalankan pada satu inti dapat memperlambat eksekusi perangkat lunak yang berjalan pada inti lainnya. Dalam situasi ini, perangkat lunak dapat membutuhkan waktu lebih lama untuk dieksekusi karena gangguan yang disebabkan oleh perebutan sumber daya bersama seperti bus, memori, cache, perangkat, FPGA, dan GPU yang dibagikan dengan tugas yang berjalan di inti lain.
Bagaimana Anda mengukur efek dari gangguan ini? Bagaimana Anda menganalisis, menguji, dan memberikan bukti nyata bahwa perangkat lunak yang sangat penting bagi keselamatan Anda, saat dijalankan pada platform multiinti, selalu dapat dijalankan dalam tenggat waktunya?
Para ahli di Barcelona Supercomputing Center (BSC), Rapit Systems Ltd (RPT), Raytheon Technologies (RTRC), dan Marelli Europe (MAR) telah menyelidiki jawaban atas pertanyaan-pertanyaan ini selama bertahun-tahun. BSC dan Rapita telah mengembangkan solusi yang akan segera diluncurkan di industri kedirgantaraan dan otomotif. Perkakas dan otomatisasi khusus, dikombinasikan dengan metodologi berbasis persyaratan dan berfokus pada keselamatan adalah kunci untuk memecahkan teka-teki.
Pekerjaan ini telah menjadi dasar proyek MASTACS, proyek penelitian dan pengembangan multi-disiplin yang didanai oleh Komisi Eropa dan diluncurkan pada Desember 2019. Proyek MASTACS akan mematangkan teknologi dan mendukung penggunaannya untuk sertifikasi sistem avionik dan otomotif. Bagian penting dari proyek MASTECS adalah memberikan demonstrasi pendekatan di dua industri melalui studi kasus yang diterapkan oleh RTRC dan MAR.
Alat canggih
Alat yang tersedia secara komersial untuk mendukung analisis pewaktuan efektif untuk elektronik sederhana (inti tunggal), tetapi tidak berskala untuk memenuhi persyaratan dan rekomendasi sertifikasi khusus multi inti baru.
Solusi analisis pengaturan waktu statis [1] menghadapi dinding kompleksitas dan tidak dapat secara efektif memodelkan perangkat keras yang semakin kompleks atau secara efisien menangani karakteristik struktural dan sintaksis dari fungsionalitas perangkat lunak yang sangat kompleks.
Solusi berbasis pengukuran telah mencapai tingkat penetrasi yang baik di pasar analisis inti tunggal (perangkat RVS Sistem Rapita termasuk yang paling sukses). Namun, alat tersebut masih belum dapat sepenuhnya menopang tantangan yang dibawa oleh pengenalan multicore. Mereka biasanya berfokus pada skenario pengukuran sebagaimana ditentukan oleh strategi pengujian fungsional terkonsolidasi, tetapi tidak memiliki metodologi berbasis keahlian perangkat keras yang membantu mendapatkan batas waktu yang dapat dipercaya untuk tugas yang berjalan dalam multicore dengan bukti pendukung yang diperlukan dan tingkat keterlacakan yang memadai.
Sepengetahuan kami, tidak ada alat komersial yang tersedia di pasar, selain yang dikembangkan di MASTERCS, yang mampu menganalisis pengaturan waktu perangkat lunak pada platform multicore, dengan fokus kuat pada standar keselamatan yang berlaku dan persyaratan sertifikasi yang muncul.
Analisis dan kontrol interferensi beraksi
Kunci untuk memahami interferensi adalah metodologi pengujian terstruktur, menggunakan pakar perangkat keras dan perangkat lunak untuk menghasilkan bukti tentang perilaku pengaturan waktu multicore. Teknologi khusus dari BSC (dikenal sebagai teknologi micro-benchmark multicore atau MμBT, dikomersialkan oleh Rapita sebagai RapiDaemons) memungkinkan perancang sistem menganalisis dan mengukur efek interferensi dalam aplikasi berbasis multicore dengan membuat skenario interferensi tambahan untuk menguji stres bagian yang berbeda dari prosesor multicore.
Tolok ukur mikro, di jantung MuBT, adalah potongan kode yang dibuat dengan baik yang beroperasi pada antarmuka terendah antara perangkat keras dan perangkat lunak untuk menekankan sumber daya bersama yang spesifik. Tolok ukur mikro mengekspos dampak saluran interferensi pada pengaturan waktu perangkat lunak. Untuk melakukannya, tolok ukur mikro dapat digunakan untuk menyebabkan tekanan yang dapat dikonfigurasi dan diukur pada aplikasi tertentu. Micro-benchmark secara khusus dirancang untuk menunjukkan satu perilaku yang didefinisikan dengan jelas dengan efek yang diantisipasi pada sumber daya perangkat keras tertentu, sambil mencegah sebanyak mungkin untuk menghasilkan pertentangan pada saluran interferensi lainnya. Fitur utama benchmark mikro meliputi:
Mereka memberikan tekanan terukur pada sumber daya bersama yang spesifik.
Perilaku mereka dapat diverifikasi melalui pemantau acara.
Mereka menangkap persyaratan terkait waktu tertentu, misalnya, apakah tindakan mitigasi yang Anda lakukan untuk menguasai pertikaian itu efektif.
klik untuk gambar lebih besar Gambar 1:Penggunaan micro-benchmark dalam analisis interferensi. (Sumber:Penulis)
Berbagai macam tolok ukur mikro telah dikembangkan untuk memiliki peran khusus, termasuk mencocokkan tingkat gangguan yang diinginkan, memaksimalkan gangguan pada sumber daya, atau sekadar menjadi sangat sensitif terhadap pertengkaran ('korban').
Dalam menganalisis efek interferensi, penggunaan MμBT didukung dengan task contention model (TCM) yang memberikan perkiraan awal dari tugas delay contention yang dapat diderita. Otomasi perangkat lunak dan alat pengujian RapiTest dan RapiTime yang dikembangkan oleh Rapita digunakan untuk menulis pengujian dan menjalankannya pada target yang disematkan.
Metodologi desain
Dengan mengikuti proses desain uji tujuh langkah di sepanjang proses pengembangan perangkat lunak standar 'V' (Gambar 2), para insinyur dapat lebih memahami dampak interferensi.
Pengaturan konfigurasi kritis prosesor multicore, saluran interferensi, dan analisis monitor peristiwa. Pakar perangkat keras membantu mengidentifikasi pengaturan konfigurasi penting untuk mengatur kerangka kerja di mana saluran interferensi juga diidentifikasi bersama dengan langkah-langkah mitigasi. Identifikasi pemantau peristiwa perangkat keras juga penting untuk menyediakan sarana verifikasi untuk semua langkah berikut.
Identifikasi persyaratan waktu. Bantu pengguna akhir untuk mengidentifikasi kebutuhan spesifik mereka, persyaratan waktu, risiko, dan masalah keamanan untuk sistem. Misalnya, verifikasi kinerja pendekatan isolasi perangkat keras apa pun untuk meminimalkan gangguan.
Desain kasus uji. Kembangkan kasus uji khusus (deskripsi pengujian) untuk memverifikasi kumpulan hipotesis yang mendukung persyaratan pengguna, termasuk menentukan item MμBT yang akan diperlukan untuk memberikan bukti dalam analisis saluran interferensi. Ini melibatkan eksekusi secara terpisah (tanpa gangguan), eksekusi terhadap benchmark mikro untuk menilai waktu eksekusi aplikasi, dan sensitivitas perangkat keras terhadap interferensi di bawah skenario tekanan terukur yang berbeda.
Implementasi prosedur pengujian. Saat ini, proses manual akan diotomatisasi di MASTACS, langkah ini membangun prosedur pengujian yang terdiri dari kerangka pengujian, tolok ukur mikro, dan probe pengukuran untuk merekam/menelusuri hasil.
Pengumpulan bukti (pengujian). Prosedur pengujian dijalankan pada platform untuk mengumpulkan bukti pengujian. Saat ini melibatkan beberapa pekerjaan manual, ini akan diotomatisasi di MASTACS menggunakan kerangka kerja otomatisasi RapiTest untuk menjalankan pengujian tersebut dan menautkannya kembali ke persyaratan verifikasi.
Analisis Hasil. Peninjauan hasil pengujian oleh pakar teknis untuk memeriksa bagaimana hasil pengujian memverifikasi (atau sebaliknya) persyaratan verifikasi. Misalnya, Gambar 3 menunjukkan tangkapan layar RapiTime pada waktu eksekusi yang dilaporkan untuk berbagai fungsi program.
Validasi hasil dan buat dokumentasi. Tinjauan akhir persyaratan, pembuatan dokumentasi dan hasil kualifikasi untuk mendukung argumen keamanan sistem. Pelanggan dapat menggunakan set lengkap laporan dan artefak analisis secara langsung untuk sertifikasi perangkat lunak yang berjalan pada multicore.
klik untuk gambar lebih besar Gambar 2:Langkah-langkah MTA dalam proses pengembangan perangkat lunak model-V. (Sumber:Penulis)
Keahlian perangkat keras dan proses analisis waktu
Menyuntikkan keahlian perangkat keras (multicore) adalah ciri utama dalam pendekatan MTA yang diusulkan untuk keberhasilannya pada multicore kompleks modern. Selama tahap awal pengembangan perangkat lunak:
Pakar perangkat keras mengidentifikasi konfigurasi multiinti (pengaturan konfigurasi penting dalam jargon avionik) karena konfigurasi tersebut memainkan peran kunci dalam menentukan perilaku fungsional dan pengaturan waktu perangkat lunak, dan sebagian besar memengaruhi jumlah tugas pertikaian yang dihasilkan satu sama lain. Sebagai contoh ilustratif, prosesor saat ini menerapkan mekanisme isolasi dan pemisahan yang, jika diterapkan dengan benar, dapat sangat mengurangi perselisihan.
Pakar multicore memainkan peran kunci dalam mengidentifikasi sumber daya di mana pertentangan tugas dapat muncul (ini disebut sebagai saluran interferensi dalam avionik). Kemampuan pakar perangkat keras untuk menavigasi manual referensi teknis prosesor multi-ribu halaman dan merumuskan pertanyaan yang sesuai tentang potensi informasi yang hilang pada manual ke vendor chip sangat penting untuk mendorong proses MTA yang sesuai.
Setelah saluran interferensi diidentifikasi, pakar perangkat keras mengidentifikasi monitor peristiwa yang dapat digunakan untuk melacak aktivitas yang dihasilkan tugas pada saluran interferensi tersebut sebagai metrik proxy untuk mengikat anggapan bahwa tugas dapat diderita. Kebenaran dari pemantau peristiwa tersebut juga harus diverifikasi [2] yang untuknya telah dirancang serangkaian tolok ukur mikro khusus.
Akhirnya, pakar perangkat keras bekerja sama dengan pakar analisis waktu untuk memperoleh, dari persyaratan pengguna, persyaratan tingkat tinggi dan tingkat rendah, dan pengujian khusus untuk memvalidasi hipotesis yang mendukung persyaratan pengguna. Setiap pengujian membuat satu atau beberapa program benchmark mikro yang dirancang oleh pakar perangkat keras untuk menempatkan tingkat beban yang diinginkan pada saluran interferensi target (set).
Selama tahap desain akhir:
Pakar perangkat keras berkontribusi dengan analisis hasil pengujian untuk menilai apakah mereka mengonfirmasi atau menolak hipotesis.
Pakar perangkat keras juga berkontribusi dalam membangun hipotesis baru dan pengujian yang sesuai jika diperlukan berdasarkan hasil yang diperoleh pada langkah sebelumnya.
klik untuk gambar lebih besar Gambar 3:Menganalisis hasil (RapiTime). (Sumber:Penulis)
Gambaran yang lebih besar
Proses desain pengujian 7 langkah hanyalah satu bagian dari metodologi verifikasi multiinti yang lebih luas yang ditunjukkan sebelumnya pada Gambar 2. Metodologi ini, yang akan terus dikembangkan sebagai bagian dari proyek MASTACS, dirancang untuk mencapai ketertelusuran penuh, dari bukti komprehensif dan hasil kembali ke persyaratan dan desain yang sesuai. Metodologi ini dirancang untuk memenuhi tujuan yang ditentukan dalam CAST-32A, dokumen panduan utama yang dikeluarkan oleh otoritas sertifikasi kedirgantaraan. Ini juga secara khusus diselaraskan dengan ISO 26262, standar keselamatan untuk sektor otomotif, yang menganjurkan kebebasan dari gangguan.
CAST-32A diterbitkan oleh Tim Perangkat Lunak Otoritas Sertifikasi (CAST) pada tahun 2016, dan mengidentifikasi faktor-faktor yang memengaruhi keamanan, kinerja, dan integritas sistem perangkat lunak udara yang dijalankan pada prosesor multicore. Jika Anda ingin menggunakan perangkat keras multiinti dalam sistem avionik, ini adalah dokumen masuknya. Ini memberikan tujuan yang dimaksudkan untuk memandu produksi sistem avionik multiinti yang aman termasuk tujuan yang terkait dengan mengidentifikasi dan membatasi dampak saluran interferensi. Lihat kertas posisi CAST-32A di sini. EASA dan FAA sedang mengerjakan adaptasi CRI generik multicore menjadi bahan AMC/AC umum (AMC 20-193). Ini diharapkan akan diterbitkan “akhir tahun ini”[3].
Keahlian tidak dapat diotomatisasi
Efek interferensi sangat kompleks. Untuk mengungkap misteri mereka, Anda memerlukan ahli yang memahami baik komponen arsitektur multicore, dan sistem penjadwalan dan alokasi sumber daya dalam perangkat lunak. Kolaborasi antara ahli perangkat keras dan perangkat lunak akan menjadi fitur utama dari proyek MASTACS karena berlanjut ke masa depan. Namun, meskipun kolaborasi menghasilkan langkah besar dalam perangkat lunak dan otomatisasi, penting untuk diingat bahwa Anda tidak dapat mengotomatiskan setiap langkah proses validasi – terutama jika analisis pengaturan waktu multicore dilibatkan.
Anda membutuhkan insinyur berpengalaman yang mengetahui sistem secara detail. Misalnya, selama tahap awal, pakar multicore dapat mengidentifikasi konfigurasi prosesor (juga dikenal sebagai pengaturan konfigurasi kritis perangkat keras) yang menentukan perilaku fungsional dan pengaturan waktu perangkat lunak, serta saluran interferensi potensial. Saat menganalisis hasil pengujian, tidak ada yang mengalahkan masukan dari pakar manusia yang berpengalaman untuk meninjau kembali dan mengevaluasi asumsi awal yang dibuat tentang platform, dan menggunakan pengetahuan mereka untuk dimasukkan ke dalam siklus pengujian baru.
Referensi
[1] Reinhard Wilhelm. Perasaan Campur aduk tentang Kekritisan Campuran. Lokakarya Analisis Waktu Eksekusi Kasus Terburuk, 2018.
[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. Unit Pemantauan Kinerja Integritas Tinggi dalam Chip Otomotif untuk Pengaturan Waktu V&V yang Andal. IEEE Mikro 38(1):56-65 (2018).
