Donanım tasarım kararlarınızı nasıl belgeliyorsunuz?

Donanım kararlarınızı tasarım aşamasında nasıl belgeliyorsunuz? Geçmişte yapmış olduğunuz bir donanım tasarımını gözden geçirirken kendinize aşağıdaki soruları sormaktan nasıl kaçınılırsınız:

• Neden bu bileşeni seçtiniz?
• Bu bileşen için bu özel parametreleri neden / nasıl seçtim?
• Devrenin bu kısmı ne işe yarıyor?
• Bu bileşen üzerinden güç tüketimi nedir?
• Bu devrenin toplam güç tüketimi nedir?
• Bu bileşeni diğer biriyle değiştirebilir miyim? Bu bileşene eşdeğer bileşenler var mı? vb.

Bir devrenin tasarım aşamasında kararlarınızı ve hesaplarınızı belgelemek için iyi bir yol nedir? Yüzlerce veri sayfası sayfasına tekrar gitmeden yukarıdaki soruların yanıtlarını nasıl alabilirim?

Düşünebilmemin bir yolu şematik dosyalara notlar eklemektir (EDA'nız destekliyorsa), ancak şemayı çok fazla bilgiyle karıştırmak istemem.

Kişisel olarak eski moda rotaya gidiyorum: Yaptığım tasarım kararları hakkında kesinlikle her şeyi yazdığım bir tasarım defterim var. Özellikle bileşen ve değer seçimleri, cari hesaplamalar, güç kaynağı hesaplamaları, her şey. Ayrıca zamanlama ve kaynak kullanımı ile ilgili yazılım / üretici yazılımı kararlarını ve notlarını da belgeliyorum.

Her dizüstü bilgisayarın tasarımın belirli bir bölümüne (güç kaynağı vb.) Atıfta bulunmak için bir içerik sayfası vardır ve tüm sayfalar numaralandırılmıştır.

Birkaç kez dijital olmayı düşünmüştüm, ancak çalışırken bilgisayarımın önümde durması çok hoş ve dijital olarak formülleri yazarken oldukça garipti. Hesaplamaları elle yazmak çok daha kolay.

Bir tahta tasarımı için bir teknik özellik ya da resmi belge hazırlarken, genellikle dizüstü bilgisayarıma yaptığım şeyin tazeleyicisi olarak geri dönerim (ya da aynı anda dijital belgeleri yazarım). Bu aynı şeyi iki kez yapıyorum gibi görünse de, defterlerimin neredeyse tamamen kendim için tüm hesaplama ve açıklamaları buluyorum, dokümantasyonun daha az ayrıntılı ve diğerleri için daha resmi ve açıklayıcı olduğu yerlerde. Gibi, sık sık aynı şeyi iki kez yazıyorum bulmuyorum.

Geri dönüp tasarım özelliklerini bu bilgilerle güncelleyebilirsiniz. Ya da spesifikasyonu alın ve ne yapacağınızı ve neden, şemalara başlamadan önce ideal olarak :) daha ayrıntılı olarak tanımladığınız bir alt seviye spesifikasyon oluşturun. Daha sonra ilerledikçe güncelleyin ve şemalarla arşivleyin.

Aşağıdaki soruları cevaplama: Genelde yaptığımız şey pazarlama gereksinimlerine başlamak, daha sonra belki resmi bir mühendislik tepkisi ya da sadece resmi olmayan tartışmalardır. Bunu, şablonumuzu kullanan bir MRD (pazarlama gereksinimleri belgesi) takip eder. Bu, gereksinimleri, rekabet analizini, pazar büyüklüğünü, fırsatı, tahmini geliştirme maliyetini vb. İçerir. Genellikle bu, bir pazarlama uzmanı (veya ödeme derecemin üzerinde bir kişi) tarafından yazılır.

Bunu, genellikle bir kelime şablonunda, mühendislik tarafından yazılan PRD (ürün gereksinimleri belgesi) izler. Bu, ürünün ne yapacağını, hangi parçaların gerekli olduğunu ve her birinin nasıl çalışacağını yüksek düzeyde ayrıntılı olarak açıklar. Genellikle hedef performans, fiyat, güç, boyut ve diğer ölçümleri buraya dahil edeceğiz.

Bunu bölümlerin her biri için ayrıntılı fonksiyonel özellikler izler. Bazı tasarım çalışmaları burada şematik olarak gösterilmeden önce iyi bir şekilde yapılıyor. Örneğin, güç hesaplanacak, parçalar seçilecek ve çok fazla araştırma yapılacaktır. Açıkça görülmeyen tasarım kararlarını belgeleyeceğimiz yer burası.

Sonunda, bu noktada kolay olan şemaya geçeceğiz, çünkü şartname aşamasında zor tasarım çalışmalarının çoğu yapıldı. Benim görüşüme göre yapılması gerekenler :) Eğer şematik aşamada bir şeyler değişirse, örneğin bir şeyin işe yaramayacağını anlarız ya da bir pazarlama çalışanı salondan aşağıya mavi yerine kırmızı olması gerektiğini söyler. geri dönecek ve özellikleri güncelleyecektir.

