Jak dokumentujesz swoje decyzje dotyczące projektowania sprzętu?

Jak dokumentujesz swoje decyzje dotyczące sprzętu na etapie projektowania? Jak uniknąć zadawania sobie następujących pytań podczas przeglądania projektu sprzętu wykonanego w przeszłości:

• Dlaczego wybrano ten komponent?
• Dlaczego / jak wybrałem te konkretne parametry dla tego komponentu?
• Co robi ta część obwodu?
• Jakie jest rozpraszanie mocy przez ten komponent?
• Jaki jest całkowity pobór mocy tego obwodu?
• Czy mogę wymienić ten komponent na inny? Czy są jakieś równoważne komponenty do tego komponentu? itp.

Jaki jest dobry sposób na udokumentowanie swoich decyzji i obliczeń podczas fazy projektowania obwodu? Jak uzyskać odpowiedzi na powyższe pytania bez ponownego przeglądania setek stron arkusza danych?

Jednym ze sposobów, w jaki mogłem wymyślić, jest dodawanie notatek do plików schematów (jeśli obsługuje je EDA), ale nie chciałbym zaśmiecać schematu zbyt dużą ilością informacji.

Osobiście wybieram staroświecką trasę: mam notatnik do projektowania, w którym zapisuję absolutnie wszystko o decyzjach projektowych, które podejmuję. W szczególności wybór komponentów i wartości, obliczenia prądu, obliczenia zasilacza, wszystko. Dokumentuję również decyzje dotyczące oprogramowania / oprogramowania układowego oraz uwagi dotyczące czasu i wykorzystania zasobów.

Każdy notebook ma stronę z treścią, która odnosi się do określonej części projektu (zasilacz itp.), A wszystkie strony są ponumerowane.

Wiele razy zastanawiałem się nad przejściem na technologię cyfrową, ale fajnie jest mieć ze sobą mój notatnik, gdy pracuję, a pisanie formuł cyfrowych jest dość niewygodne. O wiele łatwiej jest pisać obliczenia ręcznie.

Przygotowując specyfikację lub formalną dokumentację do projektu płytki, zwykle odnoszę się do mojego notatnika jako odświeżenia tego, co zrobiłem (lub piszę jednocześnie dokumentację cyfrową). Chociaż może się wydawać, że robię to samo dwa razy, stwierdzam, że moje zeszyty są dla mnie prawie w całości obliczeniami i wyjaśnieniami, a dokumentacja jest znacznie mniej szczegółowa, a dla innych bardziej formalna i objaśniająca. W związku z tym często nie piszę tego samego dwa razy.

Możesz wrócić i zaktualizować specyfikację projektu o te informacje. Lub weź specyfikację i utwórz specyfikację niższego poziomu, w której bardziej szczegółowo opisujesz, co zamierzasz zrobić i dlaczego, najlepiej przed rozpoczęciem schematów :). Następnie aktualizuj i postępuj zgodnie ze schematami.

Odpowiedzi na pytania poniżej: Cóż, zwykle robimy to od wymagań marketingowych, a następnie może formalnej odpowiedzi inżynierskiej lub po prostu nieformalnej dyskusji. Po tym następuje MRD (dokument wymagań marketingowych), słowem, przy użyciu naszego szablonu. Obejmuje to wymagania, analizę konkurencji, wielkość rynku, możliwości, szacunkowe koszty rozwoju itp. Zwykle jest to napisane przez osobę zajmującą się marketingiem (lub kogoś powyżej mojej kategorii płac).

Po nim następuje PRD (dokument wymagań produktu) napisany zwykle przez inżynierów, również w szablonie słów. Opisuje to bardziej szczegółowo techniczne, co zrobi produkt, jakie elementy są wymagane, a na wysokim poziomie, jak każdy z nich będzie działał. Często uwzględnimy tutaj docelową wydajność, cenę, moc, rozmiar i inne wskaźniki.

Następnie podano szczegółowe specyfikacje funkcjonalne dla każdej sekcji. Niektóre prace projektowe są tu właściwie wykonywane na długo przed wprowadzeniem ich do schematu. Na przykład obliczona zostanie moc, zostaną wybrane części i przeprowadzone zostaną liczne badania. To miejsce, w którym udokumentowalibyśmy wszelkie nieoczywiste decyzje projektowe.

W końcu przejdziemy do schematów, które w tym momencie są łatwe, ponieważ wiele trudnych prac projektowych wykonano na etapie specyfikacji. Moim zdaniem należy to zrobić :) Jeśli coś zmieni się na etapie schematu, na przykład stwierdzimy, że coś nie zadziała lub po korytarzu wybiegnie marketingowiec, mówiąc, że teraz musi być czerwony zamiast niebieskiego, wtedy wróci i zaktualizuje specyfikacje.

Wszystkie specyfikacje, PRD, MRD są przechowywane w SVN z linkami do dokumentów na wewnętrznej wiki. Zmiana specyfikacji spowoduje aktualizację SVN i powiadomienie zainteresowanych stron. Oczywiście możesz po prostu trzymać go ręcznie w folderze współdzielonym.

To mniej więcej mój proces, wydaje mi się, że możesz chcieć udokumentować każdą drobną decyzję dotyczącą projektu i zdecydowanie tego nie robimy. Nie mówiąc, że nie powinieneś, widziałem, gdzie byłoby to pomocne. Chyba zwykle cały czas dokumentujemy, jak, a nie dlaczego.

Ok, może powinienem był również odpowiedzieć na każde pytanie :)

Jeśli robisz obliczenia, może w Excelu? Lub na papierze i uważasz, że wyniki i metoda są ważne dla zrozumienia i zaprojektowania obwodu, to powinieneś je uwzględnić w odpowiedniej sekcji specyfikacji projektowej. Nawet jeśli oznacza to zrobienie zdjęcia rysunku ręki :)

Dlaczego wybrano ten komponent? Myślę, że funkcjonalna specyfikacja jest dobrym miejscem do tego, nie trzeba zwariować, ale tylko prosta linia lub dwie o tym, jakie były jej zalety. Zarezerwowałbym to na krytyczne elementy, nie sądzę, że chcesz opisać, dlaczego wybrałeś na przykład rezystor podciągający.

Dlaczego / jak wybrałem te konkretne parametry dla tego komponentu? Połącz to z powyższym.

Co robi ta część obwodu? Byłoby to częścią twojej specyfikacji funkcjonalnej, jeśli obwód jest wystarczająco ważny, aby uzasadnić to pytanie, powinien mieć własną sekcję specyfikacji.

Jakie jest rozpraszanie mocy przez ten komponent? Jeśli mówisz o zasilaczu, umieść to w sekcji zasilania, również chcę to zauważyć na schematach. Naprawdę, chociaż wszystkie moje części pochodzą z bazy danych, a schemat jest bezpośrednio z nimi powiązany, dzięki czemu możemy łatwo zobaczyć parametry, arkusz danych itp. Ale jeśli masz tylko wydruk, miło jest to wiedzieć.

Jaki jest całkowity pobór mocy tego obwodu? Myślę, że należy to do sekcji zasilania w specyfikacji.

Czy mogę wymienić ten komponent na inny? Czy są jakieś równoważne komponenty do tego komponentu? itp. Myślę, że należy to do twojego BOM lub dowolnego innego procesu stosowanego do produkcji. Części alternatywne mają ułatwić pozyskiwanie. Ponownie dla nas to wszystko pochodzi z bazy danych części.

Robię dużo szybkich projektów i muszę powiedzieć: adnotacja na schemacie jest zdecydowanie najwygodniejsza. Rzadko zdarza się, że którykolwiek z moich projektów ma więcej niż 2 lub 3 arkusze A4, więc liczba decyzji dotyczących projektu jest ograniczona. Wiele decyzji projektowych odbywa się prawie automatycznie; Nie muszę podawać powodów każdej części. Tylko jedna lub dwie główne części i może jakiś filtr lub czujnik pasywny. Reszta jest natychmiast oczywista dla każdego doświadczonego inżyniera.

Co do twojego ostatniego pytania: części alternatywne zasadniczo nie są decyzją projektową, ale decyzją dotyczącą zaopatrzenia, i jako taka jest częścią twojego procesu pozyskiwania. W moim przypadku części alternatywne są we właściwościach części i są pozyskiwane automatycznie, jeśli zapasy wyczerpią się na części podstawowej lub źródle.

W przypadku większych projektów i projektu systemu zwykle używam Dokumentów Google z szablonem dokumentu projektowego.

W podsumowaniu; Osobiście uważam, że zwarty przepływ pracy ostatecznie się opłaci. Posiadanie wielu oddzielnych plików z informacjami projektowymi (oddzielny projekt systemu, dokumenty decyzji projektowych, dokumenty źródłowe, wszystkie oddzielone od podstawowych plików schematu i układu) powoduje wiele (mentalnych) bałaganu i wymaga przełączania kontekstu za każdym razem, gdy chcesz przejrzeć projekt decyzja. Posiadanie wszystkiego w jednym miejscu działa dobrze. Jeśli twój schemat zaczyna wyglądać na zagracony, nie stanowi to problemu w tym przepływie pracy, ale raczej oznacza, że ​​prawdopodobnie powinieneś lepiej podzielić projekt na części, użyć więcej arkuszy lub użyć większych arkuszy.

