Gömülü Sistem Projelerinde Versiyon Kontrolü ve Dokümantasyon

Versiyon Kontrolünün Kritik Önemi

Gömülü Sistemlerde Versiyon Karmaşıklığı

Gömülü sistem projeleri, donanım ve yazılımın iç içe geçtiği benzersiz bir mühendislik alanıdır. Bu projelerde versiyon kontrolü, salt yazılım projelerine kıyasla çok daha karmaşık bir süreçtir çünkü donanım revizyonları, firmware sürümleri, bootloader versiyonları, FPGA bit dosyaları ve konfigürasyon parametreleri gibi birden fazla bileşenin versiyonlarının birbirleriyle uyumlu tutulması gerekir. Bir donanım revizyonundaki pin değişikliği, firmware güncellenmeden çalışamaz hale gelebilir; bir firmware güncellemesi, eski donanım revizyonlarıyla uyumsuz olabilir. Bu karmaşık bağımlılık ağının yönetimi, sistematik bir versiyon kontrol stratejisi olmadan imkansızdır. Dijital proje takip araçları bu süreci yapılandırılmış hale getirir.

Versiyon kontrol eksikliğinin sonuçları, gömülü sistem projelerinde özellikle yıkıcı olabilir. Sahada çalışan cihazlarda hangi firmware sürümünün yüklü olduğunun bilinmemesi, bir hata raporunun ilgili tasarım dosyalarıyla eşleştirilememesi, üretim hattında yanlış firmware sürümünün yüklenmesi veya bir müşteri sorununda hangi donanım revizyonunun kullanıldığının belirlenememesi gibi durumlar, proje ekiplerinin en sık karşılaştığı sorunlardır. Bu sorunların her biri, zaman kaybı, bütçe aşımı ve müşteri memnuniyetsizliği ile sonuçlanır.

Ürün Yaşam Döngüsü ve İzlenebilirlik

Gömülü sistem ürünleri, genellikle uzun yaşam döngülerine sahiptir. Endüstriyel kontrol sistemleri, medikal cihazlar, otomotiv elektroniği ve savunma sistemleri gibi alanlarda, ürünün on yıl ve üzerinde destek görmesi beklenir. Bu uzun süre boyunca, bileşen üretimden kalkması (end-of-life), güvenlik yamaları, performans iyileştirmeleri ve yasal düzenleme değişiklikleri nedeniyle ürün revizyonları kaçınılmazdır. Her revizyonun eksiksiz izlenebilirliği, ürünün tüm yaşam döngüsü boyunca desteklenebilmesinin temel koşuludur.

IEC 62304 (medikal cihaz yazılım yaşam döngüsü), ISO 26262 (otomotiv fonksiyonel güvenlik), DO-178C (havacılık yazılımı) ve IEC 61508 (endüstriyel fonksiyonel güvenlik) gibi sektörel standartlar, versiyon kontrolü ve izlenebilirliği zorunlu kılmaktadır. Bu standartlara uyum sağlamak, yalnızca yasal bir gereklilik değil, aynı zamanda mühendislik disiplini ve ürün kalitesinin göstergesidir.

Donanım Versiyon Yönetimi

PCB Revizyon Stratejisi

Donanım versiyon yönetimi, yazılım versiyon kontrolünden temelden farklıdır çünkü donanım değişiklikleri fiziksel üretim gerektirir ve geri alınamaz. PCB revizyon numaralandırma sistemi, değişikliğin kapsamını ve etkisini açıkça yansıtmalıdır. Yaygın kullanılan bir yaklaşım, majör revizyon harflerini (Rev A, Rev B, Rev C) kullanmaktır. Rev A ilk prototip, her sonraki majör revizyon ise şematik veya layout değişikliği içeren yeni bir PCB üretimini temsil eder.

Her PCB revizyonunda, değişiklik listesi (Engineering Change Order - ECO) hazırlanmalıdır. ECO, değişikliğin nedenini, yapılan değişikliklerin detayını, etkilenen bileşenleri, geriye uyumluluk durumunu ve doğrulama gereksinimlerini kapsar. ECO numarası, PCB revizyon numarasıyla eşleştirilir ve tüm ilgili dokümanlar (şematik, layout, BOM, Gerber dosyaları) aynı revizyon numarası altında arşivlenir.

Şematik ve layout dosyaları için Git gibi dağıtık versiyon kontrol sistemlerinin kullanımı giderek yaygınlaşmaktadır. Altium Designer 365, KiCad ve diğer modern EDA araçları, Git entegrasyonunu desteklemektedir. Ancak ikili (binary) dosya formatları nedeniyle, metin tabanlı diff ve merge işlemleri doğrudan mümkün olmayabilir. KiCad'in metin tabanlı dosya formatı, bu açıdan önemli bir avantaj sunar. Her durumda, her commit mesajının değişikliğin nedenini ve kapsamını açıkça belirtmesi ve anlamlı etiketlerin (tag) kullanılması kritik önem taşır.

BOM Versiyon Kontrolü

Bill of Materials (BOM), donanım versiyonunun ayrılmaz bir parçasıdır. Her PCB revizyonunun kendine ait bir BOM versiyonu olmalıdır. Ancak aynı PCB revizyonu için bile BOM değişikliği gerekebilir; örneğin, bir bileşenin üretimden kalkması nedeniyle alternatif bileşene geçiş. Bu durumda BOM versiyonu güncellenir ancak PCB revizyonu aynı kalır. BOM versiyon numaralandırması, PCB revizyon numarası ile kombinasyon halinde kullanılarak (örneğin Rev B, BOM v2.1) net bir izlenebilirlik sağlanır.

BOM yönetiminde dikkat edilmesi gereken kritik noktalar arasında bileşen yaşam döngüsü durumunun takibi (aktif üretimde, son satın alma uyarısı, üretimden kalkmış), alternatif bileşenlerin doğrulama durumu (form-fit-function uyumluluğu test edilmiş mi?), bileşen referans numaraları ile şematik arasındaki tutarlılık ve üretim notlarının BOM ile birlikte versiyonlanması yer alır.

Firmware Versiyon Stratejileri

Semantik Versiyonlama (SemVer)

Firmware versiyonlama için Semantik Versiyonlama (Semantic Versioning) standardı, açık ve tutarlı bir çerçeve sunar. MAJOR.MINOR.PATCH formatında: MAJOR, geriye uyumsuz değişiklikleri (yeni donanım revizyonu desteği, protokol değişikliği), MINOR, geriye uyumlu yeni özellikleri (yeni sensör desteği, performans iyileştirmesi) ve PATCH, geriye uyumlu hata düzeltmelerini temsil eder.

Gömülü sistem projelerinde firmware versiyonuna ek olarak, build numarası ve donanım uyumluluk bilgisinin de dahil edilmesi önerilir. Örneğin, v2.3.1-build1847-hwRevC formatı, firmware sürümünün (2.3.1), tam build numarasının (1847) ve uyumlu donanım revizyonunun (Rev C) tek bakışta anlaşılmasını sağlar. Bu bilgi, firmware binary dosyasının içine gömülerek, cihazdan firmware sorgulama komutuyla okunabilir hale getirilmelidir.

Git Branching Stratejisi

Firmware geliştirme için uygun bir Git branching stratejisinin benimsenmesi, ekip verimliliğini ve kod kalitesini doğrudan etkiler. Gitflow modeli, gömülü sistem projeleri için yaygın olarak tercih edilen bir yaklaşımdır. Main branch (kararlı üretim kodu), develop branch (aktif geliştirme), feature branch'ler (yeni özellikler), release branch'ler (sürüm hazırlığı) ve hotfix branch'ler (acil hata düzeltmeleri) bu modelin temel bileşenleridir.

