Конструирование

Хорошее разрешение достижимо

В интернете много публикаций о том, как используя DVD-R диск и смартфон можно собрать спектрометр, однако характеристики таких устройств не позволяют проводить точные измерения. Мне же удалось сделать прибор с разрешением 0,3 нм.

Основные характеристики

Спектрометр работает в диапазоне 400-700нм с разрешением 0,3 нм. Применяются сменные оптические щели шириной 50, 100, 200 и 300 микрон. Дифракционная решетка с шагом 740 нм изготовлена из DVD-R диска. Регистрация спектра выполняется зеркальной фотокамерой Nikon D5100. Прибор выполнен в крепком корпусе, позволяющем сохранять настройки при перемещениях.

Конструкция и изготовление прибора

Дифракционная решетка

Диск был расслоен на две половины и разрезан на части, которые после промывания спиртом были помещены в рамки. Дифракционная решетка готова.

Изготовление сменных оптических щелей

В дюралевой пластине сверлю отверстие диаметром 8 мм. Клеевым пистолетом закрепляю половинку лезвия безопасной бритвы, располагая режущую кромку по центру отверстия. Вставляю в отверстие щуп толщиной 50 мк, плотно прижимаю вторую половину лезвия и приклеиваю ее. Аналогично делаю щели 100 мк, 200 мк и 300 мк. Сменные оптические щели готовы.

Корпус спектрометра

Делаю деревянный корпус. Окрашиваю внутри и снаружи в черный цвет.

Оптика и регистрация спектра - фотоаппарат NIKON D5100

Примерно на 3000 пикселей матрицы приходится около 300 нм видимого спектра. Т.е. 1 пикселю соответствует 0.1 нм. Для надежной регистрации линии нам нужно два-три пикселя. Расчеты показывают, что для такого разрешения размеры оптической щели должны быть порядка 100 микрон. Было сделано несколько щелей для выбора лучшего варианта экспериментальным путем.

Чтобы получить такое разрешение необходим зеркальный фотоаппарат с хорошим объективом. Смартфон и веб-камера не подходят. Требуется большая апертура и ручные настройки. На данный момент на Авито можно приобрести подходящую камеру по цене от 5 до 10 тысяч рублей.

Настройка и калибровка спектрометра

Калибровка прибора проводилась перед каждой серией экспериментов по известному спектру компактной ртуть содержащей люминесцентной лампы.

Определение длины волны линий исследуемого спектра возможно без специального программного обеспечения. Ниже спектр лампы с линиями ртути 435,8 нм, 546,0 нм, 577,0 нм и 579,1 нм. Линия 611 это уже Европий.

Расстояние между линиями 2, 1 нм. Половина ширины линии на кадре не более 0,3 нм, что соответствует примерно 3пикселям матрицы. Делаем вывод разрешение прибора 0,3 нм. Что в дальнейшем подтвердится съемкой двойной линии натрия.

Для построения спектральных кривых можно использовать программу сайта Spectral Workbench

Измерение различных спектров

Были проведены несколько классических экспериментов.

Самый интересный эксперимент, ради которого и был изготовлен спектрометр - измерение спектра пламени костра

На фоне непрерывного спектра была зарегестрированна яркая линия, которую я назвал линией огня.

Обработка результата

Совмещаем спектр калибровочной лампы и исследуемый спектр на одном кадре. Зная расположение известных линий ртути, можно определить искомую длину волны, путем замеров и последующих расчетов.

Что это за линия и как она возникает - читайте в моей статье "Спектральный анализ пламени костра. Что делает огонь желтым наночастицы углерода или соли натрия?"

http://personeltest.ru/aways/habr.com/ru/post/545710/

Полезные ссылки:

1. Сайт Spectral Workbench. Используя программы на сайте можно обрабатывать спектры и получать графики интенсивности в зависимости от длины волны.

https://spectralworkbench.org

