Як ви документуєте свої рішення щодо дизайну обладнання?

Як ви документуєте свої апаратні рішення на етапі проектування? Як уникнути необхідності задавати собі такі питання, переглядаючи дизайн обладнання, який ви робили раніше:

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

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

Один із способів, про який я міг би придумати, - це додавати нотатки до схемних файлів (якщо ваш EDA це підтримує), але я б не хотів захаращувати схему занадто багато інформації.

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

Кожен ноутбук має сторінку вмісту для посилання на певну частину конструкції (джерело живлення тощо), і всі сторінки пронумеровані.

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

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

Ви можете повернутися та оновити специфікацію дизайну з цією інформацією. Або візьміть специфікацію і створіть специфікацію нижчого рівня, де ви детальніше опишите, що ви збираєтеся робити і чому, в ідеалі перед тим, як розпочати схеми :). Потім оновіть, як ви йдете разом, і архівуйте зі схемами.

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

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

Далі слідують детальні функціональні характеристики для кожного з розділів. Деякі проектні роботи насправді тут виконані задовго до того, як вони поставлені в схемі. Наприклад, буде розрахована потужність, відібрані деталі та проведено багато досліджень. Тут ми б задокументували будь-які неочевидні дизайнерські рішення.

Нарешті ми перейдемо до схеми, яка є легкою частиною на даний момент, оскільки багато важких робіт з проектування було виконано на етапі специфікації. Де це потрібно зробити, на мій погляд :) Якщо щось зміниться під час схематичного етапу, наприклад, ми з'ясуємо, що щось не вийде, або людина, що займається маркетингом, біжить по залі, кажучи, що зараз вона повинна бути червоною, а не синьою, тоді ми повернеться та оновить характеристики.

Усі характеристики, PRD, MRD зберігаються у SVN із посиланнями на документи у внутрішній вікі. Зміна специфікації призведе до оновлення SVN та повідомлення зацікавленим сторонам. Звичайно, ви можете просто зберігати його вручну в загальній папці.

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

Добре, можливо, я також повинен був би вирішити кожне питання :)

Якщо ви робите розрахунки, можливо, в excel? Або на папері, і ви вважаєте, що результати та метод важливі для розуміння та проекту вашої схеми, тоді ви повинні включити їх у відповідний розділ специфікації проекту. Навіть якщо це означає сфотографувати ваш малюнок рукою :)

Чому обрали саме цей компонент? Я думаю, що функціональна специфіка є хорошим місцем для цього, не потрібно з глузду зводитись, а просто проста лінія або два про те, у чому полягали її переваги. Я б зарезервував це для критичних компонентів, я не думаю, що ви хочете описувати, чому ви вибрали, наприклад, резистор, що піднімається.

Чому / як я обрав саме ці параметри для цього компонента? Поєднайте це з вище.

Що робить ця частина схеми? Це буде частиною вашої функціональної специфікації, якщо схема досить важлива для того, щоб гарантувати це питання, у неї повинен бути власний розділ специфікації.

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

Яке загальне споживання електроенергії у цій схемі? Я думаю, це належить до розділу живлення вашої специфікації.

Чи можу я замінити цей компонент цим іншим? Чи є еквівалентні компоненти цього компонента? і т. д. Це, на мою думку, належить до вашої BOM або будь-якого процесу, який ви використовуєте для виготовлення. Альтернативні деталі мають полегшити пошук джерел. Знову для нас це все виходить із бази даних про запчастини.

Я роблю багато дизайну швидкого повороту і мушу сказати: кодування схематики - це найзручніша річ. У будь-якій моїй конструкції рідко буває більше 2 або 3 аркушів формату А4, тому кількість дизайнерських рішень обмежена. Дуже багато дизайнерських рішень є майже автоматичними; Мені не потрібно перераховувати причини для кожної окремої частини. Всього одна-дві основні частини, а може бути якийсь фільтр або зйомка пасивного розміру. Решта відразу очевидно для будь-якого досвідченого інженера-дизайнера.