W przypadku wielu moich mniejszych projektów generalnie umieszczam prostą zieloną etykietę i obramowanie wokół obwodów. W przypadku większych projektów niektóre oprogramowanie eCAD pozwala budować od schematu blokowego w dół, gdzie każdy arkusz dodatkowo opisuje pojedynczy blok. Sztuka rozkładania każdego problemu i zarządzania kompromisami (to inżynieria IMHO). Tam, gdzie jest pewna analiza wyboru komponentów, takich jak filtrowanie analogowe, zanotuję częstotliwość odcięcia i typ filtra (np. Filtr dolnoprzepustowy (f_c = 100Hz))

Typowe bloki, z którymi się spotykam, obejmują:

• Zarządzanie energią (regulatory napięcia, zabezpieczenie przed odwrotną polaryzacją, diody TVS, wyłącznik zasilania, osłony bypassu itp.)
• MCU (mikrokontroler, programowanie nagłówka lub padów, zaślepki układu obejściowego)
• Wskaźniki (np. Diody LED, przewód EL, wyświetlacz 7-segmentowy, silnik wibracyjny)
• Wykrywanie określonej funkcji (np. Wykrywanie prądu, wyczuwanie dotykowe, GSR, aktywność, wykrywanie otoczenia itp.)
• Debug Comms (ferrytowy koralik, USB, I2C, UART, SPI, jakiś sposób na uzyskanie informacji)
• Radio (wszystkie elementy obsługi wielu radiotelefonów)
• Wideo (wszystkie komponenty pomocnicze i układy do kamery)
• Pamięć zewnętrzna (np. Zewnętrzna pamięć flash, układ EEPROM do przechowywania ustawień itp.)
• Każda inna funkcja unikalna dla twojego projektu

Dzięki tym podblokom wyraźnie zorganizowanym i oznaczonym, mogę zużyć schemat zwykle w mniej niż kilka minut.

Prowadzę notatnik projektowy i dokładnie dokumentuję potrzeby / potrzeby. W przypadku najwcześniejszych prototypów dokonam wyboru części, notując wszystkie prawdziwe decyzje. Do kolejnych zmian używam dość formalnego procesu FMEA, dokumentującego, która potrzeba nie jest zaspokojona, aby uzasadnić zmianę - ponieważ oczywiście, jeśli nie ma niezaspokojonej potrzeby, nie ma potrzeby zmiany!

Jeśli jestem wystarczająco rygorystyczny, mogę wyśledzić każdą zmianę projektu (sprzęt, oprogramowanie, mechanika) według potrzeb.

Wszystkie wersje wszystkich rzeczy są śledzone przy użyciu subversion.

Może to być istotny element pliku historii projektu, który jest koniecznością dla FDA.

Często korzystałem z keynote (możesz także wybrać PowerPoint). Ma to tę zaletę, że pozwala na stosowanie ograniczeń ekranowych w oprogramowaniu symulacyjnym, takim jak SPICE GUI i tym podobne.

Naprawdę kluczowa jest dla mnie umiejętność upuszczania fragmentów z arkuszy danych i oznaczania ich, aby pokazać względne znaczenie w moich decyzjach projektowych. Mogę również dołączyć zdjęcia wczesnych obwodów drukowanych lub tablic rejestracyjnych oraz linki do artykułów, których użyłem przy wyborze projektu.

Uważam też, że zwykle chcę robić matematykę i rysunki ołówkiem na papierze. Więc robię zdjęcie moim telefonem i upuszczam je w dyskusji bez ponownego wpisywania. Czasami dla krótkich równań mogę użyć LaTeXa i wrzucić to.

Mogę również dołączyć wykresy sporządzone przez oprogramowanie naukowe, takie jak oktawa.

W dzisiejszych czasach, szczególnie w przypadku zadań wymagających dużej mocy obliczeniowej, mogę wykonać niektóre z tych prac w notebookach IPython, ale nie zrobiłem tego specjalnie w projektowaniu obwodów, tylko w obliczeniach fizycznych.

Wreszcie, Keynotes / Powerpoints można łatwo upodobnić dla innych i wyeksportować jako pdf do dystrybucji wśród osób nie / mniej technicznych.

Umieść uwagi techniczne na schematach i w razie potrzeby utwórz więcej arkuszy. Zawsze umieszczam uwagi techniczne na wszystkich moich schematach, ponieważ w moim świecie może być konieczne ponowne odwiedzanie 1/2 upieczonych projektów przez pewien czas, a następnie ponowne umieszczanie ich na tylnym palniku podczas wybierania innego projektu; bardzo płynny przepływ projektowy. Te notatki EE pomagają mi i innym przyzwyczaić się do założeń projektowych przy niewielkim wysiłku. Używam również różnych kolorów tekstu / grafiki, aby wskazać ważność lub kontekst. Przykład poniżej ...