2. Информационная система Электронная структура атомов. Очень удобный русскоязычный ресурс по спектральным данным атомов и ионов.

http://grotrian.nsu.ru/ru/periodictable/

Продолжаю делиться историей разработки аппаратной платформы GM-Box G1. В предыдущей статье я рассказал о первых шагах на пути создания продукта - прототипировании для проверки продуктовых гипотез. Этот этап позволил сформулировать требования к серийному изделию.

Сейчас речь пойдет о непростом пути от технического задания до решений промышленного дизайна и запуска серийного производства в России. Снова будет много технических деталей, фотографий и моих откровений инженера.

Запуск разработки серийного продукта

Наступил долгожданный момент, когда после множества презентаций мы получили инвестиции и начали подготовку к разработке серийной версии нашего продукта. GM-Box стал превращаться, конечно не из гадкого утенка в прекрасного лебедя, но из прототипа во вполне симпатичное и рабочее серийное изделие. Собранные на этапе прототипирования инсайты и знания о нашем продукте мы оформили в виде технического задания (ТЗ). Формат выбрали в международной нотации - Product Requirement Document (PRD), потому что готовились к общению с иностранными подрядчиками.

Перед нами стояли следующие задачи:

• промышленный дизайн;

• разработка конструкции корпуса и молдинга для литья пластика;

• разработка схемотехники и трассировка печатных плат;

• разработка Firmware, системного, прикладного и серверного программного обеспечения;

• организация цепочки и снабжения компонентами, в том числе серийного литья пластика;

• сборка и тестирование печатных плат;

• узловая сборка, заливка софта, испытания (приемочные, приемо-сдаточные и т. д.);

• организация ремонта, технического обслуживания и поддержки;

• организация логистики (в т. ч. международной);

• управление качеством;

И, конечно же, мы бились над извечной дилеммой делать всю разработку самим (In House Design - IHD) или заказать на стороне (Original Design and Manufacturing - ODM). Выполнение всех задач внутри требовало немаленькой команды профи разных направлений, а еще много специального оборудования и софта. Это недоступная роскошь для стартапа, и мы решили скомбинировать IHD и ODM. Вот какими были наши ключевые требования к потенциальным партнерам:

• опыт разработки x86 платформ на современных SoC, включая BIOS и EC;

• опыт разработки продуктов сегментов: планшеты, телефоны;

• опыт разработки сложных пластиковых корпусов;

• высокий уровень качества продукции, услуг;

• опыт организации и сопровождения крупносерийного производства собственных продуктов.

Изучив рынки России и Беларуси, мы с удивлением осознали, что не можем найти компанию, соответствующую всем нашим ожиданиям. Тогда, хоть и с тревогой, но мы приняли решение ехать в более дальнее зарубежье в поисках партнера. Шел 2017 год Мы нашли азиатскую ODM компанию с нужным нам технологическим стеком, опытом и хорошим качеством. В итоге разделение между нами и ODM перечисленных выше задачах получилось такое: 60% (мы) на 40% (ODM). Работа закипела, и мы начали готовить требования к внешнему виду изделия.

Промышленный дизайн

Нам предстояло описать, как наше устройство будет выглядеть внешне, со стороны пользователя, взаимодействовать с ним и окружающим пространством, интерьером корпоративного офиса или его рабочего места дома в случае удаленки. Функциональные и нефункциональные, технические требования, определяющие форму и содержание, были собраны в ТЗ, их было достаточно много. Одним из ключевых требований было обеспечить удобную и стильную реализацию синергии в продукте смартфона и GM-Box.

Наш дизайнер Михаил, зарядившись ТЗ, идеями и инсайтами команды, с учетом опыта, полученного на прототипах, принялся за работу, а мы стали ждать от него волшебства. Сначала, как и на этапе прототипирования, появились черновые наброски скетчи:

Дальше перешли к 3D моделированию в Autodesk Inventor. Было безумно много вариантов дизайна на разный вкус и цвет.