Gömülü sistemlerde özel olarak dikkat edilmesi gereken bir konu, farklı donanım revizyonlarının desteklenmesidir. Aynı firmware kod tabanının birden fazla donanım revizyonunu desteklemesi gerektiğinde, koşullu derleme (conditional compilation) direktifleri veya donanım soyutlama katmanı (HAL) kullanılabilir. Alternatif olarak, her donanım revizyonu için ayrı branch'ler oluşturulabilir, ancak bu yaklaşım bakım yükünü artırır. Optimal strateji, HAL tabanlı soyutlama ile tek bir kod tabanının tüm desteklenen donanım revizyonlarını kapsamasıdır.

Firmware Güncelleme ve Dağıtım

Sahada çalışan cihazların firmware güncellemesi (OTA - Over-the-Air veya kablolu), versiyon yönetiminin en kritik uygulama alanıdır. Güvenli ve güvenilir bir firmware güncelleme mekanizması; kriptografik imza doğrulaması (güncelleme dosyasının bütünlüğü ve kaynağı), geri dönüş mekanizması (güncelleme başarısız olursa önceki sürüme otomatik dönüş), donanım uyumluluk kontrolü (yanlış firmware yüklenmesinin engellenmesi), güncelleme durumu raporlaması (başarılı/başarısız bilgisi sunucu tarafına iletilmesi) ve bölümlenmiş güncelleme desteği (sadece değişen modüllerin güncellenmesi) özelliklerini içermelidir.

AECKraft platformu, firmware sürüm geçmişinin, dağıtım durumunun ve cihaz-firmware eşleşmesinin merkezi olarak takip edilmesine olanak tanır. Hangi cihazda hangi firmware sürümünün çalıştığı, güncelleme geçmişi ve bekleyen güncellemeler gibi bilgiler, proje ekibinin tam görünürlük sağlamasına yardımcı olur.

Dokümantasyon Standartları

Donanım Dokümantasyonu

Gömülü sistem projelerinin donanım dokümantasyonu, tasarım kararlarının gerekçeleriyle birlikte kayıt altına alınmasını gerektirir. Temel donanım dokümanları şunlardır: Donanım Gereksinim Spesifikasyonu (HRS, donanımın karşılaması gereken fonksiyonel ve performans gereksinimleri), Donanım Tasarım Dokümanı (HDD, devre tasarım kararları, hesaplamalar, bileşen seçim gerekçeleri), şematik ve PCB layout dosyaları (versiyonlanmış EDA projeleri), BOM (versiyonlanmış, onaylanmış alternatifler dahil), test prosedürleri ve test raporları (her revizyon için) ve EMC ve güvenlik test raporları.

Tasarım kararlarının gerekçelendirilmesi, donanım dokümantasyonunun en değerli ancak en sık atlanan kısmıdır. Neden bu mikrodenetleyici seçildi? Neden bu güç topolojisi tercih edildi? Neden bu bileşen değeri hesaplandı? Bu soruların cevapları, gelecekte tasarımı revize edecek mühendisler için paha biçilmez bilgilerdir. Aksi takdirde, her revizyon adeta sıfırdan bir keşif süreci haline gelir.

Firmware Dokümantasyonu

Firmware dokümantasyonu, kod içi yorumlardan çok daha kapsamlı bir süreçtir. Firmware Mimari Dokümanı, sistemin yazılım mimarisini (modüller, katmanlar, arayüzler, iletişim mekanizmaları) tanımlar. API dokümantasyonu, her modülün dış arayüzünü (fonksiyon prototipleri, parametreler, dönüş değerleri, hata kodları) detaylandırır. Doxygen veya benzeri araçlarla koddan otomatik olarak üretilebilir. Donanım Soyutlama Katmanı (HAL) Dokümanı, donanıma özgü erişim fonksiyonlarını ve register haritalarını tanımlar. Bootloader Dokümanı, cihaz başlatma sürecini, bellek haritasını ve firmware güncelleme mekanizmasını açıklar.

