Yerleşik C kodu güvenilirliğini artırmak için hangi araçlar veya standartlar kullanılabilir?

Genellikle anahtarlamalı mod dönüştürücüler için PIC'leri genellikle C olarak programlarım. Kodun güvenilirliğini artırmak için kullanılabilecek MISRA C gibi çeşitli statik analiz araçlarını ve standartlarını duydum . Daha fazlasını bilmek istiyorum. Bağlamım için hangi standartlar veya araçlar uygun olabilir?

Gömülü kod doğrulaması, özellikle PIC'ler gibi sınırlı kaynak bölümleriyle uğraşırken karmaşıktır. Parçanın memnry kısıtlamaları ve bu tür cihazlarda sıklıkla "gerçek zamanlı" programlama nedeniyle test durumlarında genellikle kodlama lüksüne sahip değilsiniz.

İşte yönergelerimden bazıları:

1. Bir spesifikasyon yoksa, bir spesifikasyon yazın: Bir spesifikasyona göre kod yazmıyorsanız, kodunuzun ne olması gerektiğini, geçerli girdilerin ne olduğunu, beklenen çıktıların ne olduğunu, her rutinin ne kadar sürmesi gerektiğini, ne elde edip edemeyeceğini belgeleyin clobbered, vb. - bir operasyon teorisi, akış şemaları, hiçbir şey yoktan iyidir.

2. Kodunuzu yorumlayın : Bir şeyin sizin için aşikar olması, başkası için aşikar (veya doğru) olduğu anlamına gelmez. Hem inceleme hem de kod bakımı için düz dilde yorumlar gereklidir.

3. Defansif kodlama : Yalnızca normal girdiler için kod eklemeyin. Eksik girişleri, aralık dışındaki girişleri, matematiksel taşmaları vb. Yönetin - kod tasarımınızla ne kadar çok köşe kaplarsanız, kodun konuşlandırıldığında o kadar az serbestlik derecesi olur.

4. Statik analiz araçlarını kullanın: PC-lint gibi hata araçlarının kodunuzda bulabileceği kaçınılmaz olabilir. Ciddi testler için temiz bir statik analiz çalışmasını iyi bir başlangıç ​​noktası olarak düşünün.

5. Akran değerlendirmeleri önemlidir: Kodunuz, bağımsız bir tarafça verimli bir şekilde incelenebilecek kadar temiz ve yeterince iyi belgelenmiş olmalıdır. Egonuzu kapıda kontrol edin ve yapılan herhangi bir eleştiri veya öneriyi ciddiye alın.

6. Test önemlidir: Kodun bağımsız doğrulamasının yanı sıra kendi onayınızı da yapmalısınız. Diğerleri kodunuzu hayal bile edemeyeceğiniz şekilde kırabilir. Geçerli her koşulu ve aklınıza gelebilecek her geçersiz koşulu test edin. PRNG'leri kullanın ve çöp verilerini içeri aktarın. Bir şeyleri kırmak için elinizden geleni yapın, sonra onarın ve tekrar deneyin. Şanslıysanız, kodunuzu hata ayıklama modunda çalıştırabilir ve kayıtlara ve değişkenlere göz atabilirsiniz - eğer değilse, durumunuz hakkında fikir edinmek için kurnaz olmanız ve LED'leri / dijital sinyalleri açmanız gerekir. cihaz. İhtiyacınız olan geribildirimi almak için ne gerekiyorsa yapın.

7. Kaputun altına bakın: C derleyiciniz tarafından üretilen makine koduna bakmaktan çekinmeyin. Güzel C kodunuzun yüzlerce işlem olmasa bile onlarca havaya uçtuğu yerleri (bulacaksınız?), Güvenli olması gereken bir şeyin (sadece bir kod satırı olduğu için, değil mi?) koşulları kovdu ve geçersiz kıldı. Bir şey korkunç derecede verimsiz hale gelirse, yeniden düzenleyin ve tekrar deneyin.

Bir bilgisayarda güvenilir yazılım oluşturmak için kullanılan aynı tekniklerin çoğu gömülü geliştirme için de geçerlidir. Algoritmalarınızı donanıma özgü koddan ayırmak ve bunları birim testleri, simülasyonlar, statik analiz ve Valgrind gibi araçlarla ayrı ayrı test etmek yararlıdır. Bu şekilde, yalnızca donanımda test edilen çok daha az kod olur.

C'yi terk etmem. Ada gibi diller bazı küçük garantiler sunsa da, dilin gerçekte olduğundan daha fazla vaat ettiğini düşünme tuzağına düşmek kolaydır.

MISRA-C, genel kod kalitesini artırmak ve hataları en aza indirmek için gerçekten çok kullanışlıdır. Her kuralı okuduğunuzdan ve anladığınızdan emin olun, çoğu iyi, ancak birkaçı mantıklı değil.