Внутри команды мы периодически проводили презентации очередной версии дизайна. Обсуждали решения, предлагали изменения, спорили и, конечно же, даже ругались (какой стартап без ссор?), но всегда договаривались.

В итоге родился промышленный дизайн будущего серийного продукта.

Корпус, механика

Мы глубоко проработали дизайн и даже элементы внутренней механики, но все это нужно было связать с начинкой нашего изделия электроникой и обеспечить технологичность при серийном производстве. На базе 3D модели нашего дизайна и требований ТЗ наш ODM партнер начал проработку конструкции. Моделирование делали в Pro Engineer и присылали нам презентации с картинками и вопросами. В ответ мы моделировали в Autodesk Inventor и отправляли им свои идеи. Начитавшись про методологии разработки известных мировых брендов, мы погрузились в длительный итерационный процесс создания MDP (Minimum Desirable Product), сохраняя 3 его точки опоры:

• гештальт продукта;

• дизайн;

• качество.

Расскажу коротко о самых сложных узлах, попивших у нас крови.

Раскладная опора (нога)

Мы искали решение, которое обеспечит складывание ноги в транспортном режиме. При этом в разложенном состоянии нога должна слегка фиксироваться, предотвращая складывание ноги при работе с устройством. А еще нужно чтобы петля занимала мало места и была недорогой.

Вентиляционная решетка

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

Интерфейс подключения смартфона

Необходимо было обеспечить разъемное соединение смартфона с Gm-Box. При этом, реализовать возможность подключения любого смартфона, удобство пользователя и высокую надежность узла.

Конечно, были непростые задачи и с другими частями конструкции. Вот самые запомнившиеся элементы:

• система охлаждения;

• клавиатура;

• трубка;

• держатель кабелей;

• внешние микрофоны;

• слот батарейки часов реального времени;

• собираемость изделия.

Финалом работы над корпусом стали:

• подробная 3D модель GM-Box;

• Mockup образец (неработающий опытный образец).

Целью изготовления Mockup образцов было подтвердить соответствие дизайна, 3D модели и материалов ожиданиям заказчика (нас) и пользователей. Технологически процесс их изготовления состоял из операций:

• 3D печать;

• фрезеровка напечатанной заготовки;

• ручная доработка: снятие заусенцев, ошкуривание, шлифование;

• покраска;

• финальная сборка и "доработка напильником".

Что-то пошло не так

Пока мы не ушли далеко от разработки корпуса, расскажу о сложностях, с которыми мы столкнулись на этом этапе, и как мы с этим справились. Получив на руки Mockup образцы, мы стали оценивать его реальный дизайн, а не рендеринг. Разница между картинкой и физическим объектом значительная и именно поэтому изготовление и анализ Mockup так важен для получения качественного продукта. Нас не устраивал дизайн клавиатуры и трубки, с точки зрения их визуального восприятия. Получилось не то. И мы решили переработать эти узлы.

В поисках нашего гештальта для MDP (писал об этом выше) мы потратили 4 месяца на дизайн и дополнительное прототипирование:

• искали альтернативные варианты дизайна клавиатуры и трубки;

• прототипировали;

• обсуждали;

• вносили изменения в дизайн изделия и его 3D модель;

• вносили изменения в 3D модель конструкции.

Электроника

Параллельно с созданием корпуса мы начали разработку электроники. Нам предстояло решить следующие задачи:

• разработка архитектуры;

• выбор элементной базы;

• компоновка печатных плат и устройства;

• расчет себестоимости, оптимизация;

• Design For Manufacturing (DFM) анализ и доработка;

• наладка (брингап) электроники.

Этапы разработки электронной части в связке с корпусом\механикой и софтом у нас получились такие:

• Mockup прототип, пустышка, полноразмерный неработающий образец;

• EVT инженерные образцы, частично работающие, позволяющие отлаживать софт;

• DVT полнофункциональные опытные образцы с косяками;

• DVT2 - полнофункциональные опытные образцы без косяков;

