Як зробити апаратну документацію?

Я будую слайди для свого класу про те, як ми повинні документувати обладнання, яке ми розробляємо.

Я хотів би перерахувати документи, які ми повинні зробити при складанні певного обладнання. Мене надихнуло програмне забезпечення програмного забезпечення UML, яке містить безліч типів документів майже для кожної ситуації.

З мого досвіду та досліджень, багато проектів мають лише схеми, макет та законопроект матеріалів. Я думаю, що ми також повинні додати інформацію про мотив (вимоги), які призводять нас до вибору одного мікроконтролера, а не іншого. Існує також деяка інформація щодо макета, яку ми просто не пишемо, як особливе положення компонента, яке не слід змінювати.

Це було сказано:

• Як ми повинні документувати наше обладнання?
• Який важливий документ ви хотіли мати, якщо вам потрібно внести деякі вдосконалення / зміни на інше обладнання, якого ви ніколи не бачили?
• Як чітко організувати цю інформацію?

Я повністю погоджуюся з вашим третім пунктом. Крім очевидних речей, таких як схеми, BOMs тощо, є і менш відчутні речі, як, як ви кажете, чому ви вибрали певний компонент і так само важливо, чому ви не вибрали, можливо, більш очевидний компонент.

Зараз я, можливо, показую свій вік тут, але я все одно люблю використовувати журнал журналу, що утримується в твердій обкладинці, для запису моїх мислительних процесів та дизайнерських рішень - навіть неправильних. Якщо хтось у майбутньому намагатиметься замінити компонент на більш "підходящий" або перемістить доріжку на друкованій платі, мої замітки можуть сказати їм, що я вже був там і спалив пальці (можливо, буквально!).

Я завжди нумерую сторінки і дозволяю кілька сторінок на передній частині як зміст. Ви також можете документувати такі речі, як розрахунки розсіювання потужності, допуски, терміни і т.д. (ця звичка походить з моїх днів в аерокосмічній галузі, де ведення журналу журналів було обов'язковим). Звичайно, ви завжди можете помістити цю інформацію в документ WP, але я буду дотримуватися паперу!

Описи схем також можуть бути доречними, коли йдеться про незвичні (особливо аналогові) схеми. Я б ставився до таких, як коментарі програмного забезпечення, щоб документувати будь-які непомітні схеми або функції компонентів. Схематичні схеми, як і програмне забезпечення, повинні бути «самодокументованими», наскільки це можливо, але іноді цього недостатньо.

Більш сучасною альтернативою, особливо в освітньому середовищі, може стати веб-сайт проекту. Це може бути організовано як колекція блогів для кожної дисципліни - дизайн обладнання, компонування друкованих плат, програмне забезпечення тощо. Природа блогу дозволила б авторам показати свій потік думок та задокументувати поточний хід проекту, тоді як інші сторінки можуть бути більш офіційними (прогрес Діаграми Ганта, результати тестів тощо). Ви навіть можете додати протоколи зустрічей та списки дій. Гіперпосилання робить перехресне посилання легким, і тепер у нас є MathJax, тому навіть рівняння дизайну просто вставити.

• Як ми повинні документувати наше обладнання?

• Який важливий документ ви хотіли мати, якщо вам потрібно внести деякі вдосконалення / зміни на інше обладнання, якого ви ніколи не бачили?

• Як чітко організувати цю інформацію?

У нашій компанії очікується, що ми будемо писати документи з описом дизайну обладнання. Це досить просто: ви пояснюєте на початку, що передбачається робити схемою, а потім детально розбираєтесь у кожному розділі. Кожне значення компонента має бути виправдане певним чином: якщо у вас є резистори "підключення" або "серії за замовчуванням", вони повинні бути зазначені в примітці на початку (наприклад, "10K перемикання та байпасні конденсатори 0,1uF використовуються, якщо не вказано інше") , інакше вибір для значень компонентів потрібно пояснити. наприклад "RC-фільтр 4,7 К і 0,1 мкФ (тау = 0,47 мсек), що використовується для обмеження високочастотних компонентів" або "Мультиплексор NLAS4051, що використовується для низького витоку - цей вузол ланцюга є чутливим".