Kod içi dokümantasyon için tutarlı bir standart belirlenmeli ve ekip genelinde uygulanmalıdır. Her dosyanın başında dosya amacı, yazar bilgisi, tarih ve lisans bilgisi; her fonksiyonun başında kısa açıklama, parametre tanımları ve dönüş değeri; karmaşık algoritmalarda adım adım açıklama ve magic number yerine anlamlı sabitler ve enum tanımları kullanılmalıdır. MISRA C veya CERT C gibi kodlama standartlarına uyum, hem kod kalitesini hem de dokümantasyon tutarlılığını artırır.

Arayüz Kontrol Dokümanı (ICD)

Donanım ve yazılım arasındaki arayüzlerin tanımlandığı ICD, gömülü sistem projelerinin en kritik dokümanlarından biridir. ICD kapsamında register haritaları (adres, bit alanları, erişim tipi, varsayılan değerler), iletişim protokolleri (mesaj formatları, zamanlama diyagramları, hata yönetimi), pin atamaları (GPIO fonksiyonları, alternatif fonksiyonlar, elektriksel özellikler), kesme (interrupt) tanımları (öncelik, tetikleme koşulu, servis süresi gereksinimleri) ve bellek haritası (flash bölümleme, RAM kullanımı, paylaşımlı kaynaklar) yer alır.

ICD, donanım ve yazılım ekiplerinin ortak referans noktasıdır. Her iki tarafın da aynı doküman üzerinde çalışması ve değişikliklerin karşılıklı onay sürecinden geçmesi gerekir. ICD değişikliklerinin versiyon kontrolü altında olması ve değişiklik geçmişinin tutulması, uyumsuzluk sorunlarının önlenmesinde kritik öneme sahiptir.

Dijital Araçlarla Entegre Yönetim

Araç Zinciri Entegrasyonu

Modern gömülü sistem geliştirme, birçok aracın koordineli kullanımını gerektirir. EDA araçları (Altium, KiCad, OrCAD), IDE'ler (STM32CubeIDE, IAR, Keil), versiyon kontrol sistemleri (Git, SVN), CI/CD platformları (Jenkins, GitLab CI), hata takip sistemleri (Jira, Bugzilla) ve dokümantasyon araçları (Confluence, Doxygen) bu araç zincirinin temel bileşenleridir. Bu araçların birbirleriyle entegrasyonu, veri akışının otomasyonu ve tekrarlanabilir süreçlerin oluşturulması, ekip verimliliğini büyük ölçüde artırır.

Sürekli Entegrasyon (CI) firmware geliştirmede giderek daha yaygın kullanılmaktadır. Her commit'te otomatik derleme, statik kod analizi, birim testleri ve (mümkünse) donanım simülasyonu çalıştıran CI pipeline'ları, hataların erken tespit edilmesini sağlar. Firmware binary dosyasının otomatik olarak versiyonlanması, arşivlenmesi ve dağıtıma hazır hale getirilmesi de CI sürecinin parçasıdır.

Merkezi Proje Yönetim Platformu

AECKraft gibi merkezi proje yönetim platformları, gömülü sistem projelerinin tüm bileşenlerini bir araya getiren dijital omurgayı oluşturur. Donanım dokümanları, firmware kaynak kodu referansları, test raporları, hata kayıtları, toplantı notları ve proje planları tek bir platformda yönetildiğinde, bilgi siloları ortadan kalkar ve ekip genelinde tam görünürlük sağlanır.

Özellikle çok disiplinli ekiplerde (donanım mühendisleri, firmware geliştiricileri, test mühendisleri, proje yöneticileri), bilgi akışının merkezi bir platform üzerinden yönetilmesi iletişim kopukluklarını önler. Bir donanım revizyonunun firmware ekibini otomatik olarak bilgilendirmesi, bir hata raporunun ilgili tasarım dosyalarına bağlanması ve bir test sonucunun proje zaman çizelgesini güncellemesi gibi entegre iş akışları, projenin bütünsel kontrolünü sağlar.

