Объявление

Свернуть
Пока нет объявлений.

Одна неисправность вызывает десятки аварий: как показать первопричину?

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Одна неисправность вызывает десятки аварий: как показать первопричину?

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

    Разберём структуру аварийного оповещения: первичная неисправность, следствие, предупреждение и запрет пуска. Где уместны задержки и подавление ожидаемых сообщений, а где они способны скрыть самостоятельный отказ? Как отображать возвращение параметра в норму и сохранять историю? Предлагаем обсуждать конкретные причинные связи между сигналами и состояниями оборудования. Просто уменьшить количество красных строк недостаточно: смысл события и время его возникновения должны остаться доступными для последующего анализа.

  • #2
    Начинать полезнее с дерева причин, а не с цветов сообщений. Например, отсутствие расхода при штатно выключенном насосе и отсутствие расхода после подтверждённого пуска — разные события. Если это различие выражено в условиях формирования, значительная часть лишних сообщений исчезает без искусственного сокрытия диагностической информации.

    Комментарий


    • #3
      Подтверждение сообщения и устранение причины тоже нужно разделять. Квитирование означает, что оператор увидел событие; оно не должно само по себе давать разрешение на пуск или сбрасывать сохраняющуюся неисправность. На экране стоит явно показывать активное состояние, историю появления и состояние подтверждения события.

      Комментарий


      • #4
        В насосных системах задержка расхода после пуска может быть ожидаемой, но допустимое ожидание определяется гидравликой и режимом заполнения. Поэтому единая задержка для всех сообщений неудобна. Для каждой существенной проверки нужны обоснование, границы применения и испытание, которое показывает поведение как при нормальном переходе, так и при отказе.

        Комментарий

        Обработка...
        X