В большинстве проектов промышленного Интернета вещей (IIoT) заказчики используют контроллеры, с которыми работали раньше или рекомендованные поставщиками систем верхнего уровня. При этом счет IIoT контроллеров на рынке, из которых можно выбирать, идет на тысячи.
Не всем известна опция разработки оборудования на заказ. Для большинства промышленных контроллеров не нужен «дальний космос» в виде уникального функционала или дизайнерского корпуса. При удачном выборе подрядчика, имеющего необходимые наработки, за 2-3 месяца можно сделать опытные образцы, а еще через пару месяцев — начать серийное производство. Разработка может окупиться за счет использования недорогой элементной базы и реализации нужного количества функций под конкретный проект. Комплекс оборудования на объекте будет состоять из минимального количества устройств (часто одного), а значит будет меньше работ по сборке, установке и пуско-наладке.
Заказная разработка «железа» давно не является уделом избранных заказчиков с огромными бюджетами. Однако, имеется ряд особенностей, с которыми лучше ознакомиться насобственном чужом опыте до начала проекта.
Можно серьезно сэкономить, подобрав оборудование под проект, например, на этом сервисе.
Выбранный контроллер должен быть совместим с системой верхнего уровня и поддерживать работу со всеми объектовыми устройствами. За исключением закрытых решений единственного производителя, вопрос совместимости решается либо поддержкой необходимых протоколов в контроллере (силами его разработчика), либо поддержкой в системе верхнего уровня протоколов, «зашитых» в контроллер.
Поиск на данном этапе может оказаться неудачным. Тогда он превратится в «обзор рынка», что точно не повредит. Особенно, если в итоге будет принято решение начать разработку собственного устройства. А удачные технические решения, применяемые в готовых изделиях,стоит необходимо брать за основу. Ведь по-настоящему классных идей не так много.
Если решено разработать собственное оборудование и под боком нет исполнителей, пора искать подрядчика. Оптимально начать с компаний, уже выпускающих то, что нужно. Важно понять, нужны ли права на разработку, исходники конструкторской документации (КД) и встроенного программного обеспечения (ВПО), либо достаточно иметь эксклюзив (на территорию внедрения, дизайн, …). Компании-разработчики могут отказаться от работы на условиях, интересующих заказчика, либо предложить заградительные цены. Самым дешевым вариантом может оказаться не полноценная разработка, а доработка или OEM поставка оборудования под вашим брендом. Однако, и этот вариант несет в себе риск – можно вырастить себе конкурента.
Если договориться не получилось, надо искать подрядчика по рекомендациям, либо в Сети по запросу «контрактная разработка электроники». В помощь к работе с кандидатами вопросы из чек-листа ниже.
Для предварительно выбранного подрядчика(ов) надо сформулировать первичные требования к оборудованию. Чем детальнее будут требования, тем проще будет определить стоимость работ и время разработки образцов. Также можно показать подрядчику(ам) интересующие примеры готового оборудования.
Со встречи с потенциальным партнером надо уходить с ответом на вопрос «когдасколькопочем?». Об этом часто забывают. Ожидания заказчика (цены, сроки) могут оказаться сильно меньше запросов подрядчика. Если в итоге их удалось синхронизировать, можно переходить к согласованию:
Не все можно зафиксировать в договоре. Подрядчик может объявить «итальянскую забастовку», за которую его нельзя будет наказать. Также могут возникнуть непредвиденные сложности или новые требования, по которым придется работать больше, чем договаривались. Для того, чтобы защититься от перечисленных проблем, можно использовать простые принципы:
Только полное соответствие результата разработки ТЗ является основанием для приемки работ и окончательной оплаты. Внесение изменений в требования после заключения договора может быть болезненным, поэтому очень важно ответственно поработать над текстом ТЗ с обеих сторон. Цена ошибки на последующих этапах будет существенно выше.
Как известно, «устройство должно работать не в принципе, а в корпусе». Старт обсуждения ТЗ с корпуса, позволит обеим сторонам представить с первых минут, что за устройство получится в итоге.
Для каждого применения и проекта оптимален свой форм-фактор:
Часто конструктив выбирают по аналогии с готовыми устройствами (с рынка). В некоторых случаях это является ошибкой, поскольку дорогой фирменный корпус (с обработкой, маркировкой, системой соединителей и пр.) может стоить до 50% от себестоимости изделия. Для справки: аналогичная доля для бюджетного корпуса может составлять менее 5%.
В бюджетных устройствах обычно используют однокристальные микроконтроллеры (MCU), с оперативной памятью (RAM) и ПЗУ (Flash) в одном корпусе. Большинство устройств «тянет» компактную операционную систему (ОС) типа FreeRTOS или TNKernel, а может работать и без ОС. Будем называть их RTOS контроллерами.
В более мощных контроллерах используется процессор (CPU) с внешними микросхемами RAM и Flash. Большинство таких устройств использует различные версии ОС Linux (Linux контроллеры) или менее распространенные ОС типа VхWorks или Windows CE (здесь не рассматриваем). Сделать плату на современном процессоре не так просто: на плате от 4-х до 10-ми слоев нужно расположить несколько BGA корпусов с достаточно строгими требованиями к питанию, геометрии и длинам дорожек. Для упрощения жизни разработчиков предлагаются сотни процессорных модулей, которые могут быть выполнены в виде дочерней платы с разъемами или краевыми контактами под пайку (см. ниже).
Также на рынке появляются микросхемы System on chip (SoC), содержащие процессор и память большого объема, достаточную для работы Linux. Разводка SoC значительного проще, чем набора CPU+RAM+FLASH. Кроме этого, SoC-и могут быть очень бюджетными.
Ниже приведены типовые характеристики и цены для нескольких примеров процессорных ядер от ARM, которые могут быть использованы в IIoT контроллерах.
Часто оправдано использование в одном контроллере двух процессоров: мощного для ресурсоемких приложений и небольшого однокристального – для простых приложений реального времени.
В зависимости от типа объектов определяются требования к блоку питания, который может быть, как внешним, так и встроенным в устройство:
Изолированный блок питания часто выходит из строя из-за высыхания электролитических конденсаторов. Был случай, когда массовая поломка оборудования произошла буквально через полгода после начала эксплуатации. По этой причине подрядчик должен иметь опыт по разработке систем питания и знать их «болевые точки», … либо использовать дорогие преобразователи, качество которых гарантировано именем производителя.
Для многих задач требуется резервное питание от одной минуты (краткосрочный резерв, чтобы послать сигнал о пропадании питания) до нескольких часов/дней (охрана и промышленная безопасность). Для реализации краткосрочного резервирования сегодня популярны суперконденсаторы со сроком жизни до 15-ти лет и устойчивостью к отрицательным температурам. Для длительного резервирования нужны аккумуляторы, как правило, на основе лития.
Для всех российских устройств необходимы сертификаты ЕАС на электробезопасность и электромагнитную совместимость. Для прохождения испытаний нужно уметь проектировать фильтры и топологию плат, а также правильно выбирать компоненты.
Распространенные интерфейсы, используемые в IIoT контроллерах, показаны в таблице ниже. Выбор типов и количеств — под задачу и бюджет.
* может использоваться и для локальной связи c оборудованием на объекте
Для подключения датчиков контроллеры оснащаются дискретными, счетными и аналоговыми входами. Аналоговые входы могут быть потенциальными (например, на 0..10VDC или изолированными на 220VAC), либо токовыми (4..20mA, NAMUR, «пожарными»). Для реализации выходов используют реле (обычные и полупроводниковые, например, оптосимисторы), а также транзисторы, включенные по схеме «открытый коллектор» (ОК).
В случае использования длинных линий, либо при наличии специальных требований, входы и выходы могут выполняться с индивидуальной или групповой гальванической изоляцией.
Для уменьшения габаритов и экономии разъемов используют универсальные порты, выполняющие разные функции в зависимости от настроек, и использующие одни и те же контакты. Например, дискретный вход с функцией выхода ОК.
Продолжительное время в IIoT устройствах было достаточно использовать несколько светодиодов. В более продвинутых контроллерах использовали «телевизоры» — линейки семисегментных LED индикаторов, электролюминесцентные, текстовые или графические LCD индикаторы. Но от «телевизоров» чаще все-таки отказывались из-за их дороговизны и небольшой пользы при эксплуатации.
Сегодня «телевизоры» стали модными буквально везде: от автомобилей до «умных домов». Появляется все больше конкурсов, в которых наличие экрана обязательно и для IIoT устройств.
Хорошая новость в том, что стоимость LCD или OLED индикаторов уменьшается, а мощность процессоров, необходимая для графического вывода, растет. По этой причине «телевизор» перестает быть дорогой опцией.
Хорошей практикой является разработка не одного устройства, а целой линейки. В минимуме для этого требуется разработка всего одной платы, рассчитанной на максимальную комплектацию. Другие, более бюджетные, версии будут паяться на той же плате, но из меньшего количества деталей. Часть платы будет пустой, но это не проблема (текстолит стоит недорого).
Советую добавить этот пункт в ТЗ.
Разработка ВПО может занимать до 80% от времени реализации всего проекта. Поскольку данный пост про «железо», ограничусь перечислением основных функций, которые должны быть реализованы практически в любом IIoT контроллере:
Если ТЗ согласовано, пора подписывать договор с приложениями (ТЗ, календарный план с ценами, методика испытаний, …) и приступать к реализации.
Разработка нового IIoT контроллера – это сравнительно небольшой проект, для успеха которого, тем не менее, нужна слаженная работа сотрудников заказчика и исполнителя. Со стороны заказчика сразу нужен руководитель проекта, а позже – инженер(ы) тестирования (без независимого тестирования продукта не сделать). Более того, обычно разработка передается на условиях «As is». После подписания актов и оплаты работ доказать необходимость исправления по гарантии сложно.
Про проектное управление написаны сотни книг. В разрезе разработки контроллеров я выделяю следующие обязательные моменты:
Хорошие формы документов по проектному управлению здесь.
Нельзя сделать отличную работу с руками в карманах. Нужно много работать, рисковать и иногда выходить за рамки.
Одна из таких возможностей для IIoT проекта — применение заказных контроллеров. Для ее реализации заказчику нужно пройти путь из трех быстрых шагов:
Далее предстоит работа с выбранным подрядчиком: разработка опытных образцов, производство и поддержка. Цены на заказные контроллеры, их монтаж и пуско-наладку могут быть значительно ниже по сравнению с использованием готового оборудования. Дополнительными ценностями для заказчика будут:
Не всем известна опция разработки оборудования на заказ. Для большинства промышленных контроллеров не нужен «дальний космос» в виде уникального функционала или дизайнерского корпуса. При удачном выборе подрядчика, имеющего необходимые наработки, за 2-3 месяца можно сделать опытные образцы, а еще через пару месяцев — начать серийное производство. Разработка может окупиться за счет использования недорогой элементной базы и реализации нужного количества функций под конкретный проект. Комплекс оборудования на объекте будет состоять из минимального количества устройств (часто одного), а значит будет меньше работ по сборке, установке и пуско-наладке.
Заказная разработка «железа» давно не является уделом избранных заказчиков с огромными бюджетами. Однако, имеется ряд особенностей, с которыми лучше ознакомиться на
Шаг 1. А есть ли готовое?
Можно серьезно сэкономить, подобрав оборудование под проект, например, на этом сервисе.
Выбранный контроллер должен быть совместим с системой верхнего уровня и поддерживать работу со всеми объектовыми устройствами. За исключением закрытых решений единственного производителя, вопрос совместимости решается либо поддержкой необходимых протоколов в контроллере (силами его разработчика), либо поддержкой в системе верхнего уровня протоколов, «зашитых» в контроллер.
Поиск на данном этапе может оказаться неудачным. Тогда он превратится в «обзор рынка», что точно не повредит. Особенно, если в итоге будет принято решение начать разработку собственного устройства. А удачные технические решения, применяемые в готовых изделиях,
Шаг 2. Выбор подрядчика: «КогдаСколькоПочем» и защита от «итальянской забастовки»
Если решено разработать собственное оборудование и под боком нет исполнителей, пора искать подрядчика. Оптимально начать с компаний, уже выпускающих то, что нужно. Важно понять, нужны ли права на разработку, исходники конструкторской документации (КД) и встроенного программного обеспечения (ВПО), либо достаточно иметь эксклюзив (на территорию внедрения, дизайн, …). Компании-разработчики могут отказаться от работы на условиях, интересующих заказчика, либо предложить заградительные цены. Самым дешевым вариантом может оказаться не полноценная разработка, а доработка или OEM поставка оборудования под вашим брендом. Однако, и этот вариант несет в себе риск – можно вырастить себе конкурента.
Если договориться не получилось, надо искать подрядчика по рекомендациям, либо в Сети по запросу «контрактная разработка электроники». В помощь к работе с кандидатами вопросы из чек-листа ниже.
Для предварительно выбранного подрядчика(ов) надо сформулировать первичные требования к оборудованию. Чем детальнее будут требования, тем проще будет определить стоимость работ и время разработки образцов. Также можно показать подрядчику(ам) интересующие примеры готового оборудования.
Со встречи с потенциальным партнером надо уходить с ответом на вопрос «когдасколькопочем?». Об этом часто забывают. Ожидания заказчика (цены, сроки) могут оказаться сильно меньше запросов подрядчика. Если в итоге их удалось синхронизировать, можно переходить к согласованию:
- тезисной концепции: ТЗ крупными мазками, сроки, стоимость разработки,
- цен на изделия в партиях, сроков поставки,
- условий договора (права, исходники, эксклюзив).
Не все можно зафиксировать в договоре. Подрядчик может объявить «итальянскую забастовку», за которую его нельзя будет наказать. Также могут возникнуть непредвиденные сложности или новые требования, по которым придется работать больше, чем договаривались. Для того, чтобы защититься от перечисленных проблем, можно использовать простые принципы:
- При выборе подрядчика обязателен человеческий контакт. Идеальных заказчиков и подрядчиков не бывает, но совершенно реально найти партнера с которым будет комфортно работать именно вам.
- Отлично, если подрядчик проявляет инициативу и искренне «болеет» за дело (можно понять по ответу на вопрос «как решали серьезные проблемы в прошлом?»).
- Подрядчик должен быть управляемым. Соответственно, он должен слушать и слышать заказчика, а не только себя.
Чек-лист выбора подрядчика
| Требование | Оценка |
| Предварительное попадание в сроки и бюджет | |
| Человеческий контакт – достигнута ли синергия с заказчиком или постоянно на «разных волнах» | |
| Готовность предоставления исходников (КД, тексты ВПО), прав, эксклюзива по продаже (по необходимости) | |
| Соответствие портфолио / услуг (опыта подрядчика) задаче | |
| Наличие достойных примеров борьбы с проблемами | |
| Наличие необходимых специалистов в команде | |
| Наличие шаблонов документов (договор, ТЗ, руководства, …) | |
| Увлеченность делом: интересные идеи, инициативность, ответственность | |
| Желание разобраться в специфике, умение слушать |
Шаг 3. Согласование ТЗ на IIoT контроллер
Только полное соответствие результата разработки ТЗ является основанием для приемки работ и окончательной оплаты. Внесение изменений в требования после заключения договора может быть болезненным, поэтому очень важно ответственно поработать над текстом ТЗ с обеих сторон. Цена ошибки на последующих этапах будет существенно выше.
Согласование типа конструктива
Как известно, «устройство должно работать не в принципе, а в корпусе». Старт обсуждения ТЗ с корпуса, позволит обеим сторонам представить с первых минут, что за устройство получится в итоге.
Для каждого применения и проекта оптимален свой форм-фактор:
- Для энергетики, промышленной автоматики и учета ресурсов используют корпуса на DIN рейку 35мм. Пожалуй, это самый популярный формат для промышленного IoT, однако, не является «серебряной пулей» для всех случаев;
- Для систем связи используют модули в 19’ стойку. Они бывают различной высоты, которую измеряют в U (44,45 мм).
- В 19’ стойку также могут устанавливать крейты (или кассеты). В них вставляют нужное количество модулей, конструктив которых объединяют понятием «Евромеханика».
- Для контроля доступа и размещения отдельно стоящих компактных устройств применяют корпуса в настольном и/или настенном исполнении,
- Существует специализированные корпуса, в том числе: антивандальные, защищенные от воды и пыли (по международным кодам IP), приборные и т.п.
- Наконец, бывают устройства без корпуса, устанавливаемые внутрь бОльших устройств, либо устройства, состоящие из платы и передней панели (в частности, модули Евромеханики).
Часто конструктив выбирают по аналогии с готовыми устройствами (с рынка). В некоторых случаях это является ошибкой, поскольку дорогой фирменный корпус (с обработкой, маркировкой, системой соединителей и пр.) может стоить до 50% от себестоимости изделия. Для справки: аналогичная доля для бюджетного корпуса может составлять менее 5%.
Выбор процессорного ядра
В бюджетных устройствах обычно используют однокристальные микроконтроллеры (MCU), с оперативной памятью (RAM) и ПЗУ (Flash) в одном корпусе. Большинство устройств «тянет» компактную операционную систему (ОС) типа FreeRTOS или TNKernel, а может работать и без ОС. Будем называть их RTOS контроллерами.
В более мощных контроллерах используется процессор (CPU) с внешними микросхемами RAM и Flash. Большинство таких устройств использует различные версии ОС Linux (Linux контроллеры) или менее распространенные ОС типа VхWorks или Windows CE (здесь не рассматриваем). Сделать плату на современном процессоре не так просто: на плате от 4-х до 10-ми слоев нужно расположить несколько BGA корпусов с достаточно строгими требованиями к питанию, геометрии и длинам дорожек. Для упрощения жизни разработчиков предлагаются сотни процессорных модулей, которые могут быть выполнены в виде дочерней платы с разъемами или краевыми контактами под пайку (см. ниже).
Также на рынке появляются микросхемы System on chip (SoC), содержащие процессор и память большого объема, достаточную для работы Linux. Разводка SoC значительного проще, чем набора CPU+RAM+FLASH. Кроме этого, SoC-и могут быть очень бюджетными.
Ниже приведены типовые характеристики и цены для нескольких примеров процессорных ядер от ARM, которые могут быть использованы в IIoT контроллерах.
Часто оправдано использование в одном контроллере двух процессоров: мощного для ресурсоемких приложений и небольшого однокристального – для простых приложений реального времени.
Согласование требований к системе питания
В зависимости от типа объектов определяются требования к блоку питания, который может быть, как внешним, так и встроенным в устройство:
- домашнее/офисное применение, энергетика – ~220/380В,
- телеком – 36…72В (станционное питание) и PoE,
- промышленная автоматизация – 18...36В,
Изолированный блок питания часто выходит из строя из-за высыхания электролитических конденсаторов. Был случай, когда массовая поломка оборудования произошла буквально через полгода после начала эксплуатации. По этой причине подрядчик должен иметь опыт по разработке систем питания и знать их «болевые точки», … либо использовать дорогие преобразователи, качество которых гарантировано именем производителя.
Для многих задач требуется резервное питание от одной минуты (краткосрочный резерв, чтобы послать сигнал о пропадании питания) до нескольких часов/дней (охрана и промышленная безопасность). Для реализации краткосрочного резервирования сегодня популярны суперконденсаторы со сроком жизни до 15-ти лет и устойчивостью к отрицательным температурам. Для длительного резервирования нужны аккумуляторы, как правило, на основе лития.
Для всех российских устройств необходимы сертификаты ЕАС на электробезопасность и электромагнитную совместимость. Для прохождения испытаний нужно уметь проектировать фильтры и топологию плат, а также правильно выбирать компоненты.
Порты связи
Распространенные интерфейсы, используемые в IIoT контроллерах, показаны в таблице ниже. Выбор типов и количеств — под задачу и бюджет.
| Для связи через IP сеть | Для связи через промежуточный HUB | Для локальной связи на объекте |
| *Wired Ethernet | *RS485 / 422 | RS232 |
| Cell 2G/GPRS … 4G/LTE | *CAN | USB |
| Optical Ethernet | PLC (G3, Prime) | 1-wire, s-wire (для цифровых датчиков) |
| Optical GPON | Radio: LoRA, NB-Fi (Rus), UNB | Radio: Zigbee, 6loWPAN, ISM 433/868/2400 Mhz |
* может использоваться и для локальной связи c оборудованием на объекте
Входы и выходы
Для подключения датчиков контроллеры оснащаются дискретными, счетными и аналоговыми входами. Аналоговые входы могут быть потенциальными (например, на 0..10VDC или изолированными на 220VAC), либо токовыми (4..20mA, NAMUR, «пожарными»). Для реализации выходов используют реле (обычные и полупроводниковые, например, оптосимисторы), а также транзисторы, включенные по схеме «открытый коллектор» (ОК).
В случае использования длинных линий, либо при наличии специальных требований, входы и выходы могут выполняться с индивидуальной или групповой гальванической изоляцией.
Для уменьшения габаритов и экономии разъемов используют универсальные порты, выполняющие разные функции в зависимости от настроек, и использующие одни и те же контакты. Например, дискретный вход с функцией выхода ОК.
Индикация
Продолжительное время в IIoT устройствах было достаточно использовать несколько светодиодов. В более продвинутых контроллерах использовали «телевизоры» — линейки семисегментных LED индикаторов, электролюминесцентные, текстовые или графические LCD индикаторы. Но от «телевизоров» чаще все-таки отказывались из-за их дороговизны и небольшой пользы при эксплуатации.
Сегодня «телевизоры» стали модными буквально везде: от автомобилей до «умных домов». Появляется все больше конкурсов, в которых наличие экрана обязательно и для IIoT устройств.
Хорошая новость в том, что стоимость LCD или OLED индикаторов уменьшается, а мощность процессоров, необходимая для графического вывода, растет. По этой причине «телевизор» перестает быть дорогой опцией.
Модельный ряд
Хорошей практикой является разработка не одного устройства, а целой линейки. В минимуме для этого требуется разработка всего одной платы, рассчитанной на максимальную комплектацию. Другие, более бюджетные, версии будут паяться на той же плате, но из меньшего количества деталей. Часть платы будет пустой, но это не проблема (текстолит стоит недорого).
Советую добавить этот пункт в ТЗ.
Требования к встроенному программному обеспечению
Разработка ВПО может занимать до 80% от времени реализации всего проекта. Поскольку данный пост про «железо», ограничусь перечислением основных функций, которые должны быть реализованы практически в любом IIoT контроллере:
- Обмен данными с системой верхнего уровня, в том числе, передача экстренных оповещений;
- Обмен данными с нижестоящими устройствами и датчиками;
- Управление исполнительными механизмами;
- Обновление ВПО с защитой от перебоев питания и связи;
- Хранение настроек и их восстановление;
- Администрирование устройства с защитой от несанкционированного доступа;
- Ведение журналов событий;
- Анализ данных и формирования воздействий и событий (Edge логика);
- Синхронизация системного времени;
Проектная работа с подрядчиком
Если ТЗ согласовано, пора подписывать договор с приложениями (ТЗ, календарный план с ценами, методика испытаний, …) и приступать к реализации.
Разработка нового IIoT контроллера – это сравнительно небольшой проект, для успеха которого, тем не менее, нужна слаженная работа сотрудников заказчика и исполнителя. Со стороны заказчика сразу нужен руководитель проекта, а позже – инженер(ы) тестирования (без независимого тестирования продукта не сделать). Более того, обычно разработка передается на условиях «As is». После подписания актов и оплаты работ доказать необходимость исправления по гарантии сложно.
Про проектное управление написаны сотни книг. В разрезе разработки контроллеров я выделяю следующие обязательные моменты:
- В начале работ нужен устав проекта (цели, проектная команда, деньги, сроки, …), и календарный план;
- В процессе реализации необходим периодический контроль календарного плана и его корректировка;
- Если в процессе работ внедряются хорошие идеи или новые требования, которых не было в ТЗ, то их надо вносить в реестр изменений. Ценность таких идей может значительно превышать дополнительную стоимость (обычно до 10% от первоначальной стоимости работ).
- По результатам испытаний нужны протоколы, которые будут использоваться, как основание для доработок и оплат.
- Хорошей практикой является подведение итога по проекту после его завершения. Часто этот момент пропускают, хотя итоговый отчет – прекрасная страховка от «граблей» в будущих аналогичных проектах, а также основание для
наказания невиновныхнаграждения героев.
Хорошие формы документов по проектному управлению здесь.
Заключение
Нельзя сделать отличную работу с руками в карманах. Нужно много работать, рисковать и иногда выходить за рамки.
Одна из таких возможностей для IIoT проекта — применение заказных контроллеров. Для ее реализации заказчику нужно пройти путь из трех быстрых шагов:
- анализ рынка,
- выбор подрядчика (например, нас),
- согласование ТЗ.
Далее предстоит работа с выбранным подрядчиком: разработка опытных образцов, производство и поддержка. Цены на заказные контроллеры, их монтаж и пуско-наладку могут быть значительно ниже по сравнению с использованием готового оборудования. Дополнительными ценностями для заказчика будут:
- развитие собственного бренда,
- реализация специфического набора аппаратных функций и
- получение статуса отечественного производителя (актуально для участия в конкурсах).
lelik363
Фантастические сроки… Поставка комплектующих начинается от 4-6 недель.
Где гарантия, что сделают? А испытания, сертификация?
lkarpenko Автор
Сроки действительно сжатые, но не невозможные.
Например, для нашего GIC-2 все компоненты можно купить в РФ (Компэл, МТ-Систем, ДАРТ и т.п.) за 1..2 недели.
Если разрабатывать не что-то принципиально новое, то это 1-2 месяца на КД (конструкция, схема, плата). Еще 2 недели на закупки компонентов и производство плат (Резонит). Образцы паяются вручную — 2 недели с логистикой и очередью.
Написание ПО: можно начать почти сразу (на отладках или на своих же железках, если процессор тот же). Если все технологии известны, то за 3 мес. можно уложиться, чтобы сделать опытные образцы.
Испытания: если говорить про честную сертификацию ЕАС (ЭМС + ЭБ) с написанием ТУ, то это 1.5 мес. Конечно, есть более долгие и дорогие сертификации, но мы же за минимальные сроки с Вами говорим.
Далее за 2 мес. делается редизайн (исправление мелких ошибок) и готовится система производственного тестирования (физически тестеры, софт, стойки для прогона) и выпускается установочная партия. В начале 6-го месяца можно приступать к производству.
Еще раз: это оптимистичный сценарий. Но что по-крупному я забыл?
nckma
А как решается вопрос с исходниками фирмваре? И с доведением функционала, исправлением программных багов или апдейтов на местах?
Апдейт — это критическое действие, кто имеет права на выполнение апдейта и какова процедура?
lkarpenko Автор
У нас все просто. В большинстве проектов мы делаем обновление одним куском. Может делать пользователь с правами администратора.
Для Linux проектов делали частичное обновление, но использовали для собственной отладки. Для серии экономили память — стоимость.
Если я понял правильно, у вас применение — критическая инфраструктура. Там, кроме описанного вами, нужны соответствующие сертификаты. Для таких применений мы сейчас обсуждаем партнерство по инфобезопасности. Если договоримся, будем ставить из сертифицированную ось на защищенные устройства. Там с обновлениями, соответствующими проверками и ключами все серьезно (вплоть до «Сов.секретно»), но мы на начальной стадии в этом проекте.
nixtonixto
Вы не учли, что любое отклонение от имеющихся у вас заготовок — это месяцы работы. Клиенту надо MQTT а у вас его нет — пол-года работы на написание и отладку (учитывая, что программисты вашей компании занимаются ещё кучей другой работы на поддержку и апгрейд предыдущих проектов). Понадобилось SSL — отдаём приказ монтажникам выпаивать из макетов процы ф1 и впаивать ф4 с большой ОЗУ и пол-года впиливаем чужие кое-как работающие библиотеки… Про ТЗ, которое правится клиентом ВСЕГДА, даже после релиза — промолчу… Случилась как сейчас внезапная остановка производства СТМ32 — тратим месяцы на поиск и тестирование китайских аналогов СТМ32 или подбираем из АТсам и др… Ну-ка, скажите, где и по какой цене вы Сейчас купите СТМ32 для вашего gic-2 в количестве пары тысяч штук?
В итоге на бумаге вроде всё сходится, но реально такие сроки умножаются на 2...3. Год на запуск нового проекта уровня среднего ПЛК — это очень быстро, причём глюки и правки будут ещё год.
lkarpenko Автор
Статья не про нас персонально и не содержит ничего про серийное производство.
1-м пунктом совет искать партнера с опытом по тому, что нужно. У нас нет опыта по всему на свете точно.
Я согласен, что по абсолютно незнакомой теме можно работать год. А если «точить» самостоятельно серьезный стек, то и через 3 года он может плохо работать (видел такое).
Новый процессор — однозначно +3..6 месяцев.
ТЗ правится в процессе почти всегда, я разве об этом не написал? (поищите там, где про «10%»). А вот чтобы серьезно менялось — не соглашусь, хотя, может быть мне везет?
С чем не согласен:
1. MQTT мы поднимали около 2х мес.
2. Сразу после окончания разработки я не видел проектов, где нужно 2К шт. сделать (до этого количества продажи должны разгоняться 1-2 года). Но, если вдруг такой проект будет, то заказывать комплектацию надо будет сразу после финализации схемы — т.е. в запасе есть 4 мес., за которые можно купить 2К любых процессоров. (Если совсем дефицит — по завышенной цене и экспресс-доставкой, но можно).
3. Если найдена компания, которая делает почти то, что нужно заказчику, ОНА может уложиться в указанные сроки в оптимистичном сценарии. Во всяком случае мы укладывались.