Przygotowuję dla mojej klasy slajdy na temat tego, jak powinniśmy dokumentować opracowywany sprzęt.
Chciałbym wymienić dokumenty, które powinniśmy zrobić przy budowie sprzętu. Zainspirowałem się dokumentacją oprogramowania UML, która zawiera wiele typów dokumentów dla prawie każdej sytuacji.
Z mojego doświadczenia i badań wynika, że wiele projektów ma tylko schematy, układ i zestawienie materiałów. Myślę, że powinniśmy również dodać informacje o motywach (wymaganiach), które doprowadziły nas do wyboru jednego mikrokontrolera, a nie drugiego. Istnieją również informacje dotyczące układu, których po prostu nie piszemy, jako specjalne pozycje elementów, których nie należy zmieniać.
Mówiąc to:
- Jak powinniśmy dokumentować nasz sprzęt?
- Jakie są ważne dokumenty, które chciałbyś mieć, jeśli chcesz wprowadzić pewne ulepszenia / zmiany w sprzęcie, którego nigdy nie widziałeś?
- Jak uporządkować te informacje w przejrzysty sposób?
documentation
RMA Almeida
źródło
źródło
Odpowiedzi:
Zdecydowanie zgadzam się z twoim trzecim akapitem. Oprócz oczywistych rzeczy, takich jak schematy, BOM itp., Istnieją mniej namacalne rzeczy, takie jak, jak mówisz, dlaczego wybrałeś konkretny komponent i równie ważne, dlaczego nie wybrałeś chyba bardziej oczywistego komponentu.
Teraz mogę pokazywać swój wiek tutaj, ale nadal lubię używać dziennika w twardej oprawie, aby rejestrować moje procesy myślowe i decyzje projektowe - nawet te niewłaściwe. Jeśli ktoś w przyszłości spróbuje zastąpić komponent bardziej „odpowiednim” lub przeniesie utwór na płytce drukowanej, moje notatki mogą powiedzieć mu, że już tam byłem i przypaliłem sobie palce (być może dosłownie!).
Zawsze numeruję strony i pozwalam na kilka stron z przodu jako spis treści. Możesz również udokumentować takie rzeczy, jak obliczenia rozproszenia mocy, tolerancje, czasy itp. (Ten nawyk pochodzi z moich dni w przemyśle lotniczym, gdzie prowadzenie dziennika było obowiązkowe). Oczywiście zawsze możesz umieścić te informacje w dokumencie WP, ale pozostanę przy papierze!
Opisy obwodów mogą być również odpowiednie w przypadku obwodów nietypowych (zwłaszcza analogowych). Traktowałbym je jak komentarze do oprogramowania, aby udokumentować wszelkie nieoczywiste funkcje obwodu lub komponentów. Schematy, podobnie jak oprogramowanie, powinny być w miarę możliwości „samok dokumentujące”, ale czasem to nie wystarczy.
Bardziej aktualną alternatywą, szczególnie w środowisku edukacyjnym, może być stworzenie strony internetowej projektu. Można to zorganizować jako zbiór blogów dla każdej dyscypliny - projekt sprzętu, układ pcb, oprogramowanie itp. Charakter blogu pozwoliłby autorom pokazać przepływ myśli i udokumentować bieżący postęp projektu, podczas gdy inne strony mogłyby być bardziej formalne (postęp Wykresy Gantta, wyniki testów itp.). Możesz nawet dodać minuty spotkania i listy działań. Hiperłącza ułatwiają odsyłanie, a teraz mamy MathJax, więc nawet równania projektowe są łatwe do wstawienia.
źródło
W naszej firmie powinniśmy pisać dokumenty z opisem projektu sprzętu. Są one dość proste: na początku wyjaśniasz, co powinien zrobić obwód, a następnie szczegółowo omawiasz poszczególne sekcje. Każda wartość elementu powinna być w jakiś sposób uzasadniona: jeśli masz „domyślne” rezystory podciągające lub szeregowe, należy je wspomnieć na początku w notatce (np. „Używa się podciągnięć 10K i kondensatorów obejściowych 0,1 uF, chyba że podano inaczej”) , w przeciwnym razie należy wyjaśnić wybór wartości składników. np. „Filtr RC 4,7 K i 0,1 uF (tau = 0,47 ms) stosowany do ograniczenia komponentów o wysokiej częstotliwości” lub „Multiplekser NLAS4051 stosowany do niskich wycieków - ten węzeł obwodu jest wrażliwy”.
źródło