IATF 16949’da Gömülü Yazılım: Denetçinin Sorduğu Kanıtlar

Ürününde mikrodenetleyici olan otomotiv tedarikçisi, IATF 16949 denetiminde yalnız kalıp ve proses kontrolüyle sorgulanmaz. Denetçi o mikrodenetleyicideki yazılımın nasıl geliştirildiğini, hangi sürümün hangi araçla derlendiğini ve hat sonunda doğru dosyanın yüklendiğini sorar. Bu soruların çoğu kalite biriminden değil, kod deposunu, derleme sunucusunu ve programlama istasyonunu işleten BT ile yazılım ekibinin ortak alanından cevaplanır. Aşağıda standardın istediklerini, Automotive SPICE ile ilişkisini ve sahada en sık açık veren noktaları sırasıyla ele alıyoruz.

Gereklilik hangi şirketleri kapsar?

IATF 16949:2016’da gömülü yazılımla doğrudan ilgili iki madde var. 8.3.2.3 (Gömülü yazılım içeren ürünlerin geliştirilmesi), ürünün içindeki yazılımı kendi bünyesinde geliştiren kuruluşa yöneliktir: yazılım kalite güvencesi için bir süreç kurulmasını, geliştirme sürecinin uygun bir değerlendirme metodolojisiyle değerlendirilmesini, risk ve müşteriye olası etki esas alınarak önceliklendirilen bir öz değerlendirmenin dokümante bilgi olarak saklanmasını ve yazılım geliştirmenin iç denetim programına alınmasını ister. 8.4.2.3.1 aynı beklentiyi tedarik zincirine taşır: otomotiv ürünüyle ilgili yazılım veya gömülü yazılım içeren ürün tedarik eden alt tedarikçilerin de kalite güvencesi süreci işletmesini, süreçlerini bir metodolojiyle değerlendirmesini ve risk esaslı öz değerlendirmeyi kendisinin saklamasını şart koşar.

Durum	İlgili madde	Beklenen
ECU yazılımı şirket içinde yazılıyor	8.3.2.3	Süreç, öz değerlendirme, iç denetim
Yazılım bir tasarım evine yaptırılıyor	8.4.2.3.1	Tedarikçide süreç şartı ve izleme
Hazır modül kendi yazılımıyla alınıyor	8.4.2.3.1	Tedarikçide süreç ve öz değerlendirme kanıtı
Hat sonunda yazılım/parametre yükleniyor	8.3.2.3 ve 8.5	Doğru sürümün yüklendiğinin kontrolü

Sınırı baştan net çizin. Test standı, CMM veya SPC aracı gibi üretimde kullanılan yazılımlar ürünün parçası değildir; onların doğrulaması ayrı konudur ve ölçüm ve test yazılımlarının doğrulanması rehberinde anlatılır. Burada konu, araçla birlikte müşteriye giden yazılım. Sahada iki kapsam sık karıştırılıyor. Sonuç, iki yarım dosya.

Yazılım kalite güvencesi süreci neleri içermeli?

Standart süreç adımlarını tek tek saymaz; “kalite güvencesi süreci” ifadesi değerlendirme metodolojisiyle birlikte okunur. Denetçinin pratikte aradığı şey, yazılımın gereksinimden teslimata kadar kontrollü bir yaşam döngüsünde ilerlediğinin ve bu döngünün bağımsız bir gözle izlendiğinin kanıtıdır. Asgari bileşenler şunlar:

• Gereksinim yönetimi: Müşteri gereksiniminden yazılım gereksinimine izlenebilirlik; her gereksinim bir doğrulama durumuyla eşlenir.
• Mimari ve detay tasarım: Bileşen sınırları ve arayüzler belgelenir; güvenlik veya fonksiyonel emniyet etkisi olan kararların gerekçesi yazılır.
• Doğrulama: Birim testi, entegrasyon testi ve yazılım nitelik testi; statik analiz ve kodlama standardı (örneğin MISRA C) uyumu raporlanır.
• Sürüm onayı: Hangi testin hangi derlemeye karşı koşulduğunu gösteren, imzalı bir sürüm kararı.
• Konfigürasyon, problem ve değişiklik yönetimi: Geliştirmenin her aşamasını kesen destek süreçleri ve kayıtları.
• Kalite güvencesi: Proje ekibinden bağımsız bir rolün süreç ve ürün uygunluğunu periyodik kontrol etmesi, sapmaları kapanana kadar takip etmesi.

