Mühendislik değişikliği siparişinin yazılım eşdeğeri nedir?

Çıplak metal mikrodenetleyicide yazılım güncellemesi yapmayı düşündüğümüz bir cihazımız var. Yeni görüntü gelecekteki tüm ürünlerde programlanacaktır.

Cihazdaki bir bileşeni değiştirecek olsaydım, bir mühendislik değişikliği siparişini doldurmam gerekirdi.

Yazılımı değiştirirken eşdeğer bir endüstri prosedürü var mı?

Buna hala ECO derdim.

Ürün yazılımı fabrikada mikro programlanmışsa, bu ürün yazılımı ve özel sürümü ürün ağacında bir satır öğesi olmalıdır.
Ürün yazılımının değiştirilmesi Malzeme Listesinin değiştirilmesi anlamına gelir.
Malzeme Listesini değiştirmek bir ECO gerektirir.

Bundan sonra, bellenimin bir saha güncellemesi, sahada bir üniteye donanım için bir mod gerekiyorsa izlenecek olana benzer bir işlem izlemelidir.
Eğer buna ECO diyorsan, o zaman bu da bir ECO.

Normalde bir yazılım değişikliğine Yama veya (Yazılım Güncelleme) denir. Ve bildiğim kadarıyla (şirkete bağlı olarak) prosedürlere Yama veya Yazılım Güncelleme Prosedürü denir.

Bununla birlikte, çoğu durumda yazılım güncellemeleri, kurulumla ilgilenen özel bir uygulama çalıştırmaktan daha fazlası değildir ve gerekli tüm dönüşümler vb.

Elektronik parça değişiminin aksine, mevcut mevcut yazılımların hiçbiri normalde kaldırılmamalı veya değiştirilmemelidir, çünkü yama yazılımının kendisinin bir parçasıdır.

Ayrıca, düzeltme ekinin / yazılım güncelleştirmesinin ne zaman yüklenip yüklenemeyeceği konusunda kısıtlamalar veya koşullar olması durumunda, düzeltme ekinin kendisinde denetlenir ve yalnızca yükleme geçerli olduğunda yüklenir (veya en azından bu şekilde çalışması gerekir) ).

Bu nedenle, ilke olarak yama / yazılım güncellemesi (muhtemelen tamamlanmamıştır) gibi birçok şey yapar:

• Düzeltme ekinin / yazılım güncelleştirmesinin yüklenip yüklenemeyeceğini kontrol edin (örn. İşletim sistemi sürümleri, geçerli sürüm yüklü vb.)
• Değilse, bir mesaj gösterilir ve düzeltme eki / güncelleme durur.
• Yüklenebilirse, dönüştürülmesi gereken dosyalar yapılacaktır (bu bazen yamalanacak / güncellenecek ana uygulamanın bir parçasıdır).
• Yeni dosyalar güncellenir veya güncellenecek / yamanacak uygulamaya eklenir.
• Sürüm notları gösterilir (isteğe bağlı).
• Uygulama başlatılır (isteğe bağlı).

Normalde kullandığım terimler , değiştirilmiş gereksinimler nedeniyle değiştirilmesi gereken şeyler için Değişiklik İsteği ve hatalar nedeniyle değiştirilmesi gereken şeyler için Sorun Raporu'dur.

Bunlar toplanır ve daha sonra belirli güncelleme döngüleri için planlanır. Bir döngü yalnızca dahili ise, ona bir Kilometre Taşı denir , müşterilere dağıtıldığında buna Sürüm adı verilir .

Tipik bir zaman çizelgesi, yayınlanmadan önce, kapsamlı testlerden geçen Yayın Adayı olarak adlandırılan birkaç kilometre taşına sahiptir ve orada bulunan hatalar, yeterince önemli olduklarında bir sonraki aşama için tekrar planlanan başka Sorun Raporları veya değilse daha sonraki bir sürüm oluşturur.

Ayrıca, daha az hatanın ortaya çıkması ümidiyle, müşteri şikayetlerine yanıt olarak sadece belirli PR'ları ele alan ve daha fazla değişiklik yapılmayan ayrı bir sürümle bir Şube oluşturmak da mümkündür . Bu genellikle yalnızca güncelleme çabası yeterince düşükse yapılır (örneğin, güncellemeler sadece üzerinde belirli bir ada sahip bir dosya içeren bir USB çubuğuna takılarak kurulabilir).

Kısa cevap: Yazılım versiyonlama sistemine entegre edilmiştir.

Uzun cevap:

Yazılım, donanımdan çok daha hızlı değişme eğilimindedir. Genellikle yazılım, popüler Git gibi bir çeşit sürüm kontrol sistemi (VCS) kullanır. Çalıştığım çoğu yazılım şirketi, yazılımdaki değişiklikleri izlemek için bir VCS kullanıyor ve her biri değişikliğin ardındaki mantığı açıklıyor. Bazıları, bilinen hataları, geliştirmeleri vb. İzleyen bir sorun izleyici de kullanır. Genellikle bir dalda gelişimin gerçekleştiği bir süreç vardır, daha sonra bu gelişme bir "ana" (serbest bırakma) dalında birleştirilmeden önce test edilir. Bu, yazılım geliştirmedeki yüksek değişiklik sıklığı ve donanımdaki yavaş tempo için çok daha verimli olma eğilimindedir. Bunun özel uygulaması ve süreci şirketten şirkete değişir ve genellikle KG amaçları için bir standarttan (ISO9001, AS9100D, vb.) Etkilenir.

Bir örnek:

1. Bir değişiklik yapmaya karar verdiniz.

2. Sorun izleyicide bir sorun oluşturursunuz.

3. Sorunu çözmek için bir şube oluşturursunuz.
4. Bazı yazılım değişiklikleri yaparsınız.
5. Değişikliklerinizin şirket politikasına göre gözden geçirilmesini sağlayın
6. Bir çekme isteği yayınlar ve geliştirici dalında yeniden birleştirilirsiniz.
7. Sorunu kapattınız.

Düzgün çalışan bir endüstri ayarında, mikroya flaşlanacak bellenimin kendisi bir parçadır ve söz konusu yürütülebilir dosya (hex dosyası veya her neyse) için bir parça numarasına sahiptir. Ürün yazılımını değiştirmek istiyorsanız, ürün ağacında (malzeme listesi) yapılan bir değişikliktir. Ve bunun bir çip değiştirmek istediğiniz gibi bir ECO'ya ihtiyacı var.

Gerçekten bu kadar basit.

Bunun bir sonucu var. Senin firmware yoksa değil bir parça numarası var ve yok edilir dolayısıyla BOM listelenen ve değil kontrollü, sonra kalite süreci muhtemelen iyileştirilmesi gerekiyor. ISO-9001 veya benzeri bir şeyle karşılaşmanız gerekiyorsa, bu işleminizde düzeltilmesi gereken kesin bir boşluktur.

Yazılım güncellemeleri yama olarak adlandırılır veya "yazılım güncellemesi" olarak adlandırılır. Yazılım mühendislerine daima ünitenin "en son sürüme" güncellenip güncellenmediğini soruyorum.

İdeal olarak versiyonlama paydaşlar tarafından "imzalanır" ve üretime girmeden önce test edilir, ancak çoğu zaman bu uygulama çoğu zaman gerçekleşmez.