Tüm özellikler, PRD, MRD dahili wiki'deki dokümanlar ile bağlantılı olarak SVN'de tutulur. Spesifikasyon değişikliği, SVN’de bir güncelleme ve ilgililere bildirimde bulunma ile sonuçlanacaktır. Elbette bir yerde paylaşılan bir klasörde manuel olarak tutabilirsiniz.

Bu benim sürecim az ya da çok, bir tasarım hakkında verilen her küçük kararı belgelemek isteyebileceğinize inanıyorum ve kesinlikle bunu yapmıyoruz. Yapmamalısın demiyorum, nerede yardımcı olacağını görebiliyorum. Sanırım genellikle neden her zaman neden olduğunu ve neden olmadığını belgeliyoruz.

Tamam, belki de her soruyu cevaplamalıydım :)

Hesaplamalar yapıyorsanız, belki de excel olarak? Ya da kâğıt üzerinde, sonuçların ve yöntemin, devrenizin anlaşılması ve tasarımı için önemli olduğunu düşünüyorsunuz, o zaman tasarım şartnamesinin uygun bölümüne dahil etmelisiniz. Bu, el çizimi resminizi çekmek olsa bile :)

Neden bu bileşeni seçtiniz? İşlevsel özelliklerin bunun için iyi bir yer olduğunu düşünüyorum, çıldırmaya gerek yok ama avantajları hakkında basit bir satır. Bunu kritik bileşenler için ayırırdım, örneğin neden bir direnç direnci seçtiğinizi açıklamak istemezsiniz.

Bu bileşen için bu özel parametreleri neden / nasıl seçtim? Bunu yukarıdaki ile birleştirin.

Devrenin bu kısmı ne işe yarıyor? Bu, işlevsel spesifikasyonunuzun bir parçası olacaktır, eğer devre bu soruyu garanti etmek için yeterince önemliyse, spesifikasyonun kendi bölümüne sahip olması gerekir.

Bu bileşen üzerinden güç tüketimi nedir? Eğer güç kaynağını konuşuyorsanız, bunu güç bölümüne koyun, ayrıca şemayı da not etmek isterim. Aslında bütün bölümlerim bir veritabanından gelse ve şematik doğrudan bunlara bağlı olsa da, parametreleri, veri sayfalarını vb. Kolayca görebiliyoruz.

Bu devrenin toplam güç tüketimi nedir? Bence bu şartnamenin güç kaynağı bölümüne ait.

Bu bileşeni diğer biriyle değiştirebilir miyim? Bu bileşene eşdeğer bileşenler var mı? vb Bence Bu BOM aittir veya ne olursa olsun üretim için kullanmak işler. Alternatif parçalar kaynak yapmayı kolaylaştırır. Yine bizim için bunların hepsi bir parça veri tabanından geliyor.

Çok hızlı bir şekilde tasarım yapıyorum ve şunu söylemeliyim: şematik açıklama, en uygun şeydir. Tasarımlarımın herhangi birinin 2 veya 3 A4 sayfasından fazla olması nadirdir, bu nedenle tasarım kararlarının miktarı sınırlıdır. Birçok tasarım kararı hemen hemen otomatiktir; Her bölüm için nedenler listelememe gerek yok. Sadece bir veya iki ana parça ve belki bir kısmı pasif boyuta filtre veya algılayıcı. Gerisi, deneyimli tasarım mühendisleri tarafından hemen anlaşılır.

Son sorunuza gelince: alternatif parçalar genellikle bir tasarım kararı değil bir satın alma kararıdır ve bu nedenle kaynak iş akışınızın bir parçasıdır. Benim durumumda, alternatif parçalar benim parça özelliklerimde ve ana parça veya kaynakta stok tükenirse otomatik olarak kaynaklanıyor.

Daha büyük tasarımlar ve sistem tasarımı için Google Dokümanlar'ı bir tasarım belgesi şablonuyla kullanma eğilimindeyim.

Özetle; Ben şahsen kompakt bir iş akışının sonuçta karşılığını alacağı kanısındayım. Tasarım bilgisine sahip (ayrı sistem tasarımı, tasarım karar belgeleri, kaynak belgeleri, hepsi temel şematik ve düzen dosyalarınızdan ayrı olarak) birçok ayrı dosyaya sahip olmak, bir çok (zihinsel) karmaşaya neden olur ve her bir tasarımı gözden geçirmek istediğinizde içerik değiştirmeyi gerektirir karar. Her şeyin tek bir yerde olması iyi çalışıyor. Eğer şemanız dağınık görünmeye başlarsa, bu iş akışında bir sorun değildir, bunun yerine tasarımınızı daha iyi bölümlere ayırmanız, daha fazla sayfa kullanmanız veya daha büyük sayfalar kullanmanız gerektiği anlamına gelir.