İzlenebilirlik Matrisi

İzlenebilirlik matrisi, gereksinimlerden tasarıma, tasarımdan uygulamaya ve uygulamadan teste kadar tüm bağlantıları gösteren kritik bir dokümandır. Gömülü sistem projelerinde bu matris, donanım gereksinimleri ile şematik tasarım elemanları, firmware gereksinimleri ile kod modülleri, test gereksinimleri ile test prosedürleri ve sertifikasyon gereksinimleri ile doğrulama kanıtları arasındaki bağlantıları kapsar. Bu matris, herhangi bir gereksinimin karşılanmamış olup olmadığını ve herhangi bir tasarım elemanının gereksinimsiz olup olmadığını tespit etmeye yarar.

AECKraft platformunda görevler, dokümanlar ve etiketler arasındaki bağlantılar kullanılarak izlenebilirlik matrisinin dijital ortamda yönetilmesi mümkündür. Bu yaklaşım, özellikle sertifikasyon süreçlerinde (CE, FCC, UL) denetçilere sunulması gereken izlenebilirlik kanıtlarının hazırlanmasını büyük ölçüde kolaylaştırır.

Sıkça Sorulan Sorular

Donanım tasarım dosyaları için Git kullanmak uygun mudur?

Git, firmware ve metin tabanlı dosyalar için mükemmel bir versiyon kontrol sistemidir. Donanım tasarım dosyaları için ise duruma göre değerlendirilmelidir. KiCad gibi metin tabanlı dosya formatı kullanan EDA araçlarında Git çok etkilidir çünkü satır satır diff ve merge işlemleri yapılabilir. Altium Designer gibi ikili dosya formatı kullanan araçlarda, Git dosyaları saklayabilir ve geçmişi tutabilir ancak anlamlı diff mümkün olmaz. Bu durumda Altium 365 gibi araç-spesifik versiyon kontrol çözümleri veya Git ile birlikte LFS (Large File Storage) kullanımı önerilir. Her durumda, commit mesajlarının değişikliği detaylı açıklaması ve anlamlı etiketlerin kullanılması kritik önem taşır.

Firmware ve donanım versiyonları arasındaki uyumluluk nasıl yönetilir?

Uyumluluk yönetimi için bir uyumluluk matrisi oluşturulmalıdır. Bu matris, her firmware sürümünün hangi donanım revizyonlarıyla uyumlu olduğunu açıkça gösterir. Firmware içinde donanım revizyon tespiti mekanizması (GPIO okuma, EEPROM veya resistor divider ile revizyon kodu okuma) bulunmalı ve uyumsuz donanımda firmware çalışması engellenmelidir. CI/CD sürecinde, her firmware build'inin desteklenen tüm donanım revizyonları için derlenip test edilmesi otomatize edilmelidir. Uyumluluk matrisinin ve donanım-firmware eşleştirmesinin merkezi dokümantasyonda güncel tutulması, sahada yaşanabilecek uyumsuzluk sorunlarını önler.

Küçük ekiplerde dokümantasyon yükü nasıl hafifletilir?

Küçük ekiplerde kapsamlı dokümantasyon, pratik olmayabilir. Ancak minimum dokümantasyon seviyesi korunmalıdır. Code-as-documentation ilkesini benimseyerek, kendini açıklayan kod yazın ve Doxygen yorumlarını disiplinli şekilde kullanın. Şablon kullanımı, yeni doküman oluşturma süresini kısaltır. README dosyaları ile proje kurulumu, derleme talimatları ve temel mimari bilgisi kayıt altına alınmalıdır. Tasarım kararlarının gerekçelerini kısa notlar halinde bile olsa kaydetmek, hiç kaydetmemekten çok daha iyidir. Dijital proje yönetim araçlarında görev açıklamaları ve yorumlar, gayri resmi dokümantasyon işlevi görebilir ve zaman içinde değerli bir bilgi birikimi oluşturur.