Що стосується вашого останнього запитання: альтернативні деталі, як правило, не є дизайнерським рішенням, а рішенням про джерело пошуку, і як таке воно є частиною вашого робочого процесу з пошуку. У моєму випадку альтернативні частини є в моїй частині властивостей і отримуються автоматично, якщо запас закінчується на первинній частині чи джерелі.

Для більш великих конструкцій та для системного дизайну я зазвичай використовую Google Docs із шаблоном документа-дизайну.

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

Для багатьох моїх менших проектів я зазвичай розміщував просту зелену мітку та облямівку навколо підсхем. Для великих проектів деяке програмне забезпечення eCAD дозволяє будувати з блок-схеми вниз, де кожен аркуш додатково описує один блок. Існує мистецтво розкладати будь-яку проблему та керувати компромісами (це інженерія IMHO). Якщо є чіткий аналіз для вибору компонентів, таких як аналогова фільтрація, я зазначу частоту зрізу та тип фільтра (наприклад, фільтр низьких частот (f_c = 100 Гц))

Поширені блоки, які я стикаюсь з часом і знову включають:

• Управління живленням (регулятори напруги, захист від зворотної полярності, діоди TVS, перемикач живлення, байпасні кришки тощо)
• MCU (мікроконтролер, програмуючий заголовок або колодки, кришки байпаса)
• Індикатори (наприклад, світлодіоди, провід EL, 7-сегментний дисплей, вібромотор)
• Зондування певної функції (наприклад, поточне зондування, сенсорне зондування, GSR, активність, екологічне зондування тощо)
• Команди налагодження (феритна бісер, USB, I2C, UART, SPI, певний спосіб отримати інформацію)
• Радіо (всі компоненти підтримки для багатьох радіостанцій)
• Відео (всі компоненти підтримки та мікросхеми для камери)
• Зовнішнє сховище (наприклад, зовнішня Flash, мікросхема EEPROM для зберігання налаштувань тощо)
• Будь-яка інша особливість, унікальна для вашого дизайну

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

Я зберігаю дизайнерський зошит і ретельно документую потреби / потреби. Щодо ранніх прототипів, я пройду підбір деталей, беру до відома всі реальні рішення. Для подальших змін я використовую досить формальний процес FMEA, документуючи необхідність якого не задовольняється, щоб виправдати зміну - адже очевидно, якщо немає незадоволеної потреби, немає потреби в змінах!

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

Усі версії всіх речей відслідковуються за допомогою підриву.

Це може бути істотним компонентом файлу історії дизайну, який є обов'язковим для FDA.

Я часто використовував основну інформацію (ви також можете використовувати PowerPoint). Це має перевагу в тому, що дозволяє обмежувати екрани програмного забезпечення для моделювання, таких як SPICE GUI та подібні.

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

Я також вважаю, що, як правило, хочу займатися математикою та малюнками, використовуючи олівець на папері. Тож я беру фотографію зі своїм телефоном і опускаю його в основну примітку, не вводячи текст. Іноді для коротких рівнянь я можу використовувати LaTeX і скинути це.

Я також можу включати сюжети, намальовані таким науковим програмним забезпеченням, як октава.

Сьогодні, особливо для обчислювально-інтенсивних завдань, я можу вирішити виконати частину цієї роботи в зошитах IPython, але я не робив цього спеціально для конструкцій схем, лише для обчислення фізики.

Нарешті, Keynotes / Powerpoints легко підготувати для інших та експортувати у форматі PDF для розповсюдження серед не менш технічних людей.

Розмістіть інженерні замітки на схемах і при необхідності створіть більше аркушів. Я завжди розміщую інженерні замітки на всіх моїх схемах, тому що в моєму світі мені, можливо, доведеться повторно відвідати 1/2 запечені конструкції на певний проміжок часу, а потім знову поставити її на задню панель, поки я підбираю інший дизайн; дуже текучий проектний потік. Ці примітки з ЕЕ допомагають мені та іншим з невеликими зусиллями відновити проектні наміри. Я також використовую різні кольори тексту / графіки, щоб вказати на важливість чи контекст. Приклад нижче ...