• PVT образцы, собранные на конвейере по серийной технологии;

• MP серийные изделия.

Очень похоже на наш отечественный процесс разработки по ГОСТ 15: ЭП, ТП, РКД, постановка на производство.

Отрисовку схемотехники и топологию печатных плат выполнял ODM партнер. Использовали Cadence ORCAD. Буквально через 3 недели после готовности топологии появились первые образцы системных плат, и мы поехали их брингапить в Азию.

Сначала железо запускали и тестировали на Win10, т. к. много готовых утилит, примеров, референсов для наладки. После того как железо ожило на Win10 мы перешли к проверке и доработке на Linux Ubuntu. Это был итерационный процесс поузловой наладки и доработки BIOS и программы EC контроллера. Больше всего досталось нашим программистам, т. к. железо без софта не работает, а софт у нас на Linux Ubuntu и заточен под особенности продукта. Пришлось сильно попотеть в раскуривании работы чипов и общей логики работы устройства и отдельных узлов. Ну и конечно перед нами стояла задача финальной валидации работоспособности продукта на этом этапе разработки (EVT).

Снаружи GM-BOX все просто, а под капотом много интересных штук:

Программное обеспечение

Железо без софта безжизненный организм, хотя мне больше по вкусу вот такая визуализация архитектуры программного обеспечения:

Если серьезно, то наш софт это достаточно сложный набор компонентов:

• Firmware;

• системное ПО;

• серверное ПО;

• мобильное ПО.

У каждого компонента свое предназначение, история разработки, набор применяемых технологий, интересных фич. Поэтому про каждый элемент в отдельности мы расскажем в наших следующих статьях.

Вкратце расскажу сейчас только про устройство Firmware, как крайне важный компонент для оживления электроники. Это даст более цельное понимание устройства нашей аппаратной платформы.

Firmware GM-Box G1 состоит из:

• BIOS (Basic Input Output System) обязательная часть х86 платформ;

• EC (Embedded Controller) система управления аппаратной инфраструктурой (питание, сброс, периферия).

BIOS для x86 платформ на рынке предлагают несколько вендоров: AMI, Insyde и т.д. У каждого такого продукта есть свои преимущества и недостатки. Сделать оптимальный выбор и разработать BIOS под нашу аппаратную платформу нам помог наш ODM партнер с учетом: своего опыта, наличия лицензий, исходников и тулчейна для разработки. Итого, мы получили рабочий BIOS, исходники и тулчейн для возможности модификации.

EC контроллер аппаратно реализован на чипе IT8987. Это интегрированное решение для управления инфраструктурой простеньких ПК. Внутри ядро классического микроконтроллера х8051. Программа для EC тоже разрабатывалась ODM, но мы потом кое-что дописали сами. Итого, мы получили рабочую прошивку EC, исходники и тулчейн для возможности модификации.

Упаковка

С дизайном GM-Box мы успешно справились и настал черед сделать красивую упаковку. С одной стороны, это продукт для B2B и B2G рынков, а значит коробку, скорее всего, выбросят сразу после приобретения, и нет необходимости заморачиваться над дизайном. С другой стороны, учитывая специфику нашего продукта, важно было обеспечить безопасную транспортировку и сохранить его презентабельный вид. К тому же мы выходили на рынок с новым продуктом, поэтому упаковка выполняла еще и задачу презентации устройства показать, что внутри высокотехнологичный, качественный продукт. Так что мы продумывали все до мелочей.

Наша упаковка должна решать следующие задачи:

• защита изделия от повреждения во время транспортировки и хранения;

• удобное паллетирование и одиночное хранение;

• удобное размещение компонентов изделия для легкого доступа к ним пользователя;

• понятный процесс подготовки и включения изделия;

• дополнение образа качественного, инновационного продукта.

Мы снова воодушевились, взяли для примера лучшие бренды электроники и получилось вот такое решение:

