Bir elektronik kontrol ünitesi üreten firmanın tetkikinde konu donanımdan hızla kaydı: "Sahadaki bu araçta hangi yazılım sürümü yüklü?" Ekipten kimse net cevap veremedi. Kart izlenebilirdi, lehim prosesi kayıtlıydı, kutu barkodluydu; ama içindeki yazılımın hangi sürüm olduğu, hangi parti karta yüklendiği kayıtlı değildi. İşte gömülü yazılımın klasik açığı buradadır: fiziksel parçayı titizlikle izleyen firmalar, çoğu zaman kartın beynine yüklenen kodu aynı disiplinle yönetmez. IATF 16949 tam da bu boşluğu kapatmak için yazılıma özel şartlar getirir. Bu yazıda bu şartların ne istediğini ve sahada nasıl karşılandığını konuşuyoruz.
IATF 16949 yazılım için ne der?
Standart, ürününde gömülü yazılım bulunan kuruluşlardan iki şey bekler. Birincisi, yazılım geliştirme için bir kalite güvence süreci kurmaları; yazılımı, mekanik bir parçayı geliştirir gibi disiplinli bir yaşam döngüsüyle üretmeleri. İkincisi, kendi yazılım geliştirme yeteneklerini bir öz değerlendirme yöntemiyle ölçüp izlemeleri. Yazılım, standardın gözünde de bir üründür; dolayısıyla planlama, doğrulama, konfigürasyon yönetimi ve izlenebilirlik onun için de geçerlidir.
Bu şart, otomobillerin giderek "tekerlekli bilgisayara" dönüşmesiyle birlikte ağırlık kazandı. Bir fren kontrol ünitesindeki yazılım hatası, kırık bir parça kadar, hatta ondan daha tehlikeli olabilir; üstelik gözle görülmez. IATF 16949'un bütününü IATF 16949 rehberimizde ele alıyoruz; burada yazılıma özgü kısma odaklanıyoruz.
Öz değerlendirme ve Automotive SPICE
Standart, yazılım yeteneğini ölçmek için belirli bir modelin adını dayatmaz; bir öz değerlendirme metodolojisi ister. Sektörde bu amaçla en çok kullanılan model Automotive SPICE (ASPICE) olmuştur. ASPICE, yazılım geliştirme süreçlerini gereksinim analizi, tasarım, kodlama, test ve entegrasyon gibi başlıklarda olgunluk seviyelerine göre değerlendirir. Pek çok büyük müşteri, tedarikçisinden doğrudan belli bir ASPICE seviyesini talep eder; yani standart adını zorunlu kılmasa da müşteri özel şartı çoğu zaman kılar.
Öz değerlendirmenin amacı bir sertifika toplamak değil, kendi zayıf halkanızı bulmaktır. Gereksinimleriniz izlenebilir mi, testleriniz gereksinimlere bağlı mı, bir değişiklik geldiğinde etkisini görebiliyor musunuz? Bu sorulara dürüst cevap vermek, tetkikten çok önce yazılım kalitenizi yükseltir.
Öz değerlendirmeyi bir defalık bir tatbikat gibi görmeyin. En işe yarayan firmalar bunu düzenli aralıklarla, tercihen her önemli proje kilometre taşında tekrarlar ve çıkan zayıf noktaları küçük ama takip edilen iyileştirme aksiyonlarına bağlar. "Test kapsamımız gereksinimlerin ancak yarısını karşılıyor" gibi bir bulguyu bir kez görüp geçmek yerine, onu bir sonraki değerlendirmede kapanmış görmek istersiniz. Bu döngü, hem ASPICE olgunluğunuzu gerçekten yükseltir hem de müşteri denetimine gittiğinizde elinizde "gelişiyoruz" diyebileceğiniz somut bir iz bırakır.
Donanım disiplinini yazılıma taşımak
Otomotiv üreticileri fiziksel parçalarda köklü bir disipline sahiptir; aynı mantığı yazılıma taşımak çoğu zaman kültür meselesidir. Aşağıdaki eşleştirme, tanıdık donanım kavramlarının yazılımdaki karşılığını gösterir:
| Donanımda | Yazılımda karşılığı |
|---|---|
| Teknik resim / spesifikasyon | Yazılım gereksinimleri |
| Kontrol planı | Test planı ve test senaryoları |
| Parti / seri numarası | Yazılım sürüm numarası (versiyonlama) |
| Mühendislik değişiklik yönetimi | Konfigürasyon ve değişiklik yönetimi |
| İlk parça onayı (PPAP) | Sürüm sürüm doğrulama ve serbest bırakma |
| Tasarım FMEA | Yazılım FMEA / hata analizi |
Bu köprüyü kurmak, yazılım ekibine yabancı gelen otomotiv dilini tanıdık hale getirir. Yazılım FMEA'sının nasıl kurulacağını merak ediyorsanız, FMEA nedir yazımız iyi bir başlangıç noktasıdır.
Bir kontrol ünitesi üreticisinde en sancılı bulgu, teknik değil süreçseldi. Yazılımcı bir hata düzeltmesini gece hızlıca derleyip bir sonraki üretim partisine göndermişti; kod düzeldi ama sürüm numarası değişmemiş, hangi kartlara eski hangi kartlara yeni sürümün yüklendiği kayıtlanmamıştı. Donanımda kimsenin aklından geçmeyecek bu gevşeklik, yazılımda çok kolay oluyor. Çözüm, her serbest bırakılan sürümü bir parça gibi numaralandırıp kaydetmekti.
Sürüm ve konfigürasyon yönetimi
Gömülü yazılımın kalbinde konfigürasyon yönetimi vardır. Her yazılım sürümü benzersiz bir numarayla tanımlanmalı, hangi gereksinim ve test setiyle serbest bırakıldığı kayıtlı olmalı ve hangi donanım partisine yüklendiği izlenebilmelidir. Bu zincir kopmadan tutulduğunda, sahada bir sorun çıktığında hedefli hareket edebilirsiniz: "Şu tarih aralığında üretilen, şu sürümü taşıyan kartlar" gibi. Zincir kopuksa, tek bir hata bütün üretimi şüpheli hale getirir.
- Her sürüm için benzersiz bir kimlik ve serbest bırakma kaydı tutun.
- Gereksinim, kod ve test arasındaki izlenebilirliği koruyun.
- Hangi sürümün hangi seri numaralı ürüne yüklendiğini kaydedin.
- Değişiklikleri, donanım değişikliği kadar ciddi bir onay akışından geçirin.
Bu kayıtların dağınık olması en büyük risktir. Doküman ve sürüm kontrolünü sağlam kurmanın yollarını doküman yönetimi rehberimizde bulabilirsiniz.
Yazılımı olmayan firma bundan sorumlu mu?
Sık gelen bir soru budur. Ürününüzde gömülü yazılım yoksa, bu özel şart size uygulanmaz; basit bir mekanik parça üreticisiyseniz rahat olabilirsiniz. Ama araya bir gri alan girer: yazılım içeren bir bileşeni dışarıdan alıp kendi ürününüze montajlıyorsanız, o tedarikçinin yazılım yeteneğini yönetmek sizin sorumluluğunuza girer. Yazılımı siz yazmasanız bile izlenebilirlik zincirinin bir halkasısınızdır; müşteriniz size sorduğunda "o kısım tedarikçide" demek sizi kurtarmaz. Tedarikçi yönetimi, gömülü yazılım için de donanım için de aynı ciddiyetle işler.
Yazılım içeren bir ürünü denetleyen tetkikçi genelde tek bir izi sürer: sahadaki bir seri numarasından yola çıkıp o üründe hangi yazılım sürümünün olduğunu, o sürümün hangi gereksinim ve testlerle serbest bırakıldığını sorar. Bu zincir bir yerde kopuyorsa, ne kadar iyi kod yazılmış olursa olsun bulgu kaçınılmazdır. Denetçi kodun kalitesine değil, kodun yönetilebilirliğine bakar.
Yazılım kalitesini bütünleşik yönetmek
Gömülü yazılımın zorluğu, donanım kalite sisteminden kopuk yürütülmesidir. Yazılım ekibi kendi araçlarında çalışır, kalite ekibi kendi klasörlerinde; ikisi ancak tetkik sabahı buluşur. Bir kalite yazılımı bu iki dünyayı aynı çatı altında toplar: yazılım gereksinimlerini, sürüm serbest bırakma kayıtlarını, öz değerlendirme sonuçlarını, değişiklik onaylarını ve yazılım FMEA'sını izlenebilir biçimde bir arada tutar. Böylece "hangi araçta hangi sürüm var?" sorusuna saniyeler içinde cevap verir, tetkikte de o soğuk teri yaşamazsınız. Bu bütünleşik yaklaşımı IATF 16949 yazılımı sayfamızda inceleyebilirsiniz. Gömülü yazılım, otomotivde donanım kadar somut bir üründür; onu da bir parça gibi numaralandırıp izlediğinizde, hem tetkik hem de saha çok daha sakin geçer.