Denetimde en sık eksik çıkan son maddedir. Küçük ekiplerde ayrı bir yazılım kalite mühendisi olmayabilir. Bu durumda başka bir projenin kıdemli geliştiricisinin çapraz gözden geçirme yapması ve bulguların kayda alınması, bağımsızlığı makul düzeyde gösterir. Kaydı olmayan gözden geçirme ise yapılmamış sayılır.

Automotive SPICE ve öz değerlendirme

Standart belirli bir model dayatmaz; “uygun bir değerlendirme metodolojisi” ister. Otomotivde bu ihtiyaç büyük ölçüde VDA QMC’nin yayımladığı Automotive SPICE süreç değerlendirme modeliyle karşılanır; bazı kuruluşlar CMMI gibi alternatifler kullanır. Hangi modelin ve hangi hedef seviyenin beklendiği çoğu zaman müşteri özel gerekliliklerinde (CSR) yazılıdır. Öz değerlendirmeye başlamadan önce ilgili OEM’in CSR dokümanını okuyun; sonradan modeli değiştirmek işi ikiye katlar.

Automotive SPICE süreçleri gruplar halinde tanımlar: sistem mühendisliği (SYS), yazılım mühendisliği (SWE), destek (SUP), yönetim (MAN) ve tedarik (ACQ) en çok değerlendirilenlerdir. Her süreç 0–5 arası yetenek seviyesiyle derecelendirilir; süreç nitelikleri N (sağlanmadı), P (kısmen), L (büyük ölçüde) ve F (tamamen) ölçeğiyle puanlanır. Seviye 1 sürecin amacına ulaştığını, seviye 2 sürecin ve iş ürünlerinin yönetildiğini, seviye 3 kurumsal olarak tanımlanmış standart bir sürecin kullanıldığını gösterir.

Öz değerlendirme resmi değerlendirme değildir. Ama gelişigüzel bir anket de olamaz. Uygulanabilir sıra şöyle:

1. Risk ve müşteri etkisine göre önceliklendirilmiş proje listesini çıkarın; emniyetle ilgili veya yüksek hacimli ürünler önce gelir.
2. Kapsamı belirleyin: hangi süreçler, hangi hedef seviye. Müşterinin istediği süreç kümesi biliniyorsa onu esas alın.
3. Her süreç için temel uygulamaları ve iş ürünlerini projedeki gerçek kayıtlarla karşılaştırın; görüşmeyi kanıtla destekleyin.
4. Derecelendirmeyi N/P/L/F olarak kaydedin, boşlukları sahibi ve tarihi belli aksiyonlara dönüştürün.
5. Sonucu yönetimin gözden geçirmesine ve iç denetim programına girdi olarak verin.

Konfigürasyon ve sürüm yönetimi

Sahadan arıza bildirildiğinde ilk soru şudur: bu araçtaki ECU’da tam olarak hangi yazılım vardı, o yazılım hangi kaynaktan, hangi araçlarla üretildi? Bu soruyu dakikalar içinde cevaplayabilmek konfigürasyon yönetiminin asıl amacıdır. Cevap günler sürüyorsa süreç kâğıt üzerindedir. Bir sürümün temel çizgisi (baseline) yalnız kaynak koddan oluşmaz:

• Kaynak kod ve derleme betikleri (commit kimliğiyle)
• Derleyici, bağlayıcı ve kütüphane sürümleri ile derleme seçenekleri
• Kalibrasyon ve varyant parametre dosyaları
• Üretilen ikili dosya (hex/bin) ve özet değeri
• Test raporları ve sürüm notu

Sürüm etiketini imzalamak ve ikili dosyanın özet değerini kayda geçirmek, programlama istasyonuna giden dosyanın onaylanan dosya olduğunu kanıtlamanın en basit yoludur:

# Onaylanan sürümü imzalı etiketle işaretle
git tag -s v2.4.1 -m "ECU-X yazılım sürümü 2.4.1 - sürüm onayı SR-0412"
git verify-tag v2.4.1

# İkili dosyanın SHA-256 özetini üret ve sürüm kaydına ekle
sha256sum ecu_x_2.4.1.hex > ecu_x_2.4.1.hex.sha256

# Programlama istasyonunda yüklemeden önce doğrula
sha256sum -c ecu_x_2.4.1.hex.sha256