Коробка выполнена из гофрокартона с нанесением цвета и дополнительной графики.

Нас очень сильно беспокоило транспортирование кабеля телефонной трубки. Он спиральный и легко деформируется. Мы не хотели, чтобы пользователь брал в руки изуродованный кабель. В жизни это выглядит так:

Решение нашлось, в виде специальной коробки с ложементом для кабеля:

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

Заключение

Успешное прохождение этапа прототипирования не означает, что при разработке серийного продукта все будет гладко. Неожиданности поджидают на каждом шаге разработки, к этому нужно быть готовым морально и технически. Самое важное в успешном преодолении этих трудностей командная работа, вовлеченность (даже увлеченность) каждого члена команды и фокусирование на поиске лучшего решения для продукта. Тщательная подготовка к предстоящему этапу работ и формализация требований помогают подстелить соломку и снизить риски неудач.

В следующей публикации я расскажу об этапах тестирования и постановки на производство. Снова будет много технических деталей и фотографий.

Полезные ссылки

1. В чем разница MVP и MDP?

2. От дизайна до производства: Как обеспечивается качество продуктов Apple

В статье затронута важность разработки стандартов в команде hardware разработчиков, а также приведен пример одного из стандартов для ведения репозитория на сборку.

Для прочтения необходимо иметь базовые представления о конструировании.

Немного истории

До 2020 года я работал конструктором (разрабатывал электронику и электрику). Сейчас я сменил сферу деятельности, но считаю важным поднять вопрос, который возник в свое время, пока он совсем не выветрился из головы.

Команда наша была небольшая, внутренние регламенты еще не были сформированы, поэтому мне представилась возможность для творчества в части организации разработки своих узлов. Единственное ограничение - мнение требование заказчика. А заказчик - военный завод с бумажным документооборотом, нормоконтролем и всяких таких заморочек. В мои задачи входила разработка, сборка, наладка электроники и электрики (PCB проекты, чертежи, схемы, спецификации, ИИ - это были мои брат, жена,сестра и все такое). Ввиду того, что бумажный документооборот уже не соответствует темпам развития инструментов разработки, он принял вид некоторого формального рудимента. И все мы плевались на это требование, но смирялись, так как они заказывали музыку.

Таким образом были файлы проекта, которые по сути нужны и достаточны и были спецификации, чертежи, схемы, перечни, которые нужны были в части узлов лишь формально. Мышление самодельщика быстро сформировало структуру проекта: папка с файлами.

Но как только посыпались ошибки и последующие исправления, количество папок выросло.

И это еще порядок. То что я видел в некоторых проектах удручает сильнее (см. ниже).

Каждая версия была важна, осмысленное именование могло бы помочь, но к счастью электроника и программирование часто идут бок о бок. Моя работа не была исключением. Так или иначе я познакомился с git, который был для меня чудом чудесным в хорошем смысле. Все файлы проектов сразу были подвергнуты версифицированию (корявый, но ценный log внизу).

Огорчило только то, что не было таких важных функций системы контроля версий как merge, diff, compare, ведь файлы для того же печатного узла для системы контроля версий - бинарники (за редким исключением, о чем ниже), а как известно данные инструменты в нативном гите не работают. Но осмысленное хранение уже было достаточно. К сожалению проект закрылся и наработки в области использования git для hardware так и остались на полке. Но именно поэтому я пишу здесь, чтобы привлечь внимание к проблеме и по возможности разработать регламент-образец для нашего сообщества. Я спрашивал других разработчиков из других городов о том как они организуют файлы проектов и у каждого был свой рецепт. Если мы поделимся своими рецептами, то увидим в них слабые и сильные стороны. Мы сможем сформировать свой, продуманный механизм. В данной статье я делюсь своим.

Стандартизация в конторе

