Her yazılım sürümü, derleme (build) tarihi, versiyon numarası ve değişiklik açıklamasıyla birlikte saklanmalıdır. Bu arşivleme, hem geliştirme takibi hem de saha desteği için zorunludur. Sürüm arşivleri; kaynak kod, derlenmiş binary (.hex / .bin / .elf), yapı betikleri (build scripts) ve konfigürasyon dosyalarını içermelidir. Arşivleme işlemi, Git, SVN veya Mercurial gibi sürüm kontrol sistemlerinde otomatik yapılmalıdır. Her build için sistem tarafından hash (commit ID) veya semantic version (ör. v1.2.3) oluşturulmalıdır. Gerektiğinde eski sürümler, ürün seri numarasıyla eşleştirilerek yeniden yüklenebilmelidir. Bu madde, Configuration Management (CM) sistemlerinin temel gereksinimidir (bkz. ISO 10007:2017).

Revizyon geçmişi, yazılımın evrimini izlenebilir hale getirir. Her değişiklik teknik olarak açıklanmalı ve sorumluluk sahibi geliştiriciyle ilişkilendirilmelidir. Revizyon kayıtlarında bulunması gereken bilgiler: Tarih (Değişikliğin yapıldığı gün), Geliştirici (Sorumlu kişi veya ekip), Açıklama (Hangi modülün, neden değiştirildiği), Versiyon numarası (Değişiklik sonrası sürüm etiketi ör. 1.0.5 → 1.0.6). Her değişiklik "changelog.md" veya "release_notes.txt" dosyasında toplanmalıdır. Geliştiriciler commit mesajlarında iş emri (ticket ID) veya hata kodu (bug ID) referansları kullanmalıdır. Saha yazılımları (field firmware) için sürüm geçmişi müşteriye görünür olmalıdır. Bu madde, IEEE 828 – Configuration Management in Systems and Software Engineering standardındaki change tracking gerekliliğine karşılık gelir.

Yazılımın anlaşılabilirliği, yalnızca kod kalitesiyle değil, niyetin (design intent) açıkça belgelenmesiyle ölçülür. Tasarım notları, kritik fonksiyonların nasıl ve neden bu şekilde yazıldığını açıklar. Kodun içinde fonksiyon seviyesinde açıklamalar (docstring / comment block) bulunmalıdır. Geliştirilen algoritmaların açıklamaları ayrı bir "Software Design Note" dokümanında (ör. SW_Design_Notes_RevB.pdf) tutulmalıdır. Her modül için giriş/çıkış parametreleri, işlem süresi ve hata koşulları tanımlanmalıdır. Akış diyagramları (flow chart) veya state machine (FSM) diyagramları dokümana eklenmelidir. Kritik yazılım bölümleri (ör. ISR, RTOS task, DMA handler) detaylı yorumlarla açıklanmalıdır. Bu madde, DO-178C (Software Considerations in Airborne Systems) standardındaki Design Description Documentation prensibini karşılar.

Yazılım versiyonları yalnızca kod seviyesinde değil, veri yapılarında ve iletişim protokollerinde de izlenmelidir. Bu, firmware güncellemelerinde geriye dönük uyumluluğu (backward compatibility) korumak için zorunludur. Her veri paketi veya EEPROM/Flash yapısı bir structure version etiketi taşımalıdır (örn. struct_version = 0x02). Firmware yükseltmelerinde, eski veriler yeni formata otomatik dönüştürülmelidir. Protokol değişikliklerinde major/minor versiyonlama uygulanmalıdır (ör. v1.2 → v2.0). Bu bilgiler, "Software Interface Control Document (ICD)" içerisinde yer almalıdır. Bu madde, ISO/IEC/IEEE 12207 – Software Lifecycle Processes standardındaki configuration item traceability gerekliliğine karşılık gelir.

Kodlama stili, yazılım mimarisinin "ortak dili"dir. Ekipteki tüm geliştiricilerin aynı biçimde kod yazması, bakım süresini kısaltır ve hata oranını düşürür. Proje başlangıcında, kodlama stili yazılı biçimde tanımlanmalıdır. Örnek standartlar: MISRA-C (Motor Industry Software Reliability Association): Gömülü güvenlik sistemleri için, CERT-C: Güvenli C programlama ilkeleri, Google C++ Style Guide: Modüler ve modern kod yapısı için, Şirket içi kılavuzlar (örneğin "Company_C_Style_v2.1.pdf"). Kod gözden geçirme (code review) sırasında stil kontrolü otomatik araçlarla doğrulanmalıdır (örn. clang-format, uncrustify). Stil ihlalleri "warning" olarak değil, kalite eşiği olarak değerlendirilmelidir. Bu madde, ISO/IEC 5055 – Software Engineering: Software Quality Measurement standardının "Consistency & Maintainability" kriterini destekler.

