Я увидел статью расходов "Тестирование, выявление недочетов, доработка, улучшение функционала" , поэтому подумал, что вы можете рассказать подробнее, что там происходило.
Как следует из названия, основная идея - как сэкономить на электронике, если делать её самим и превлечь фрилансеров. Есть упоминание примерной стоимости этапов разработки и подготовки производства, но не озвучены планы по производству. Потраченные рубли, к сожалению, не дают представления об экономии. Если это 1000 устройств в год, то одно, если 10000 - то совсем другое. Вклад этих разовых затрат будет совсем разный. Помимо этого хочется увидеть масштаб проекта в целом. Например: мы будем делать 10 000 устройств в год, 5 лет. Себестоимость изделия с учётом разработки $100, то есть весь объём выпуска $5M. Экономия $100 000 на R&D за счёт привлечения фрилансеров, составила 2% от всего проекта. А в итоге: по сравнению с закупкой n приборов в год от поставщика, мы вложили S собственных средств в разработку и производство, за счёт чего выиграли X с каждого прибора. В целом этот инвестпроект обеспечил нам доходность на вложенный капитал Y, окупаемость T лет.
Как будто пропущен вопрос контроля качества выпускаемой электроники, как с точки зрения верификации и сертификации, так и на серийном производстве.
Не все ваши мысли мне понятны, постараюсь ответить, где смог разобраться. Насколько я понял, вы занимаетесь построением тестовых решений на LabView, приобретая лицензии для каждой тестовой станции. По нашим исследованиям, большая часть продуктовых команд делают стенды сами, программируя на том, что им удобно(C, python,...). Наша целевая аудитория - такие команды, которые и так используют python в своём тестировании.
Я сходил по ссылке и посмотрел ваше рекламное видео. Вот примеры интерфейсов оператора из него:
Примеры интерфейсов пользователя
Если вы прочитали статью, то заметили, что предлагаемый фреймворк как раз даёт возможность получить панель оператора, когда тесты написаны на python. На рабочей станции запускается не LabView, а HardPy, вот и вся разница. Для вашего удобства приведу пример интерфейса из статьи:
Интерфейс оператора HardPy
На наш взгляд, подробное информирование оператора стенда о результатах всех измерений (например, напряжение до десятков мВ) избыточно в большинстве случаев. Возможно, это полезно при ремонте дефектных изделий или отладке.
Пример избыточного интерфейса тестирования
Мне показалось, что вы имеете в виду, что на производстве сами меняют тестовый план, поэтому нужно иметь визуальный инструмент автоматизации. Нам эта позиция не близка, заказчик должен контролировать объём и глубину тестирования, на производстве доступа к модификации тестового ПО и железа быть не должно.
Про критику отдельных шагов тестирования и план тестирования в целом - статья не про это, пример может быть любым.
P.S.Ваши высказывания о людях другой национальности это, конечно, дно.
Переключились с Микрософт экосистемы на Яндекс 360. Диск вообще сырой, шеринг папок работает плохо. Если хочешь освободить лицензию-удаляй сотрудника, данные при этом улетают безвозвратно. В общем, пока грустно.
Стенд сравнивает желаемое состояние на всех входах при последовательном переборе выходов. Таким образом могут быть не только найдены КЗ с соседними, но и отсутствие нужного контакта при нескольких отводах.
Эта технология ICT flying probes широко распространена. В РФ у некоторых контрактников они есть. Стоимость и время такого тестирования весьма велики. Помимо этого, ICT не даёт проверить функции устройства, наличие правильных компонентов не гарантирует работоспособности устройства в целом.
Не знаю статистики, но я сам не с детства этим занимаюсь. Да и направление тоже совсем не в embedded- электротехника, электромеханика и электротехнологии. Удачно попал на практику к хорошим людям, загорелся всеми этими микроконтроллерами)
В моём понимании продуктовая модель-это не следующий уровень, а другая модель. Со своими плюсами и минусами. Сейчас у нас есть продукт - Robster, решение для систем функционального тестирования на производстве электроники. Если есть желание сделать что-то вместе-пишите в личку.
Верно, один универсал может делать работу эффективнее. Особенно, одарённый. Однако, более-менее сложные проекты так делать не получится просто ввиду их большой трудоёмкости. Помимо этого, специализация ведёт к углублению экспертизы, это значит, что, при прочих равных, универсал сделает хуже команды. Наличие нескольких людей одной специализации даёт возможность делать ревью, что тоже положительно сказывается на качестве.
Верно, но автор написал свою прошивку, без использования оригинальной. Если задействовано только железо pas~, должен ли автор раскрыть код? По мне, закрытость прошивки делает её бесполезной для всех кроме автора.
Это всё за 50к?
Я увидел статью расходов "Тестирование, выявление недочетов, доработка, улучшение функционала" , поэтому подумал, что вы можете рассказать подробнее, что там происходило.
Спасибо за статью. Есть пара соображений:
Как следует из названия, основная идея - как сэкономить на электронике, если делать её самим и превлечь фрилансеров. Есть упоминание примерной стоимости этапов разработки и подготовки производства, но не озвучены планы по производству. Потраченные рубли, к сожалению, не дают представления об экономии. Если это 1000 устройств в год, то одно, если 10000 - то совсем другое. Вклад этих разовых затрат будет совсем разный. Помимо этого хочется увидеть масштаб проекта в целом. Например: мы будем делать 10 000 устройств в год, 5 лет. Себестоимость изделия с учётом разработки $100, то есть весь объём выпуска $5M. Экономия $100 000 на R&D за счёт привлечения фрилансеров, составила 2% от всего проекта. А в итоге: по сравнению с закупкой n приборов в год от поставщика, мы вложили S собственных средств в разработку и производство, за счёт чего выиграли X с каждого прибора. В целом этот инвестпроект обеспечил нам доходность на вложенный капитал Y, окупаемость T лет.
Как будто пропущен вопрос контроля качества выпускаемой электроники, как с точки зрения верификации и сертификации, так и на серийном производстве.
Не все ваши мысли мне понятны, постараюсь ответить, где смог разобраться. Насколько я понял, вы занимаетесь построением тестовых решений на LabView, приобретая лицензии для каждой тестовой станции. По нашим исследованиям, большая часть продуктовых команд делают стенды сами, программируя на том, что им удобно(C, python,...). Наша целевая аудитория - такие команды, которые и так используют python в своём тестировании.
Я сходил по ссылке и посмотрел ваше рекламное видео. Вот примеры интерфейсов оператора из него:
Если вы прочитали статью, то заметили, что предлагаемый фреймворк как раз даёт возможность получить панель оператора, когда тесты написаны на python. На рабочей станции запускается не LabView, а HardPy, вот и вся разница. Для вашего удобства приведу пример интерфейса из статьи:
На наш взгляд, подробное информирование оператора стенда о результатах всех измерений (например, напряжение до десятков мВ) избыточно в большинстве случаев. Возможно, это полезно при ремонте дефектных изделий или отладке.
Мне показалось, что вы имеете в виду, что на производстве сами меняют тестовый план, поэтому нужно иметь визуальный инструмент автоматизации. Нам эта позиция не близка, заказчик должен контролировать объём и глубину тестирования, на производстве доступа к модификации тестового ПО и железа быть не должно.
Про критику отдельных шагов тестирования и план тестирования в целом - статья не про это, пример может быть любым.
P.S.Ваши высказывания о людях другой национальности это, конечно, дно.
Переключились с Микрософт экосистемы на Яндекс 360. Диск вообще сырой, шеринг папок работает плохо. Если хочешь освободить лицензию-удаляй сотрудника, данные при этом улетают безвозвратно. В общем, пока грустно.
Стенд сравнивает желаемое состояние на всех входах при последовательном переборе выходов. Таким образом могут быть не только найдены КЗ с соседними, но и отсутствие нужного контакта при нескольких отводах.
Эта технология ICT flying probes широко распространена. В РФ у некоторых контрактников они есть. Стоимость и время такого тестирования весьма велики. Помимо этого, ICT не даёт проверить функции устройства, наличие правильных компонентов не гарантирует работоспособности устройства в целом.
Не знаю статистики, но я сам не с детства этим занимаюсь. Да и направление тоже совсем не в embedded- электротехника, электромеханика и электротехнологии. Удачно попал на практику к хорошим людям, загорелся всеми этими микроконтроллерами)
Спасибо!
В моём понимании продуктовая модель-это не следующий уровень, а другая модель. Со своими плюсами и минусами. Сейчас у нас есть продукт - Robster, решение для систем функционального тестирования на производстве электроники. Если есть желание сделать что-то вместе-пишите в личку.
Верно, мы используем Agile подход в разработке Embedded. Это требует постоянной синхронизации с заказчиком, что как раз хорошо получается на T&M.
Верно, один универсал может делать работу эффективнее. Особенно, одарённый. Однако, более-менее сложные проекты так делать не получится просто ввиду их большой трудоёмкости. Помимо этого, специализация ведёт к углублению экспертизы, это значит, что, при прочих равных, универсал сделает хуже команды. Наличие нескольких людей одной специализации даёт возможность делать ревью, что тоже положительно сказывается на качестве.
Внимание. Мероприятие не может принять всех, надо предварительно регистрироваться, просто так прийти не получится.
https://t.me/thirdpin/683 Красногорск, 12 апреля!
автомобиль, хотя ноутбук тоже подходит
Не ясно, в чём страдание по UART, если есть разъём программатора?
Верно, но автор написал свою прошивку, без использования оригинальной. Если задействовано только железо pas~, должен ли автор раскрыть код? По мне, закрытость прошивки делает её бесполезной для всех кроме автора.
Спасибо за действительно независимую обратную связь! Исправлять мы, конечно, ничего не будем.
Видео не нужно, нужно нажать F1. https://keepass.info/help/base/autotype.html
Попробуйте установить параметр автоввода в базе keepass.