Hat sonu yazılım yükleme, geliştirme ile üretimin kesiştiği noktadır ve denetçinin ayrıntıya indiği yerdir. Programlama istasyonu dosyayı nereden alıyor, o dosyayı kim değiştirebiliyor, yükleme sonrası ECU’dan okunan sürüm bilgisi parça seri numarasıyla birlikte kaydediliyor mu? Sahada en sık gördüğümüz açık, istasyonun yerel diskinde elle kopyalanmış bir dosya ve hiçbir yükleme kaydı olmamasıdır. İstasyondaki dosya değişikliği bir üretim değişikliğidir; sınıflandırması üretim sistemlerinde değişiklik yönetimi rehberindeki süreçle uyumlu olmalıdır.

Geliştirme araç zinciri ve kod deposunun yönetimi

Gömülü yazılım ekipleri araçlarını çoğu zaman kendileri seçer ve kurar. Ancak bu araçların çalıştığı sunucular, lisans sunucuları, yedekleme ve erişim yönetimi BT’nin işidir. Sorumluluk sınırı yazılı değilse BT uyum denetiminde “bunu kim yapıyor?” sorusu iki ekip arasında boşta kalır.

Alan	BT sorumluluğu	Geliştirme sorumluluğu
Kod deposu (Git sunucusu)	Barındırma, yedek, erişim, kimlik doğrulama	Dal stratejisi, inceleme kuralları
Derleme sunucuları (CI)	İşletim sistemi, yama, kapasite	Pipeline tanımı, araç sürümleri
Derleyici lisansları	Lisans sunucusu sürekliliği	Lisans ihtiyacı ve sürüm seçimi
Araç arşivi	Uzun süreli saklama ve geri yükleme testi	Arşivlenecek araç setinin tanımı
Sürüm dosyaları	Programlama istasyonuna güvenli dağıtım	Sürüm onayı ve özet değeri

Tabloda en çok gözden kaçan satır araç arşividir. Otomotiv parçaları seri üretimden sonra yıllarca yedek parça olarak üretilir ve sahada yazılım düzeltmesi gerekebilir. Derleyicinin o sürümü, lisansı ve çalıştığı işletim sistemi kaybolmuşsa aynı ikili dosyayı yeniden üretemezsiniz. Kaynak kod tek başına yetmez. Pratik çözüm: her ana sürüm için derleme ortamını sanal makine veya konteyner imajı olarak arşivleyin, kurulum dosyalarını ve lisans bilgisini yanına koyun, yılda en az bir kez bu ortamdan derleme yapıp aynı özet değerini aldığınızı doğrulayın. Lisans sunucusu MAC adresine veya donanım anahtarına bağlıysa, bu bağımlılığı da arşiv notuna yazın; geri yüklemede ilk takılan yer orası olur.

Fonksiyonel emniyet kapsamındaki projelerde ISO 26262-8’in yazılım araçlarına güven (araç güven seviyesi, TCL) bölümü ayrıca devreye girer: kod üreteçleri, statik analiz ve test araçları için araç sınıflandırması ve gerekiyorsa araç kalifikasyonu kanıtı istenir. Aracın sürümü değiştiğinde bu kanıtın geçerliliği yeniden değerlendirilir. Bu yüzden araç güncellemesi BT tarafında rutin bir yama gibi ele alınmamalı; derleme sunucusuna otomatik güncelleme açmak, kalifiye edilmiş aracı sessizce değiştirmek demektir.

Kod deposunda asgari kontroller şunlar: korumalı ana dal ve zorunlu kod incelemesi, kişisel hesaplarla kimlik doğrulama ve çok faktörlü doğrulama, ayrılan personelin erişiminin aynı gün kapatılması, deponun ve CI yapılandırmasının yedeklenmesi ve geri yükleme testinin kayda geçmesi. Paylaşılan “build” hesabıyla push yapılan depo, kimin neyi değiştirdiğini kanıtlayamaz. Müşteri kaynaklı spesifikasyonlar veya OEM’e ait kod parçaları depodaysa bunlar aynı zamanda müşteri mülkiyetidir ve erişim kısıtlaması buna göre planlanır.

Denetimde beklenen kanıtlar

Aşağıdaki liste 8.3.2.3 ve 8.4.2.3.1 kapsamında hazır olması gereken kanıtları toplar. Genel BT kanıtlarıyla birleştirmek için IATF 16949 denetiminde BT kanıtları rehberindeki liste kullanılabilir.