Kodun okunabilirliği, isimlendirme konvansiyonlarının tutarlılığıyla doğrudan ilişkilidir. İsimlerin açık, anlamlı ve amaca uygun olması, hem hata oranını düşürür hem de yeni geliştiricilerin sürece adaptasyonunu kolaylaştırır. İsimlendirme kuralları proje kılavuzunda tanımlanmalıdır (ör. "Naming_Conventions.md"). Fonksiyonlar: eylem tabanlı ve anlamlı olmalıdır (örn. ReadTempSensor() veya InitUART()). Değişkenler: açık bağlam içermelidir (uint16_t batteryVoltage_mV; tercih edilir). Sabitler (define, enum): büyük harf ve alt çizgiyle (MAX_BUFFER_SIZE). Dosyalar: içeriği yansıtacak şekilde (temp_sensor.c, adc_driver.h). Karmaşık kısaltmalar (RTS1(), SMPX()) yalnızca teknik dokümantasyonda açıklanmışsa kullanılmalıdır. Bu madde, ISO/IEC 25010 – Software Product Quality Model'in "Understandability" alt kriterine karşılık gelir.

Statik analiz, kod çalıştırılmadan önce olası hataların, bellek taşmalarının ve güvenlik açıklarının tespit edilmesini sağlar. Bu süreç, testlerden önce "ilk savunma hattı"dır. Geliştirme sürecine statik analiz araçları entegre edilmelidir: LINT / PC-Lint (Gömülü C kodları için klasik analiz aracı), Cppcheck (C/C++ açık kaynak statik analiz), SonarQube (Kurumsal seviye analiz ve raporlama altyapısı), Clang Static Analyzer veya Coverity Scan alternatifleri. Analiz çıktıları kod gözden geçirme toplantılarında değerlendirilmelidir. "Severity" (önem derecesi) seviyeleri belirlenmeli: Critical / Major / Minor. Statik analiz raporları build pipeline'a dahil edilerek CI (Continuous Integration) sürecine entegre edilmelidir. Bu kontrol, ISO/IEC 27034 – Application Security ve MISRA-C:2012 Rule 2.x gereklilikleriyle uyumludur.