Burada bir uyarı. MISRA belgesi okuyucunun C dili konusunda geniş bilgiye sahip biri olduğunu varsayar. Ekibinizde bu kadar sert bir C gazisi yoksa, ancak statik bir analizör almaya karar verdikten sonra verilen her uyarıyı körü körüne takip ederseniz, okunabilirliği azaltabileceğiniz ve yanlışlıkla hatalar ekleyebileceğiniz için büyük olasılıkla daha düşük kalitede kodla sonuçlanacaktır. Bunun birçok kez olduğunu gördüm, kodu MISRA uyumluluğuna dönüştürmek önemsiz bir görev değil.

MISRA-C belgesinin uygulanabilecek iki sürümü vardır. Halen mevcut gömülü endüstri fiili standardı olan MISRA-C: 2004. Veya C99 standardını destekleyen yeni MISRA-C: 2012. Daha önce hiç MISRA-C kullanmadıysanız, ikincisini uygulamanızı tavsiye ederim.

Bununla birlikte, alet satıcılarının genellikle MISRA kontrolüne sahip olduklarını söylediklerinde MISRA-C: 2004'e başvurduklarını unutmayın (bazen eski MISRA-C: 1998 versiyonuna atıfta bulunurlar). Bildiğim kadarıyla, MISRA-C: 2012 için araç desteği hala sınırlı. Bence sadece bazı statik analizörler bunu uyguladı: Klocwork, LDRA, PRQA ve Polyspace. Daha fazla olabilir, ancak kesinlikle hangi MISRA sürümünü desteklediğini kontrol etmeniz gerekir.

Karar vermeden önce, elbette MISRA belgesini okuyarak ve nelerin gerektirdiğini görebilirsiniz. ISO standartlarına kıyasla oldukça uygun fiyatlı , misra.org'dan 10 £ karşılığında satın alınabilir .

Mathworks (MATLAB çalışanları) Polyspace adlı statik bir kod analiz aracına sahiptir .

Statik kod analizi, tiftik ve benzeri gibi, arayüzlerin (resmi bir inceleme süreci ile) ve kod kapsama analizinin dikkatli bir şekilde tanımlanmasını ve tasarlanmasını öneririm.

Ayrıca MISRA'nın yanı sıra UL1998 ve IEC 61508 standartları da dahil olmak üzere güvenlik açısından kritik kod tasarımı yönergelerine de bakmak isteyebilirsiniz.

Bu soruya tam bir cevap için, "kod güvenilirliği" hakkındaki düşünceyi bastırır ve bunun yerine "tasarım güvenilirliği" ni düşünürüm, çünkü kod tasarımın sadece son ifadesidir.

Yani, gereksinimlerle başlayın ve bunları yazın ve inceleyin. Bir gereksinim belgeniz yoksa, rastgele bir kod satırına işaret edin ve kendinize "neden bu satıra neden ihtiyaç var?" Herhangi bir kod satırı gereksinimi, "giriş 12-36VDC arasındaysa güç kaynağı 5VDC vermelidir." Bunu düşünmenin bir yolu, bu kod satırı bir gereksinime göre izlenemiyorsa, bunun doğru kod olduğunu veya gerekli olduğunu nasıl bilebilirsiniz?

Ardından, tasarımınızı doğrulayın. Tamamen kodda (örneğin, yorumlarda) varsa sorun değil, ancak kodun gerçekten ne anlama geldiğini bilmek zorlaşır. Örneğin, okuyan bir çizgi olabilir kod output = 3 * setpoint / (4 - (current * 5)); mı current == 4/5çökmesine neden olabilir, geçerli bir girdi? Bu durumda sıfıra bölünmeyi önlemek için ne yapılmalı? İşlemden tamamen kaçınıyor musunuz yoksa çıktıyı düşürüyor musunuz? Tasarım belgenizde bu tür kenar kasaların nasıl ele alınacağına dair genel bir not olması, tasarımı daha yüksek bir seviyede doğrulamayı çok daha kolay hale getirir. Bu nedenle, kod denetimi artık daha kolay çünkü kodun bu tasarımı doğru şekilde uygulayıp uygulamadığını kontrol etmek meselesi.

Bununla birlikte, kod denetimi, IDE'nizin yakalamadığı (= ID 'demek istediğinizde = = gibi) sık rastlanan hataları kontrol etmelidir. ifadeleri, olmaması gereken noktalı virgüller vb.

Bunu yazarken, yıllarca süren yazılım kalitesi eğitimini / deneyimini tek bir gönderide özetlemek gerçekten zor. Tıbbi cihazlar için kod yazıyorum ve yukarıda nasıl yaklaştığımızın son derece basitleştirilmiş bir özeti var.