• Yazılım geliştirme süreç tanımı ve rol tanımları (kalite güvencesi rolü dahil)
• Seçilen değerlendirme metodolojisi, gerekçesi ve müşteri CSR’ı ile eşleşmesi
• Risk esaslı önceliklendirilmiş öz değerlendirme raporu ve aksiyon planı
• Yazılım geliştirmeyi kapsayan iç denetim planı ve son denetim raporu
• Örnek bir sürüm için gereksinim–test izlenebilirlik matrisi
• Sürüm onay kaydı, imzalı etiket ve ikili dosya özet değeri
• Araç listesi, sürümleri ve araç arşivinin geri yükleme testi kaydı
• Yazılım alt tedarikçileri için sözleşme şartları ve izleme kayıtları
• Kod deposu erişim listesi ve periyodik erişim gözden geçirme kaydı

Sahada sık görülen hatalar

Öz değerlendirmeyi bir kez yapıp unutmak: Standart öz değerlendirmenin dokümante bilgi olarak saklanmasını ister. Süreç değiştiğinde, yeni müşteri ya da yeni ürün ailesi geldiğinde güncellenmeyen rapor, denetçinin “bu hâlâ geçerli mi?” sorusuna cevap vermez.

Yazılımı iç denetim dışında bırakmak: Kalite birimindeki iç denetçiler yazılım süreçlerine yabancıysa bu alan sessizce atlanır. Madde bunu açıkça istiyor. Çözüm, IATF 16949 denetim hazırlığı sırasında yazılım bilgisi olan bir denetçiyi ekibe eklemek veya dış kaynaklı bir iç denetim planlamaktır.

Hat sonu programlama dosyasını paylaşılan klasörde tutmak: Herkesin yazabildiği bir ağ klasöründen yüklenen dosya, onaylı sürümle aynı olduğunu kanıtlayamaz. Salt okunur dağıtım, özet kontrolü ve yükleme kaydı birlikte kurulur; biri eksikse zincir kopar.

Alt tedarikçinin yazılımını kara kutu saymak: 8.4.2.3.1 satın alınan yazılım için de kalite güvencesi süreci ve tedarikçi öz değerlendirmesi ister. Öz değerlendirme özetine ek olarak sürüm notu, test özeti ve sürüm kimliği istenmeli, bunlar gelen kalite kontrolünde kayda geçmelidir.

Gömülü yazılım gerekliliklerini TISAX ve ISO 27001 kapsamındaki kod deposu ve erişim kontrolleriyle tek programda yönetmek, aynı kanıtın birden fazla denetimde kullanılmasını sağlar; çerçevesi entegre TISAX, ISO 27001 ve IATF programı sayfasında anlatılıyor. Standardın resmi metni ve yorumları için IATF Global Oversight, Automotive SPICE modeli için VDA QMC birincil kaynaktır.

Sık sorulan sorular

Automotive SPICE sertifikası IATF 16949 için zorunlu mu?

Hayır. IATF 16949 yazılım geliştirme sürecinin uygun bir metodolojiyle değerlendirilmesini ve öz değerlendirmenin saklanmasını ister; belirli bir model veya resmi değerlendirme şart koşmaz. Ancak birçok OEM, müşteri özel gerekliliklerinde Automotive SPICE’ı ve hedef yetenek seviyesini açıkça yazar. O durumda müşteri şartı bağlayıcıdır.

Yazılımı tamamen dış tasarım firmasına yaptırıyoruz; 8.3.2.3 bizi kapsar mı?

Yazılım şirket içinde geliştirilmiyorsa 8.3.2.3’ün öz değerlendirme yükümlülüğü doğrudan uygulanmayabilir; bu kez 8.4.2.3.1 devreye girer. Tasarım firmasının yazılım kalite güvencesi süreci işletmesini ve kendi öz değerlendirmesini saklamasını sözleşmeye yazmanız ve bunu izlemeniz gerekir. Gereksinimi yazmak, sürümü kabul etmek ve saha sorununu yönetmek yine sizin işinizdir.

Kalibrasyon parametresi değişikliği yazılım değişikliği sayılır mı?

Ürünün davranışını değiştiren her parametre seti konfigürasyon yönetiminin konusudur ve sürüm temel çizgisinin parçası olarak izlenir. Müşteri onayı gerekip gerekmediğini ürün onayı süreci ve müşteri gereklilikleri belirler; bu karar değişiklik kaydına açıkça yazılmalıdır.

Eski bir sürümü yıllar sonra yeniden derleyebilmek için ne saklamalıyız?

Kaynak kodun yanında derleyici ve kütüphane kurulum dosyaları, lisans bilgisi, derleme betikleri ve derleme ortamının sanal makine veya konteyner imajı saklanmalıdır. Arşivin çalıştığı, bu ortamdan derleme yapılıp aynı özet değerinin elde edilmesiyle periyodik olarak doğrulanmalıdır.