Koda estetik tutarlılık kazandırmak yalnızca görsel bir tercih değildir; okunabilirlik, hata tespiti ve ekip verimliliği açısından önemlidir. Kod formatlama kuralları otomatik araçlarla uygulanmalıdır (clang-format, astyle). Girintiler: 4 boşluk (space) veya sabit tab politikası belirlenmelidir. Yorumlar: Satır içi (//), Çok satırlı (/* ... */), Fonksiyon açıklamaları Doxygen formatında. Kodda açıklama oranı (%comment density) %20–25 arasında olmalıdır. Otomatik kontrol: pre-commit hook veya CI lint pipeline'ı. Bu madde, ISO/IEC 29110 – Software Engineering Lifecycle Profile for Small Enterprises'ın Coding and Documentation Standards gerekliliğini karşılar.

Döngülerin sonlanma koşulu olmaması, yazılım kilitlenmesine (hang) veya watchdog reset'lerine neden olur. Bu durum, gerçek zamanlı sistemlerde sistemin tümünü işlevsiz hale getirebilir. Her for, while, do-while döngüsü açık bir sonlanma koşulu içermelidir. Döngü koşulları dış etkenlere (ör. sensör sinyali, bayrak değişkeni) bağlıysa, zaman aşımı (timeout) mekanizması tanımlanmalıdır. Zaman aşımı sonrası sistemin davranışı belirlenmelidir (ör. "abort", "retry", "safe mode"). Watchdog reset yalnızca kritik hata sonrası kurtarma için kullanılmalı, normal akışın parçası olmamalıdır. Bu kontroller static analysis (MISRA Rule 14.2) ve unit test coverage aşamalarında doğrulanmalıdır. Bu madde, IEC 61508-3:2010 Clause 7.4.3 – Software Control Structures gerekliliğini karşılar.

Yazılım test kapsamının temel ölçütü, dallanma (branch) kapsama oranıdır. Tüm koşullar, hata yolları (error paths) ve istisna durumları (exception) test edilmelidir. Her if-else, switch-case, try-catch yapısı için hem pozitif hem negatif durum testleri yapılmalıdır. Coverage hedefi: Statement Coverage: ≥ %90, Branch Coverage: ≥ %80. Hata durumları (ör. null pointer, invalid data, I/O timeout) özel test senaryolarıyla doğrulanmalıdır. Test araçları: Ceedling (CUnit), GoogleTest, Unity Framework, gcov / lcov (coverage analizi). Bu madde, ISO/IEC/IEEE 29119-4 – Software Testing Techniques ve DO-178C Table A-7 kriterlerine uygun test kapsamını tanımlar.

Gerçek zamanlı sistemlerde zamanlama hataları, doğrudan ürünün kararlılığını etkiler. Zamanlayıcı ve gecikme fonksiyonlarının doğruluğu, mikrodenetleyici clock frekansı ve interrupt latency koşullarına bağlı olarak test edilmelidir. Her zamanlayıcı fonksiyonu (delay_ms, timeout, scheduler tick) referans zaman kaynağıyla (ör. osiloskop, logic analyzer) doğrulanmalıdır. Tolerans hedefi: ±%1 doğruluk (ör. 1 s gecikme → 0.99–1.01 s). Gerçek zamanlı işletim sistemlerinde (RTOS) görev zamanlaması (task scheduling) jitter ölçümleri yapılmalıdır. Timer ISR (interrupt service routine) içindeki iş yükü analiz edilmelidir; ISR süresi görev önceliğini etkilememelidir. Bu madde, ISO/IEC/IEEE 24765 – Real-Time Systems Vocabulary ve AUTOSAR Timing Extensions ilkeleriyle uyumludur.

Buffer taşmaları, gömülü sistemlerde en yaygın ve en tehlikeli hata türlerinden biridir. Taşmalar, veri bozulmasına, sistem çökmesine veya güvenlik açıklarına yol açabilir. Her FIFO veya buffer yapısında yazma (write) ve okuma (read) sınır kontrolleri yapılmalıdır. Dizi veya bellek erişimleri, dizin sınırları (array bounds) kontrol edilerek güvence altına alınmalıdır. Ring buffer yapıları için modüler sınır kontrolü ((index + 1) % size) uygulanmalıdır. Geliştirme sürecinde statik analiz (LINT, cppcheck) ve AddressSanitizer / Valgrind testleri yapılmalıdır. Hata durumlarında buffer temizlenmeli veya overflow bayrağı ayarlanmalıdır. Bu madde, CERT-C Rule ARR30-C: Do Not Form or Use Out-of-Bounds Pointers ve MISRA-C 18.1 kurallarıyla doğrudan ilişkilidir.

PWM, ADC, DAC, I²C, SPI gibi çevresel birimlerle ilişkili sürücü kodları, sistem kararlılığının çekirdeğini oluşturur. Bu nedenle bu sürücülerin hem fonksiyonel hem de zamanlama doğruluğu test edilmelidir. Her çevre birimi için sürücü testleri hazırlanmalıdır: PWM (Duty cycle doğruluğu, frekans kararlılığı), ADC (Örnekleme frekansı, çözünürlük ve ortalama hatası), DAC (Çıkış kararlılığı, sıfır nokta offset), I²C/SPI (Haberleşme senkronizasyonu, timeout yönetimi). Sürücü fonksiyonları hem izole testte (module test) hem de sistem testinde (integration test) doğrulanmalıdır. Test sonuçları "Driver Verification Report" dokümanına eklenmelidir. Bu madde, IEC 60730 – Automatic Electrical Controls for Household and Similar Use (Software Testing) standardına uygun doğrulama gerekliliklerini karşılar.

Enerji kesintisi veya beklenmedik güç kapanmaları sırasında sistem davranışı önceden tanımlanmazsa, veri kaybı veya donanım hasarı meydana gelebilir. Bu nedenle her ürün, kontrollü bir güç açılış ve kapanış algoritmasına sahip olmalıdır. Power-up aşamasında: Besleme hatlarının sıralaması (power sequencing) yazılım tarafından izlenmelidir, Başlatma (initialization) adımları belirli bir sırayla çalışmalıdır (ör. sensör → haberleşme → uygulama), EEPROM/Flash erişimi sırasında yazma işlemi varsa, enerji stabilizasyonu beklenmelidir. Power-down aşamasında: Geçici veriler (config, log, sayaçlar) güvenli biçimde NVM'ye kaydedilmelidir, Yazma işlemleri kesilmeden önce enerji mevcudiyeti doğrulanmalıdır (ör. power-fail detect pin), Kritik işlemler "atomic" şekilde (kesilemez işlem bloğu) tamamlanmalıdır. Bu madde, IEC 60730-1 Annex H – Software Power Cycle Integrity gerekliliklerini karşılar.

Farklı reset türlerinin doğru yönetilmemesi, sistemin başlangıç koşullarında kararsızlığa yol açabilir. Bu nedenle sıcak ve soğuk reset senaryoları yazılım tarafından açıkça ayırt edilmelidir. Cold Reset: Tüm bellek alanları sıfırlanır (stack, heap, global değişkenler), Donanım çevre birimleri yeniden başlatılır, Sistem "factory default" konfigürasyonla başlar. Warm Reset: RAM içeriği (ör. sayaç, mod durumu) korunur, EEPROM/Flash yeniden başlatılmaz, Kullanıcı işlemi yarıda kalmadan devam eder. Reset nedeni, donanımdan veya yazılımdan "reset cause register" (ör. RCC_CSR, MCUSR) üzerinden okunmalıdır. Bu madde, ISO 26262-6 Clause 9 – Software Initialization ve IEC 61508-3 Clause 7.4.4 gerekliliklerini karşılar.

Kullanılmayan kesmeler (interrupts), doğru ele alınmazsa bellek taşması veya tanımsız davranışlara neden olabilir. Tüm boş kesme vektörleri tek bir güvenli "trap" fonksiyonuna yönlendirilmelidir. Bu fonksiyon sistemin beklenmedik durumlarda kontrollü şekilde resetlenmesini sağlar. Boş vektörlerin ISR tablosunda adresleri doğrulanmalıdır (ör. linker map file kontrolüyle). Bu madde, ISO/IEC/IEEE 12207 – Software Lifecycle Processes (Maintenance and Fault Handling) standardına uygundur.

Programın yanlış adrese dallanması (jump to invalid address) durumunda sistemin rastgele komutlar yürütmesini engellemek gerekir. Boş ROM alanları NOP (No Operation) veya Reset vektörü (0xFFFF / JMP 0x0000) ile doldurulmalıdır. Bu, bellek bozulması veya pointer taşması durumlarında güvenli sistem kapanışı sağlar. Linker betiğinde (linker script / .ld file) "fill" direktifleriyle tanımlanabilir: FILL 0xFFFF. Firmware güvenlik taraması (binwalk, hexcmp) ile bu alanlar doğrulanmalıdır. Bu madde, DO-178C – Software Considerations in Airborne Systems standardındaki software integrity level (SIL 3–4) güvenlik kriterlerine uygundur.

EEPROM veya Flash belleklerde yazma işlemleri, özellikle güç kesintisi sırasında yarım kalabilir. Bu durum, bozuk konfigürasyon verileri veya sistem açılış hatalarına neden olabilir. Her kayıt alanı için CRC16 veya CRC32 doğrulama kodu kullanılmalıdır. Yazma işlemi sırasında "shadow copy" veya "double-buffer" yöntemi uygulanmalıdır. Flash yazma işlemi tamamlandığında verify readback yapılmalıdır. Güç kesintisi sırasında yazma tespit edilirse (ör. brown-out detection), sistem açılışta güvenli modda başlatılmalıdır. EEPROM ömür sınırı (ör. 100.000 cycle) için yazma sayaçları tutulmalıdır. Bu madde, IEC 60730-1 Annex H.11 – EEPROM Data Integrity ve ISO 26262 Part 6 gerekliliklerine uygundur.

Yazılımda beklenmeyen dallanmalar, sonsuz döngüler veya pointer hataları sistemin öngörülmeyen davranışlara girmesine yol açabilir. Bu nedenle her sistemde "self-recovery" mekanizması tanımlanmalıdır. Watchdog timer: Sistem kilitlenmelerinde otomatik reset sağlar. Stack overflow guard: Stack limit kontrolü yapılmalıdır (ör. stack canary, MPU). Memory Protection Unit (MPU): Kod ve veri alanlarının erişim sınırları tanımlanmalıdır. Exception handler: Tanımsız durumlarda hata log'u oluşturmalı (ör. HardFault_Handler()). Recovery logic: Reset sonrası sistem "safe state" moduna geçmelidir. Bu madde, IEC 61508-3 Clause 7.4.7 – Defensive Programming ve AUTOSAR Safety Platform ilkeleriyle doğrudan uyumludur.

UART, I²C, SPI, CAN, Ethernet veya BLE gibi haberleşme protokollerinde, yanıt alınamayan durumlarda sistemin bekleme süresi sınırsız olmamalıdır. Timeout kontrolü, sonsuz döngü (infinite loop) veya CPU kilitlenmesi riskini ortadan kaldırır. Her haberleşme çağrısı (read(), write(), transfer()) bir maksimum bekleme süresi (timeout) ile sınırlandırılmalıdır. Timeout süresi, haberleşme hızına ve ortam koşullarına göre belirlenmelidir: UART (100–500 ms), I²C (10–100 ms), SPI (1–10 ms), Ethernet (1–3 s). Timeout durumunda sistem "retry" veya "fail-safe" moduna geçmelidir. Gerçek zamanlı sistemlerde, bekleme süresi RTOS task yapılarına uygun olarak osDelay() veya EventFlag mekanizmalarıyla uygulanmalıdır. Bu madde, IEC 61508-2 Clause 7.4.9 – Communication Error Detection gerekliliğini karşılar.

Haberleşme katmanında oluşan hatalar yalnızca geçici durumlar değildir; genellikle donanım parazitleri, hatalı yapılandırma veya EMI kaynaklı sistemsel sorunların göstergesidir. Bu nedenle her hata türü kayıt altına alınmalı ve gerektiğinde sistem davranışı değiştirilmelidir. Tespit edilmesi gereken hata türleri: CRC / Checksum hatası, Framing / Parity hatası (UART), ACK/NACK (I²C), Collision (Ethernet, CAN), Timeout / Buffer overflow. Hatalar, ring buffer yapısında bir log alanına veya flash tabanlı hata günlüğüne kaydedilmelidir. Her hata, sayısal bir kodla (ERR_COMM_TIMEOUT = 0x02) ve zaman damgasıyla saklanmalıdır. Hata sayısı eşik değeri aşıldığında sistem uyarı veya güvenli moda geçmelidir. Bu madde, ISO 26262-6 Clause 9.4 – Fault Tolerance and Monitoring standardına uygundur.

Yüksek CPU kullanım oranı, gerçek zamanlı görevlerin gecikmesine veya sistemin öngörülmeyen davranışlara girmesine neden olabilir. Bu nedenle, CPU yükü düzenli olarak ölçülmeli ve sınır değerlerin altında tutulmalıdır. Hedef aralık: Ortalama CPU yükü %70'in altında, maksimum %80'in altında. Ölçüm yöntemleri: RTOS tabanlı sistemlerde "Idle Task Hook" fonksiyonu, Donanım sayaçları (SysTick, DWT_CYCCNT), Profiling araçları (FreeRTOS Tracealyzer, SEGGER SystemView, STM32CubeMonitor). Yük analiz sonuçları üretim öncesi "CPU Profiling Report" dokümanına eklenmelidir. Yüksek CPU kullanımı tespit edilirse, görev öncelikleri veya zaman dilimleri yeniden düzenlenmelidir. Bu madde, ISO/IEC 25010 – Performance Efficiency kriterini destekler.

Gerçek zamanlı sistemlerde kesme (interrupt) gecikmesi, kritik olayların kaçırılmasına neden olabilir. Bu nedenle, ISR latency (kesme gecikmesi) periyodik olarak ölçülmeli ve sistem gereksinimleriyle karşılaştırılmalıdır. ISR latency = Kesme oluşma anı ile ISR başlama anı arasındaki süre. Ölçüm yöntemleri: Logic analyzer veya osiloskop kullanılarak "trigger → ISR giriş pini" gecikmesi, RTOS sistemlerinde "trace hook" veya DWT_CYCCNT ölçümü. Kabul edilebilir aralık: Yüksek hızlı kontrol sistemleri (10 µs'den kısa), Genel gömülü uygulamalar (100 µs'den kısa). ISR latency artışı, yüksek öncelikli görevlerin aşırı CPU tüketiminden kaynaklanabilir. Bu madde, DO-178C Table A-7 ve ISO 26262 Part 6 Clause 9.4.3 gerekliliklerini destekler.

Kesme servis rutinlerinin (ISR) gereğinden uzun sürmesi, sistemde diğer görevlerin bloklanmasına yol açar. Bu durum "priority inversion" veya "missed event" hatalarına neden olabilir. ISR içinde yalnızca en kısa işlem yapılmalı, detaylı işlemler "deferred task" olarak ana döngüye aktarılmalıdır. ISR süresi, işlemci saat döngüsüne göre ölçülmelidir (örn. DWT_CYCCNT veya toggled GPIO). Kabul edilebilir ISR süresi: toplam sistem periyodunun %5'ini geçmemelidir. ISR süresi aşılırsa, işlev iki aşamaya bölünmelidir: ISR (fast): olay bayrağı kurar, Handler (slow): veriyi işler. ISR profili, "Timing Verification Report" altında dokümante edilmelidir. Bu madde, IEC 61508-3 Clause 7.4.11 – Execution Time Limitation gerekliliğini karşılar.

Yazılım güncellemeleri sırasında eski veri biçimleriyle (legacy format) uyumsuzluk oluşabilir. Bu nedenle her veri yapısı, versiyon numarası (struct version field) içermelidir.

Örnek yapı:

typedef struct { uint8_t version; uint16_t crc; float calib_value; } system_config_t; 

Versiyon değiştiğinde, yazılım otomatik dönüştürme (migration) veya sıfırlama yapmalıdır. Bu, EEPROM/Flash içeriği değişikliklerinde sistemin çökmesini önler. Versiyon kontrolü loglara ve konfigürasyon raporlarına eklenmelidir. Bu madde, IEC 62304 – Medical Device Software Lifecycle standardındaki "Data Compatibility & Upgrade Integrity" gerekliliğiyle doğrudan uyumludur.

Bellek taşmaları (overflow) gömülü yazılımlarda en sık karşılaşılan ve en zor tespit edilen hatalardır. Bu hatalar, sistemin rastgele resetlenmesine, veri bozulmasına veya belirsiz davranışlara neden olabilir. FIFO ve buffer yapıları için boyut sınırları (BUFFER_SIZE) derleme zamanı sabitleriyle tanımlanmalıdır. Stack izleme: RTOS tabanlı sistemlerde her görev için ayrı stack alanı belirlenmeli ve stack guard etkinleştirilmelidir, Stack taşması durumunda sistem watchdog reset veya fault handler'a yönlenmelidir. Heap izleme: Dinamik bellek (malloc, free) kullanımı minimumda tutulmalıdır, Bellek ayırma başarısızlıkları kontrol edilmeli (if (ptr == NULL)), uygun hata mesajı verilmelidir, Heap fragmentasyonu düzenli olarak profil edilmelidir. Stack/Heap sınırları derleme sonrası analiz aracıyla izlenmelidir: ARM Keil uVision Map Report, GCC map file, FreeRTOS Tracealyzer. Bu madde, ISO 26262-6 Clause 7.4.11 ve CERT-C MEM35-C: Allocate and Free Memory Safely ilkeleriyle uyumludur.

Derleyici optimizasyonları, yanlış değişken tanımları nedeniyle bazen beklenmedik sonuçlara yol açabilir. Özellikle donanım erişimleri ve kritik veri paylaşım alanlarında volatile ve const kullanımının doğru yapılması, kod bütünlüğü açısından zorunludur. volatile: ISR (interrupt service routine) veya donanım register'ları tarafından değiştirilen değişkenler için kullanılmalıdır (Örnek: volatile uint8_t uart_rx_flag;), Bu, derleyicinin değişkeni optimize etmesini (ör. cache'ten okumayı) engeller. const: ROM'da sabit kalacak tablolar, lookup verileri veya konfigürasyon sabitleri için kullanılmalıdır, Bellek koruması sağlar, RAM tüketimini azaltır. Yanlış kullanım, özellikle "volatile olmayan flag değişkeni" gibi durumlarda ISR ve main döngüsü arasında senkronizasyon hatalarına neden olabilir. Bu madde, MISRA-C 2012 Rules 8.7 ve 8.13 ile doğrudan ilişkilidir.