Küçük projelerimin çoğu için, genellikle alt devrelerin etrafına basit bir yeşil etiket ve kenarlık yerleştiriyorum. Daha büyük projeler için, bazı eCAD yazılımları aşağıda her bir sayfanın tek bir blok daha tanımladığı bir blok diyagramdan oluşturmanıza olanak sağlar. Herhangi bir sorunun ayrıştırılması ve değişimlerin yönetilmesi için bir sanat var (bu IMHO'yu tasarlıyor). Analog filtreleme gibi bileşenlerin seçimi için açıkça bazı analizlerin olduğu yerlerde, kesme frekansını ve filtre tipini not edeceğim (örn. Düşük Geçişli Filtre (f_c = 100Hz))

Zamanla karşılaştığım ve tekrar kullandığım ortak bloklar:

• Güç Yönetimi (voltaj regülatörleri, ters kutup koruması, TVS diyotları, güç düğmesi, bypass kapakları, vb.)
• MCU (mikrodenetleyici, programlama başlığı veya pedleri, talaş atlatma kapakları)
• Göstergeler (örneğin, LED'ler, EL teli, 7 kademeli ekran, vib motor)
• Belirli bir özelliğe yönelik algılama (örneğin, Geçerli Algılama, Dokunmatik Algılama, GSR, Etkinlik, Çevresel Algılama, vb.)
• Hata Ayıklama İletişimi (ferrit boncuk, USB, I2C, UART, SPI, bilgi almanın bir yolu)
• Radyo (birçok radyo için tüm destek bileşenleri)
• Video (kamera için tüm destek bileşenleri ve yongalar)
• Harici Depolama (örneğin, Harici Flaş, ayarları saklamak için EEPROM yongası, vb.)
• Tasarımınıza özgü diğer özellikler

Bu alt bloklar açıkça düzenlenmiş ve etiketlenmiş olarak, genellikle birkaç dakikadan daha az bir sürede şematik olarak tüketebilirim.

Dizayn defterim var ve ihtiyaçları / istekleri dikkatlice belgeliyorum. İlk prototipler için, tüm gerçek kararları not alarak bölüm seçiminden geçeceğim. Daha sonraki değişiklikler için, bir değişikliği gerekçelendirmek için hangi ihtiyacın karşılanmadığını belgeleyen oldukça resmi bir FMEA süreci kullanıyorum - çünkü açık bir şekilde, karşılanmamış bir ihtiyaç yoksa, bir değişikliğe gerek yok!

Bu konuda yeterince titiz davranırsam, ihtiyacım olan her tasarım değişikliğini (donanım, yazılım, mekanik) izleyebilirim.

Her şeyin tüm sürümleri, alt sürüm kullanılarak izlenir.

Bu, FDA için şart olan bir Tasarım Geçmişi Dosyasının önemli bir bileşeni olabilir.

Ben sık sık açılış konuşmasını kullandım (PowerPoint kullanmayı da seçebilirsiniz). Bu, SPICE GUI'leri ve benzeri simülasyon yazılımlarının ekran kapaklarına izin verme avantajına sahiptir.

Gerçekten benim için kilit nokta, parçacıkları veri sayfalarından çıkarma ve onları işaretleme yeteneği, böylece tasarım kararlarımdaki göreceli önemlilik ortaya çıkıyor. Ayrıca eski devre kartlarının veya breadboardların fotoğraflarını ve tasarım seçiminde kullandığım makalelere linkleri de ekleyebilirim.

Ayrıca kağıt üzerinde kalem kullanarak matematik ve çizimler yapma eğiliminde olduğumu da buluyorum. Bu yüzden telefonumla bir fotoğraf çekip tekrar yazmaya gerek kalmadan açacağım. Bazen kısa denklemler için LaTeX kullanabilir ve onu bırakabilirim.

Ayrıca oktav gibi bilimsel yazılımların çizdiği grafikleri de ekleyebilirim.

Günümüzde, özellikle yoğun hesaplama gerektiren işler için bu çalışmanın bir kısmını IPython notebooklarda yapmayı seçebilirim, ancak bunu özellikle fizik hesaplamaları için devre tasarımları için yapmadım.

Son olarak, Keynotlar / Powerpoint'lerin diğerleri için güzelleştirilmesi ve teknik olmayan / az teknik kişilere dağıtım için pdf olarak dışa aktarılması kolaydır.

Mühendislik notlarını şemaya yerleştirin ve gerekirse daha fazla sayfa oluşturun. Her zaman tüm şemalarımın üzerine mühendislik notları yerleştiririm çünkü dünyamda bir süre boyunca 1/2 pişmiş tasarımları tekrar ziyaret etmek zorunda kalacağım, daha sonra başka bir tasarım alırken tekrar ocakta koymak zorunda kalabilirim; çok akışkan tasarım akışı. Bu EE notları bana ve diğerlerinin tasarım amacını çok az bir çaba ile tekrar kucaklamasına yardımcı oluyor. Önemini veya içeriğini belirtmek için farklı metin / grafik renkleri de kullanıyorum. Aşağıdaki örnek ...