Что то более серьезное всегда делается сообща. Наш коллектив не исключение. Были штатные сотрудники, были просто туристы, были люди, задействованные на outsource. Каждый делал так как ему казалось правильным. Итоговые документы pdf-ок с чертежами формально подходили для нормоконтроля и производства, но поддерживать это было очень сложно. Ситуация приближалась к важному вопросу: вопросу стандартизации. Да, мы молодой подвижный коллектив и противопоставляли себя излишне бюрократическому заводу. Главное - результат, документация потом. Но порой за этим прячется лень и неграмотность. Хочу подчеркнуть, что все зависит от уровня проекта и готовности самих людей. Если это реально просто поделка, то ничего не надо, но если работают несколько людей, а по результатам испытаний возникает куча правок, то стоит иметь порядок и однозначность в документации.

Таким образом мы столкнулись с необходимостью обговорить то как мы называем имена файлов, то как мы присваиваем обозначения сборкам и деталям, то как мы вносим изменения. Часть из соглашений было прописано, а часть была негласной. Здесь содержится мой первый призыв к сообществу:

Разработайте хотя бы простенькие стандарты о том как вы оформляете структуру файлов в проекте.

Это упускается даже в крупных конторах как оборонные заводы, где казалось бы есть целый отдел стандартизации. Отношение к группе ЕСКД как к дарам свыше, к которым нельзя ничего прибавить и убавить, порождает отвлеченность этих стандартов от реального процесса разработки. В каждом отделе формируется свой подход к организации хранения исходников. Доходит до того, что при внесении изменений в конструкцию заново формируется файл проекта от отдела к отделу. Я не говорю уже о хранении баз данных библиотек компонентов и footprint. Но, внимание, сам ГОСТ призывает его дополнять. В 2013 году в ГОСТ 2.001 добавлен пункт:

8.5 В КД допускается указывать ссылки на другие КД, стандарты и технические условия на материалы (вещества). Допускается указывать ссылки на стандарты организаций при условии, что они однозначно определяют соответствующие требования к изделию. Допускается указывать ссылки на технологические инструкции, выполненные по стандартам Единой системы технологической документации, когда требования, установленные этими инструкциями, являются единственными, гарантирующими требуемое качество изделий.

Не ленитесь, то что очевидно для вас, не является очевидным для всех. Пропишите или проговорите принципы, по которым организуете проект.

Есть ли у вас в команде/предприятии регламент на структуру файлов проекта?

Также существует "секретный" документ Д33, значение которого должна установить сама организация. И это выход для нас, друзья. Д33 - это электронный документ. Он содержит данные проектирования для печатной платы. В него вы можете поместить файлы проекта и узаконить его ответственное хранение. В него вы можете обязать вносить так же и bom, столь любимый нами. Подробнее см. РД 107.460640.020-88.

Стандарты очень нужны нам, только важно их вовремя обновлять и поддерживать. Да, нужна некая дисциплина для подчинения им, но они просто необходимы для повышения качества разработки.

Обзор систем контроля версий для hardware

Некоторый САПР поддерживает системы контроля версий нативно. К таким относится Altium Designer с SVN. Но с Altium у меня не сложилось из за цены в 500 кр. Но по сути это прекрасно. Это то что нужно, но для меня мимо. К тому же приходится использовать не только Altium, ведь существует механика и электрика (жгуты, блоки). Хотя если вы используете Altium стоит использовать SVN для всего.

Так же в сети есть примеры использования git хуков для KiCAD, для формирования diff. И это здорово, если вы используете KiCAD - это может вам помочь. Но мы использовали DipTrace в связке с КОМПАС и это не подходило. Но с глобальной точки зрения - это важный инструмент.

Eagle, столь популярный на западе тоже имеет костыли для интеграции с git.

Интересный ресурс CADLAB.io. Это что то типа github, но для проектов в Eagle, KiCAD, Altium. И ребята планируют расширять форматы. Это здорово, не проходите мимо, если вы используете данный САПР.

Уже сейчас я познакомился с EasyEDA. Ведь нужно порой до сих пор что-то накидать, но ставить серьезный САПР для дома как то не охота. Тем не менее он тоже имеет вкладки системы контроля версий. В общем движение в эту сторону имеется. Поделись тем, что известно тебе.