Mikrodenetleyiciler, bellek erişiminde hizalama (alignment) kuralına uymadığında bus fault veya hard fault oluşturabilir. Bu, özellikle stack pointer veya yapı (struct) hizalamalarında kritik öneme sahiptir. 16-bit sistemlerde veriler 2-byte hizalı, 32-bit sistemlerde 4-byte hizalı olmalıdır. C yapılarında hizalama için attribute((aligned(4))) veya #pragma pack(push, 4) kullanılabilir. Stack pointer'ın hizası başlangıçta kontrol edilmelidir: assert(((uint32_t)__get_MSP() % 8) == 0); Hizalanmamış erişimler, özellikle DMA veya çevre birimi (peripheral) erişimlerinde veri bozulmasına yol açabilir. Derleme sonrası "map" veya "elf dump" analiziyle hizalama doğrulanmalıdır. Bu madde, ARM Architecture Procedure Call Standard (AAPCS) ve ISO/IEC 9899:2011 (C11) §6.2.8 Alignment kurallarına uygundur.

Her derleme sonunda sistemin bellek kaynaklarının nasıl kullanıldığı gözden geçirilmelidir. Bu analiz, kod büyümesi, stack taşması veya RAM aşımı gibi riskleri erken fark etmeyi sağlar. Derleme sonrası oluşturulan .map, .elf, veya memory summary dosyaları düzenli olarak incelenmelidir. Takip edilmesi gereken metrikler: .text (kod bölgesi) boyutu → Flash kullanımı, .data + .bss (RAM bölgeleri) → Çalışma zamanı bellek, Stack ve heap toplamı → Toplam RAM kullanımı. Hedeflenen değerler: RAM kullanımı toplam belleğin %80'inden az, Flash kullanımı toplam alanın %90'ından az olmalıdır. Bu raporlar otomatik olarak CI/CD sisteminde arşivlenmeli ve sürümle ilişkilendirilmelidir. Bu madde, ISO/IEC 25010 – Resource Utilization ve MISRA C:2012 Rule 8.10 ilkelerine uygundur.

