В этом посте три варианта текста, первый мой, второй – с ИИ, третий – с существенным уточнением и пошаговым критическим разбором ИИ.
1
Примените схему заземления к имеющейся рабочей задаче, в ситуации, где, по вашему мнению, что-то уже идёт не так или что-то имеет все шансы пойти не так. Составьте первую версию описания задачи.
В системе “HW scaling” существует терминальное состояние, в котором система оказывается в затребованном уровне производительности, но последующие запросы на смену уровня производительности не могут быть выполнены ввиду отсутствия сервисных ключей для сброса в начальное состояние. Для сброса в начальное состояние можно воспользоваться специальной (не допущенной к широкому использованию) версией ПО, после которой снова установить квалифицированную.
Производственный процесс может приводить к ошибкам установки начального требуемого уровня производительности, так что иногда необходимо использовать специальную версию ПО. Это усложняет производственный процесс. Производственная часть предприятия просит включить сброс уровня производительности в основную версию ПО как функцию чтобы избежать сложных изменений.
2
Загрузите описание в LLM, усиленную FPF. Дайте команду “Проанализируй с опорой на FPF, достаточно ли конкретно и заземлённо составлено это описание”, прямо упомянув необходимость отвечать на языке вашей предметной области (подставьте название своей предметной области: разработка ПО, архитектура, продажи и т.п.). При необходимости покритикуйте ответ LLM и поменяйте запрос столько раз, сколько нужно, чтобы LLM исправила ошибки в ответе. Если у вас есть какие-то источники информации о предметной области помимо FPF, на которые LLM должна опираться при ответе, укажите их в запросе тоже.
Описание после нескольких проходов с ИИ. Мне нравится больше стурктурно, пришлось уточнить несколько "почему".
Проблема
HW Scaling позволяет установить для ECU определённый уровень производительности. После установки уровня квалифицированная production-версия ПО не позволяет вернуть ECU в исходное состояние и выбрать другой уровень, поскольку reset требует сервисной авторизации, недоступной в стандартной production-конфигурации. Восстановление возможно только через временную установку специальной версии ПО, выполнение reset и последующую повторную установку квалифицированной версии.
В производстве возникают случаи, когда ECU получает уровень производительности, не соответствующий требуемой конфигурации. Исправление такой конфигурации невозможно штатными средствами production software и требует описанной процедуры со специальной версией ПО.
Это добавляет в rework-процесс два дополнительных обновления ПО и требует специального доступа для установки сервисной версии ПО, который отсутствует в штатном production-процессе.
Кандидат решения
Production предлагает рассмотреть возможность reset performance level непосредственно в квалифицированной версии ПО, чтобы ошибочно сконфигурированный ECU можно было вернуть в исходное состояние и повторно сконфигурировать без смены версии ПО.
Другие направления решения
Рассматриваемое пространство решений не ограничивается изменением основной версии ПО. В частности, возможны изменение производственного процесса — например перенос установки performance level ближе к его концу — либо другой механизм адаптации ПО, позволяющий вернуть ECU к исходному уровню производительности.
3
Опишите к клубе МиМ свои выводы. Помогло ли заземление выявить ошибки в описании? Составить план решения проблем? В данной ситуации действительно стоило напрячься, или “радар ошибок” сработал вхолостую?
Мне понравилось прохождение по этапам “описал как смог – попытался добавить структуры – сделал первую версию, из которой уже стало видно альтернативы”.
Потом прекрасная критика самого ИИ – действительно, смешаны несколько утверждений, и “существует терминальное состояние” достаточно точно для ПО, но недостаточно формально. Заметно, что сам запрос на заземление уже позволил в первоначальное описание ввести нужного уровня детали и нужный набор, мне почти ничего не пришлось сильно уточнять.
Результат сам по себе прекрасный, особенно если сравнивать с “просто моделью”, сделать самому удалось существенно меньше ожидаемого, много цеплялся за подсказки. Кроме того, даже такое вылизанное описание оказалось немного ущербным. Мне несколько циклов приходилось усиленно задавать вопросы.
Итоговый текст, написанный вместе с ИИ
Проблема
HW Scaling позволяет установить для ECU определённый уровень производительности в соответствии с
production order. Информация об активации выбранного уровня сохраняется в persistent state ECU в виде записи об активации лицензии.После активации уровня квалифицированная production-версия ПО не предоставляет штатного способа стереть эту запись и вернуть HW Scaling в состояние, в котором можно выбрать другой уровень производительности.
Стирание записи возможно с помощью специальной сервисной версии ПО. Однако основная production station штатно имеет доступ только к официально выпущенным версиям ПО. Для установки сервисной версии требуется вручную предоставить специальную авторизацию, индивидуальную для конкретного ECU.
После получения такой авторизации rework выполняется следующим образом:
- на ECU программируется сервисная версия ПО;
- с её помощью стирается persistent-запись об активации лицензии;
- ECU программируется обратно квалифицированной production-версией ПО;
- требуемый performance level устанавливается повторно в соответствии с production order.
В производстве возникают случаи, когда активированный в ECU performance level не соответствует значению, указанному для данного ECU в production order.
В таком состоянии существующий штатный production/rework flow основной станции не позволяет привести ECU к конфигурации, соответствующей production order. Исправление требует описанной выше специальной процедуры.
По сравнению со штатным rework эта процедура:
- увеличивает время rework приблизительно на 30–60 минут;
- требует участия другого оператора;
- требует перемещения ECU на отдельную rework-линию, ёмкость которой ограничена;
- требует ручного получения индивидуальной сервисной авторизации;
- требует двух дополнительных операций программирования — установки сервисной и последующей установки стандартной версии ПО;
- создаёт дополнительную возможность ошибки при программировании. Наблюдаемый уровень таких ошибок составляет около 2% в ранних производственных фазах и около 0,1% в последующих фазах.
Критерий приемлемого улучшения
Желаемый rework должен выполняться автоматически или быть пригодным для автоматизации средствами основной production station, без необходимости перехода на отдельную rework-линию, привлечения специального оператора и ручной установки сервисной версии ПО.
Дополнительное время на исправление желательно сделать несущественным относительно штатного production flow: около 3 минут считается целевым уровнем, до 5 минут — приемлемым.
Кандидаты решений
Production предлагает рассмотреть возможность изменения persistent state HW Scaling непосредственно средствами официально выпущенной квалифицированной версии ПО, чтобы ECU с performance level, не соответствующим production order, можно было вернуть в состояние повторной конфигурации без временной установки сервисной версии ПО.
Это предложение является одним из кандидатов решения, а не частью определения самой проблемы.
Другие направления решения могут включать:
- изменение production process, например перенос первоначальной установки performance level на более поздний этап;
- альтернативный механизм изменения persistent state, позволяющий повторно выбрать performance level штатными средствами production environment;
- предотвращение установки performance level, не соответствующего production order.