Я создаю несколько слайдов для моего класса о том, как мы должны документировать оборудование, которое мы разрабатываем.
Я хотел бы перечислить документы, которые мы должны сделать при сборке оборудования. Меня вдохновила документация по программному обеспечению UML, которая содержит множество типов документов практически для любой ситуации.
Судя по моему опыту и исследованиям, многие проекты имеют только схемы, макет и спецификацию. Я думаю, что мы должны также добавить информацию о мотиве (требованиях), который приводит нас к выбору одного микроконтроллера, а не другого. Есть также некоторая информация относительно компоновки, которую мы просто не пишем, как специальная позиция компонента, которая не должна изменяться.
Что говорится:
- Как мы должны документировать наше оборудование?
- Какой важный документ вы хотели бы иметь, если вам нужно внести какие-то улучшения / изменения в другое оборудование, которое вы никогда не видели?
- Как организовать эту информацию в понятной форме?
documentation
RMAAlmeida
источник
источник
Ответы:
Я полностью согласен с вашим третьим абзацем. Помимо очевидных вещей, таких как схемы, спецификации и т. Д., Есть и менее ощутимые вещи, такие как, как вы говорите, почему вы выбрали определенный компонент и, что не менее важно, почему вы не выбрали, возможно, более очевидный компонент.
Сейчас я, возможно, показываю свой возраст здесь, но мне все еще нравится использовать журнал в твердом переплете для записи моих мыслительных процессов и проектных решений - даже неправильных. Если кто-то в будущем попытается заменить компонент более «подходящим» или переместит дорожку на печатной плате, мои заметки могут сказать им, что я уже был там и сжечь пальцы (возможно, буквально!).
Я всегда нумерую страницы и допускаю несколько страниц впереди в качестве оглавления. Вы также можете задокументировать такие вещи, как расчеты рассеиваемой мощности, допуски, время и т. Д. (Эта привычка возникла в мои дни в аэрокосмической промышленности, где ведение журнала учета было обязательным). Конечно, вы всегда можете поместить эту информацию в документ WP, но я буду придерживаться статьи!
Описания цепей также могут быть уместны в случае необычных (особенно аналоговых) цепей. Я бы отнесся к ним как к программным комментариям, чтобы документировать любые неочевидные схемы или функции компонентов. Схемы, как и программное обеспечение, должны насколько возможно «самодокументироваться», но иногда этого недостаточно.
Более современной альтернативой, особенно в образовательной среде, может быть создание веб-сайта проекта. Это может быть организовано как набор блогов для каждой дисциплины - проектирование аппаратного обеспечения, макет печатной платы, программное обеспечение и т. Д. Природа блога позволила бы участникам демонстрировать свои мысли и документировать текущее продвижение проекта, в то время как другие страницы могут быть более формальными (прогресс Диаграммы Ганта, результаты испытаний и т. Д.). Вы даже можете добавить протоколы собраний и списки действий. Гиперссылки упрощают перекрестные ссылки, и теперь у нас есть MathJax, так что даже уравнения проектирования просты для вставки.
источник
В нашей компании мы должны написать документы с описанием дизайна оборудования. Это довольно просто: сначала вы объясняете, что должна делать схема, а затем углубляетесь в каждом разделе. Каждое значение компонента должно быть обосновано каким-либо образом: если у вас есть резисторы «по умолчанию» или последовательные резисторы, они должны быть упомянуты в примечании в начале (например, «10 кОм и 0,1 мкФ, конденсаторы байпаса используются, если не указано иное») В противном случае выбор значений компонентов должен быть объяснен. Например, «RC-фильтр 4,7 К и 0,1 мкФ (тау = 0,47 мсек) используется для ограничения высокочастотных компонентов» или «Мультиплексор NLAS4051 используется для малой утечки - этот узел цепи чувствителен».
источник