Statik analiz araçları, derleme aşamasına gelmeden önce hataları tespit ederek hem geliştirme süresini kısaltır hem de güvenilirliği artırır. Özellikle gömülü sistemlerde, derleyici uyarılarına ek olarak LINT, cppcheck, Splint gibi araçlar kullanılması önerilir. Tipik tespit edilen hatalar: Bellek sızıntısı, erişim ihlali, kullanılmayan değişkenler, olası taşmalar. Analiz, her derlemede otomatik olarak çalıştırılmalı ve sonuçlar CI/CD pipeline'ına dahil edilmelidir. Rapor formatı (örneğin XML, HTML) arşivlenmeli ve yazılım versiyonuyla ilişkilendirilmelidir. Hedef: Zero Critical Warnings Policy — kritik uyarıların %100 giderilmesi. Bu madde, MISRA-C:2012 Rule Compliance ve ISO 26262-6 Clause 11.4.8 – Static Verification gerekliliklerini karşılar.

Fonksiyonel testler, yazılımın sadece "doğru durumda" değil, tüm olası akışlarda doğru çalıştığını garanti altına alır. Bu kapsamda, testlerin branch coverage hedefini sağlaması gereklidir. Statement Coverage (Satır): ≥ %95, Branch Coverage (Dallanma): ≥ %90, MC/DC Coverage (Karar kombinasyonu): güvenlik-kritik sistemlerde ≥ %80. Test senaryoları, hata durumlarını (error paths) da içermelidir. Test araçları: Ceedling, Unity, GoogleTest, gcov/lcov, VectorCAST. Her yazılım sürümü için test kapsam raporu ("Coverage Report") oluşturulmalıdır. Bu madde, DO-178C Table A-7 ve ISO/IEC/IEEE 29119-4 – Test Techniques standardına uygundur.

