Search
Write a publication
Pull to refresh
20
72.1
Алексей Фоменко @Strannii

Инженер-электронщик

Send message

Конечно, главным образом отслеживаются именно системные проблемы. Мы не ремонтируем руками разработчиков каждый непропай светодиода, или недоклеенный разъём =)

Программно-аппаратный баг, допущенный именно при разработке, вряд ли проявится через годы работы (конечно, такое бывает, но это исключительные случаи, требующие отдельного рассмотрения). И для "старых" устройств, главным образом, мы следим за проблемами, которые носят системный характер.

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

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

Про какие "оригиналы" вы говорите? Единственное, что мы частично переиспользуем — это часть трассировки SoC — DDR память. И то, часто там мало остаётся от референса, предоставленного производителем чипов.

Всё остальное проектируется с нуля. Даже динамики мы просчитываем и заказываем именно с необходимыми нам параметрами Тилля-Смолла. Вся конструкция, все схемы, платы, и даже сборки linux — всё разработано под конкретный продукт.

Да, мы проектируем схемы и платы в Altium (что, собственно, вы верно подметили из скриншотов).

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

Кстати, приходите на Я-Железо, там обычно на стенде можно встретить большинство наших электронщиков и конструкторов, можете вживую пообщаться и задать точечные вопросы =)

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

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

А там, глядишь, и будет отклик в чем-то материальном.

Чтобы не тратить драгоценное время команды разработки на очередное переизобретение автоматизации тестирования, мы используем опенсорсные проекты, как например, OpenHTF.

К сожалению, такие системы (как и HardPy) не напишут сами тесты, специфичные для конкретной платы, не разработают механику джиги, не проработает тест-план.

К тому же такие общие инструменты не способны закрыть все наши потребности в обеспечении качества, поэтому мы активно развиваем и переиспользуем собственные внутренние инструменты.

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

Не уверен, что понял ваш вопрос, но "на самом деле" в нашей команде аппаратной разработкой занимаются инженеры-схемотехники/трассировщики, инженеры-конструкторы, инженеры аппаратного тестирования, инженеры производственного тестирования, инженеры системного ПО, ВЧ-инженеры, инженеры по качеству, технические менеджеры, технические руководители проектов. Наверняка кого-то ещё забыл...

Чем длиннее стрелка "назад" — тем "больнее" бизнесу от каждого такого перемещения. Поэтому на этой линии так много промежуточных точек: всё для того, чтобы не случилось ситуации, когда нужно перепрыгивать назад через стадию. Это вопрос организации бизнес-процессов, в т.ч. на самых ранних стадиях.

По поводу документации: документация ведётся в том объёме, который необходим для работы с производством, с сертификационными органами и сервисными центрами. Отдельно про эту (скучную) часть я писать не стал — и так статья получилась довольно объёмная.

Про сертификацию: устройства проходят испытания и получают сертификаты соответствия ТР ТС 020, 004 и прочих ЕАС-специфичных регламентов. В статье об этом упомянуто вскользь, т.к. вся разработка ведётся сразу с прицелом на нормы регулирования, и ещё до подачи на сертификацию мы должны убедиться, что мы необходимые испытания пройдём (самое сложное тут, конечно, испытание на ЭМИ). А далее со спокойной душой устройства отправляются в сертификационные лаборатории.

Не хочу показаться излишне нудным, но вроде как эта история не имеет никакого отношения к Нильсу Бору. Вроде как вот тут даже неплохо это доказали: https://provereno.media/blog/2023/10/03/pravdiva-li-istoriya-pro-nilsa-bora-i-zadachu-o-barometre/

И да, Ernest Rutherford по-русски пишется как Эрнест Резерфорд.

А вот в наше время не голоса были, а голосищи! От их пения бокалы лопались, поэтому мы их в серванте держали.

А музыку всем селом писали! И все, заметьте, выпускники консерватории!

Если две ноты в песне повторялось — Сталин сразу расстреливал. Поэтому все песни были одна на другую непохожие.

А выглядели артисты все на загляденье — хоть сейчас под венец отдавай: опрятные, ухоженные. Румянец на щеках такой был, что даже на черно-белом телевизоре проявлялся.

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

А в этом видео можете увидеть, сколько на самом деле занимает места прибор)
А тумба — это просто тумба.
Колоссальная работа проделана, смотреть одно удовольствие!)

У меня только пара технических вопросов:

1. Вы написали, что выравнивали дорожки в рейзере по времени, а не по длине. Каким способом вы рассчитывали время? Встроенным в Аллегро калькулятором, или сторонним? Насколько я помню, Аллегро считает время просто по длине меди, и завязать скорость распространения с внешними условиями — хороший челлендж. И отсюда другой вопрос:

2. Пользуетесь ли вы сторонними калькуляторами импеданса типа Polar, и сравнивали ли его результаты с результатами встроенного в Аллегро калькулятора?

3. Вы смотрели реальную глазковую диаграмму после того, как выбрали 100-омный разъем вместо 85-ти омного? Или хотя бы симулировали это в предтопологическом анализе?

4. Как у вас организован процесс совместной разработки с конструкторами? В аллегро предполагается использовать idx формат, но его мало какие механические САПР поддерживают.

5. Бэкдриллинг вы делали на разные глубины?
Все опыты замечательные, и экскурсия просто супер, но у меня возник один вопрос: а вы пробовали соединять коктейльные трубочки таким образом, как показано в вашей карточке? По моему опыту, это невозможно сделать герметично, т.к. они одного и того же диаметра с обоих концов, а материал весьма неэластичный.
Это очень здорово, отличную работу вы проделали! Даже не верится, что до этого никто не сделал систему такого типа
т.к. сам в поиске

А приходите к нам, нам сейчас нужно много хороших профессионалов)
То есть у вас дифпары HDMI идут без опорного слоя? А возвратные токи? Либо я что-то не понимаю в интерфейсе HDMI, либо это просто чудо, что у вас все заработало. Это же идет вразрез со всеми мыслимыми правилами разводки высокоскоростных интерфейсов. Даже примерная прикидка дифпары 0.2-0.2 на плате толщиной 1.5мм дает импеданс 150 Ом при необходимых 90.

Какой размер картинки передаете? Судя по фото, это 1366х768. Вы пробовали запускать изображение крупнее?

Может, у вас есть какой-то секрет применительно к HDMI (короткая линия, личные эксперименты)?

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

Я его спросил, какую задачу нужно выполнить, он мне озвучил довольно сложный проект и довольно сжатые сроки. Ну я ему и рассказал — здесь вам понадобятся:
— Инженер-схемотехник, чтоб разработать схему и плату
— Программист фирмарщик для контроллеров и DSP
— Программист ПЛИС для, соответственно, ПЛИС
— Инженер-конструктор для проектирования корпуса и всякой механики.

Он меня выслушал, и заявляет: «А я думал вообще-то, что это все делает один человек, мы собирались одного нанимать». Я говорю: «При должном усердии вы, конечно, сможете найти такого человека, который в каждой из этих областей будет в нужной степени компетентен. Но сколько вы собираетесь ему платить?» На что он мне ответил: «Ну тысяч восемьдесят, не больше»

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

В целом статья была полезна тем, что я понял, что остальной инженерный мир работает так же)
Я почему-то не нашел в статье Rinspeed Oasis

http://www.rinspeed.eu/aktuelles.php?aid=20
1

Information

Rating
189-th
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity