У нас есть устройство, на котором мы рассматриваем возможность обновления программного обеспечения на голом металлическом микроконтроллере. Новый образ будет запрограммирован на все будущие продукты.
Если бы я должен был изменить компонент на устройстве, мне нужно было бы заполнить заказ на технические изменения.
Существует ли аналогичная отраслевая процедура при смене программного обеспечения?
Ответы:
Я бы все еще назвал это ЭКО.
Если на заводе микропрограмма запрограммирована в микропрограмму, эта микропрограмма и ее конкретная версия должны быть позицией в спецификации.
Смена прошивки означает изменение спецификации.
Изменение спецификации требует ЭКО.
Исходя из этого, обновление микропрограммы в полевых условиях должно следовать процессу, аналогичному процессу, который был бы применен, если бы модулю в полевых условиях требовался мод для аппаратного обеспечения.
Так что если вы называете это ECO, то это тоже ECO.
источник
Обычно изменение программного обеспечения называется исправлением или обновлением программного обеспечения. И, насколько я знаю (в зависимости от компании), процедуры называются Patch или процедурой обновления программного обеспечения.
Однако в большинстве случаев обновления программного обеспечения - это не более чем запуск специального приложения, которое заботится об установке, и все необходимые преобразования и т. Д. Являются частью патча.
Таким образом, в отличие от электронного обмена запчастями, никакое текущее существующее программное обеспечение обычно не нужно удалять или изменять, поскольку оно является частью самого программного обеспечения исправления.
Кроме того, в случае, если существуют ограничения или условия, когда исправление / обновление программного обеспечения может или не может быть установлено, оно будет проверено в самом исправлении и будет установлено только тогда, когда оно действительно для установки (или, по крайней мере, оно должно работать таким образом). ).
В принципе, обновление патча / программного обеспечения делает много вещей, например (возможно, не завершенных):
источник
Обычно я использую термины « Запрос на изменение» для вещей, которые необходимо изменить в связи с измененными требованиями, и « Отчет о проблемах» для вещей, которые необходимо изменить из-за ошибок.
Они собираются, а затем запланированы для определенных циклов обновления. Если цикл является только внутренним, он называется Milestone , а если он развернут для клиентов, он называется Release .
Типичная временная шкала имеет несколько этапов перед выпуском, которая называется Release Candidate, которая подвергается всестороннему тестированию, и любые обнаруженные там ошибки приводят к появлению дополнительных отчетов о проблемах, которые снова запланированы на следующий этап, если они достаточно важны, или на более поздний выпуск, если нет.
Также возможно создать филиал, который рассматривает только определенные PR в ответ на жалобы клиентов, с отдельным выпуском, который не имеет дальнейших изменений, в надежде, что здесь будет меньше ошибок. Обычно это делается только в том случае, если усилия по обновлению достаточно малы (например, поскольку обновления можно установить, просто подключив USB-накопитель с файлом с определенным именем на нем).
источник
Краткий ответ: Он встроен в систему управления версиями программного обеспечения.
Длинный ответ:
Программное обеспечение имеет тенденцию меняться гораздо быстрее, чем аппаратное обеспечение. Обычно программное обеспечение использует какую-то систему контроля версий (VCS), например, популярный Git. Большинство софтверных компаний, с которыми я работал, используют VCS для отслеживания изменений в программном обеспечении, причем каждый коммит объясняет причину изменения. Некоторые также используют систему отслеживания ошибок, которая отслеживает известные ошибки, улучшения и тому подобное. Обычно существует процесс, в котором разработка происходит в одной ветви, затем эта разработка тестируется перед объединением в «основную» (выпускную) ветку. Это имеет тенденцию быть намного более эффективным для высокой частоты изменений в разработке программного обеспечения по сравнению с более медленным темпом в оборудовании. Конкретная реализация и процесс этого варьируются от компании к компании и часто зависят от стандарта для целей обеспечения качества (ISO9001, AS9100D и т. Д.).
Пример:
Вы решили внести изменения.
Вы создаете проблему в трекере проблем.
источник
В правильно настроенном отраслевом параметре прошивка, которая должна быть записана в микро, сама является частью и имеет номер детали для этого конкретного исполняемого файла (шестнадцатеричный файл или любой другой). Если вы хотите изменить прошивку, это изменение спецификации (ведомости материалов). И это требует ECO так же, как если бы вы хотели заменить чип.
Это действительно так просто.
Есть следствие этого. Если ваша микропрограмма не имеет номера детали и не указана в спецификации и, следовательно, не контролируется, вероятно, процесс улучшения качества нуждается в улучшении. Если вы должны соответствовать ISO-9001 или чему-то подобному, это определенный пробел в вашем процессе, который необходимо устранить.
источник
Обновления программного обеспечения называются исправлениями или являются обновлениями программного обеспечения. Я всегда спрашиваю разработчиков программного обеспечения, обновлено ли устройство «до последней версии».
В идеале версионирование «подписывается» заинтересованными сторонами и тестируется перед его выпуском в производство, но чаще всего в большинстве случаев такая практика происходит только большую часть времени.
источник