Performans ölçümleri, sistemin gerçek zamanlı kısıtlar içinde çalıştığının kanıtıdır. Bu ölçümler, donanım kaynaklarının aşırı kullanımı veya darboğaz oluşumunu erken fark etmeyi sağlar. Ölçülmesi gereken temel metrikler: Loop time (Ana döngü periyodu örneğin 10 ms ±2 ms), Interrupt latency (Kesme tepkisi örneğin 10 µs'den kısa), CPU load (Ortalama %60, maksimum %80 sınırı). Ölçüm araçları: DWT_CYCCNT, FreeRTOS trace hooks, SystemView, logic analyzer. Raporlar periyodik olarak "Performance Summary" dokümanında saklanmalıdır. Bu madde, ISO/IEC 25010 – Performance Efficiency ve AUTOSAR Timing Analysis ilkeleriyle uyumludur.

Yazılımın farklı başlangıç koşullarında (soğuk/sıcak reset), kesme trafiği altında veya hata enjekte edilerek test edilmesi, dayanıklılık (resilience) değerlendirmesinin temelidir. Test senaryoları: Cold start (Bellek sıfırlı başlatma), Warm start (RAM korunarak devam), Fault injection (Sensör, haberleşme veya flash yazma hatası simülasyonu), Interrupt storm test (Yüksek kesme yoğunluğu altında işlem sürekliliği). Bu testler manuel değil, otomatikleştirilebilir şekilde yürütülmelidir. Sonuçlar "Reliability Test Record" altında belgelenmelidir. Bu madde, IEC 61508-3 Clause 7.4.7 – Fault Insertion Testing gerekliliğini karşılar.

Uzaktan yazılım güncelleme (OTA), ürün ömrü boyunca fonksiyonel gelişim ve hata düzeltmeleri için kritik bir yetenektir. Ancak güvenli ve dayanıklı bir OTA sistemi için rollback mekanizması zorunludur. Güncelleme süreci yalnızca imzalı firmware üzerinden çalışmalıdır. A/B partition veya dual-bank memory yapısı kullanılmalıdır: Yeni yazılım doğrulanmadan aktif hale getirilmemelidir, Güncelleme hatası durumunda sistem eski sürüme dönebilmelidir. Güncelleme sırasında güç kesilmesi senaryosu test edilmelidir. OTA logları (başlangıç, sonuç, checksum, sürüm) arşivlenmelidir. Bu madde, IEC 62443 – Secure Software Update ve ISO/SAE 21434 Cybersecurity for Vehicles gerekliliklerine uygundur.

Konfigürasyon yönetimi, geliştirilen yazılımın hangi sürümünün hangi donanım ve test setiyle uyumlu olduğunu izlemek için gereklidir. Sürüm kontrol sistemi olarak Git, SVN veya Mercurial kullanılmalıdır. Branching modeli: main/master (üretim kodu), develop (entegrasyon), feature/, hotfix/ (geçici dallar). Her sürüm bir tag (örn. v1.0.3) ile etiketlenmelidir. Commit mesajları standart biçimde yazılmalıdır: [MODULE] Fixed SPI timeout handling – Issue #123. Politika belgesi "Software Configuration Management Plan (SCMP)" olarak saklanmalıdır. Bu madde, ISO/IEC/IEEE 12207 Clause 6.2 – Configuration Control standardına uygundur.

Secure Boot, cihazın yalnızca yetkili yazılımı çalıştırmasını garanti altına alır. Bu, kötü niyetli kod yüklemelerine karşı temel koruma katmanıdır. Firmware, RSA/ECDSA algoritmasıyla dijital olarak imzalanmalıdır. Bootloader, her açılışta bu imzayı doğrulamalıdır. "Chain of Trust" yapısı: Boot ROM → Bootloader → Application. Private key üretici kontrolünde, public key firmware içinde saklanmalıdır. İmza doğrulama başarısız olursa sistem güvenli moda geçmelidir. Bu madde, IEC 62443-4-2 ve NIST SP 800-193 – Platform Firmware Resiliency standartlarına uygundur.

Kişisel veriler veya cihaz kimlik bilgileri içeren loglar, uygun şekilde maskeleme veya anonimleştirme işleminden geçmelidir. Örnek maskeleme: Device ID: 1289, User: U@mail.com. Log seviyeleri (INFO, WARN, ERROR, DEBUG) filtrelenebilir olmalıdır. Log sisteminde veri erişimi rol bazlı kontrol (RBAC) ile sınırlandırılmalıdır. Kritik loglar imzalanarak bütünlük kontrolü yapılmalıdır. Bu madde, GDPR / KVKK uyumluluğu ve ISO 27001 – Information Security Management ilkelerine uygundur.

Hataların kök neden analizinde en önemli parametre, olayın ne zaman ve hangi üründe gerçekleştiğidir. Her log satırında şu bilgiler yer almalıdır: Zaman damgası (UTC formatında), Cihaz seri numarası, Yazılım versiyonu, Hata kodu ve kısa açıklama. Örnek: [2025-11-12 14:32:01Z] SN:10293 V1.04 ERR:0x12 – I2C Timeout. Log kayıtları CSV veya binary formatta saklanmalı, 1000 kayıt üzeri sistemlerde döngüsel (circular) yapı kullanılmalıdır. Bu madde, ISO/IEC 27035-1 – Incident Management kriterlerini karşılar.

Kütüphanelerde, RTOS bileşenlerinde veya açık kaynak kodlarda yer alan bilinen açıkların (CVE – Common Vulnerabilities and Exposures) izlenmesi gerekir. Tarama araçları: NVD, Snyk, OWASP Dependency Check, GitHub Advisory Feed. Zafiyet raporları, her major sürümde gözden geçirilmelidir. Kritik açık (CVSS ≥ 7.0) tespit edildiğinde acil yama (patch) planı devreye alınmalıdır. Bu işlem CI/CD pipeline'ına entegre edilmelidir. Bu madde, ISO/SAE 21434 – Cybersecurity Management System standardına uygundur.

SBOM, yazılımın içeriğini oluşturan tüm bağımlılıkların (library, driver, middleware) listesidir. Tedarik zinciri güvenliği ve bakım süreçlerinde zorunlu hale gelmektedir. SBOM, JSON veya SPDX formatında tutulmalıdır. Her öğe için şu bilgiler bulunmalıdır: Bileşen adı ve sürümü, Lisans türü (MIT, BSD, GPL, vb.), Kaynak deposu (URL), Güvenlik statüsü (CVE bilgisi). SBOM dosyası sürümle birlikte arşivlenmeli, değişiklikler PCN/ECO süreciyle güncellenmelidir. Bu madde, NTIA SBOM Framework ve ISO/IEC 5230:2020 – OpenChain gereklilikleriyle uyumludur.