Но нашего инструмента так и не было. Да, его можно создать, да можно мигрировать на другой САПР. И если бы проект продолжился, то мы бы обязательно пошли дальше. Но важно дать общее положение. Общий регламент того как вести репозиторий независимо от САПР. Данный регламент стоит дополнять под тонкости конкретного САПР.

Есть ли у вас в команде/предприятии регламент на использование систем контроля версий?

Мой стандарт по ведению репозитория

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

Стандарт назван Обозначение версий для hardware. И это не спроста. Очень важно иметь соответствие между коммитом и между реальным образцом (будь то макет или какая то ревизия тестового образца). Это решается обозначением номера версии как на самом изделии так и в документе, так и в логе git (такое требование и содержится в требовании на конструкцию на печатную плату).

1 Общие положения

1.1 За основу обозначений принята система внесения изменений ЕСКД. Если вы читаете этот документ впервые, то советую прочитать хотя бы второй раздел ГОСТ 2.503.

И я перепробовал всякое, но остановился на ЕСКДшном подходе указания версий потому что:

1. Это идеально клеилось с взаимодействием с заказчиком;

2. Все тонкости продуманы и опробованы годами до тебя;

3. Любой мало мальский инженер в теме и поймет интуитивно эти литеры.

1.2 Внесение изменений это не создание следующей версии железа, которая не совместимо с изделиями выпущенными до этого (п. 4.2 ГОСТ 2.503).

В этом случае необходимо присвоить изделию новое обозначение. На изделия единичного производства и на опытный образец (опытную партию) допускается не выпускать конструкторские документы с новыми обозначениями, если их применяют не более чем в одном документе.

Это очень важно. Каждый PartNumber (децимальный номер) должен быть уникальным. И важно присваивать обозначения, а не просто давать имена сборкам. Просто назвать энкодер Энкодер, но не дать обозначение - это значит внести путаницу, если вы будете делать уже другой энкодер. Ведь вы его назовете Энкодер 2.0, но у него своя история версий. Обозначение всех деталей и узлов можно производить по тому же классификатору ЕСКД с занесением в базу данных (у нас это был табличка в Excel на локальном диске) порядкового номера. Опять же причины:

1. Это идеально клеилось с взаимодействием с заказчиком;

2. Все тонкости продуманы и опробованы годами до тебя;

3. Любой мало мальский инженер в теме и поймет интуитивно эти литеры.

1.3 Под релизом подразумевается изготовление узла.

Это важно, так как я использую тег релиза (см. далее). К тому же важно вести отдельную релизную ветку с запретом fast forward.

2 Внесение изменений и ведение репозитория

2.1 Log git представляет из себя журнал изменений до литеры O1.

По возможности стоит пользоваться Log git в течении всего жизненного цикла изделия.

Это важная концепция. Если вы не в теме, то важно знать, что для опытных образцов для упрощения документооборота допускается проводить изменения в документации просто по журналу изменений. Причем этот журнал составляется на более или менее самостоятельную сборку. Узел, блок или шкаф - подойдет. А Log git идеально выполняет его функции.

2.2 Репозиторий необходимо создавать для каждой самостоятельной сборочной единицы.

Это важно, так как вышестоящая сборка зависит от нижестоящих сборок. И важно, чтобы на сборку выше уходили только стабильные коммиты (со стабильной ветки).

Допускается не заводить репозиторий до тех пор, пока изменение не нагрянет.

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

2.3 Коммит в стабильную ветку должен содержать корректировку всех документов (всех схем, перечней и т. п.).

К примеру вы решили поменять транзистор в сборке. Для этого надо:

1. поменять его в файле схемы;

2. обновить файл платы по схеме;

3. поменять его в bom;

4. поменять его в перечнях, спецификации и чертежах (при необходимости).

5. сделать коммит с версией = версия + 1.

2.4 Литеру изменения при релизе надо проставить во всех КД (в pdf, в исходник САПРа, на шеклографию и медь).

Если указание версии с поясняющей надписью "Версия", "version", "V" затруднительна, то следует указать её хотя бы в квадратных скобках.

Это спорно, и нет такого в ГОСТ, и скорее помогает отнести распечатанный чертеж с Log git. Но если бумага не ходит, то это не нужно.

2.5 Если изменение допускает доработку задела, то изменения по электрике нужно внести в файл схемы.

Если формирование файлов для производства не планируется, то доработка отражается в файле проекта в отдельном слое (см. табл. ниже). Если же планируется релиз. А доработка просто использует задел в дополнение, то для каждого дорабатываемого задела необходимо создать свой pcb файл с именем "Доработка N", где N - номер задела. В отдельном слое проекта (см. табл. ниже) необходимо внести пометки, касающиеся доработки (в том числе и место наклейки/надписи с новым номером литеры изменения). На изделие стоит поместить новый номер.

Однако, если доработка несущественная, то достаточно сделать фотографии доработки, поместить их каталог "Доработка N" и выполнить коммит.

Если делать это сверх сил, то хотя бы в комментарию к коммиту нужно описать действия, которые необходимо произвести с изделием из предыдущего коммита, чтобы получилась новая версия. Например "Связи выполнить проводом сечением не менее 0.22 мм"

Есть изменения, который мы вносим в железо доработкой (перемычки, перерезания дорожек). Таки доработки тоже нуждаются в описании для их повторения и для истории. При этом возможны две ситуации:

1. Изменение затронет только доработку;

2. Планируется отдать на производство изделие с изменениями, но параллельно планируется доработать имеющейся задел.

В первом случае необходимо прямо в проекте прописать изменение в отдельном слое. А во втором случае стоит создать отдельную папку с описанием доработки.

Упрощения важны, так как никто не будет проводить огромную работу из за мелочи, и репозиторий будет не актуальным.

2.6 Допускается указывать номер версии на изделии в новом месте (при этом старый номер необходимо подчистить или хотя бы изуродовать).

Это важно, чтобы сопоставить версию файлов и версию конкретной железки. Не оставляйте старые номера версий, ведь можно заметить сначала его, и ошибиться.

2.4 Изменения касающиеся вторичных КД (README файл, опечатки в ПЭ3 и т. п.) тоже закрепляются коммитом.

Казалось бы зачем? Но так мы исполняем требование ЕСКД. Отличить такой коммит можно по выводу его сравнения с родителем. Таким образом, чтобы иметь актуальные файлы по конкретной версии железа, нужно не просто найти номер в Log git, но и просмотреть коммиты выше на предмет изменений вторичных документов.

2.5 Тег релиза стоит размещать для изделий, отданных на производство. Тэг имеет следующий вид:

release_ММ.YY,

где release - просто строка;

ММ.YY - год и месяц изготовления.

Подобное требование мы находим в требования на конструкцию печатных плат.

2.6 При отдаче в производство файл проекта стоит переименовать добавив к нему номер версии (для СКВ контрактника).

Это важно, чтобы платы были изготовлены именно по новой документации. Был один прокол с резонитом, который по имени файла нашел старые фотошаблоны.

3 Обозначение версий узла

3.1 HW версия представляет из себя номер последнего изменения.

Ну и итог стандарта - смысл версии железа.

Вот ссылка на стандарт.

Что дальше?

Для работы нужны и другие стандарты. Например применение Gitflow.

Хорошо бы работать хуки для проверки требований стандарта, или хотя бы косвенные проверки в виде проверки даты изменения gerber файлов и т. п.

Но это детали. К тому же большое количество стандартов тоже плохо. Важно иметь основные требования, а в тонкостях должна быть свобода.

Пишите ваши замечания в комментариях, так мы сделаем конструкторский мир чуточку лучше.