#200 closed улучшение
При сбросе аварий ЧРП очищать прочитанные ранее флаги аварий — at Version 11
| Сообщил: | san | Владелец: | alx |
|---|---|---|---|
| Приоритет: | средний | Этап разработки: | 1-я очередь |
| Ключевые слова: | Копия: | andrei, Art_M |
Описание (последним изменил )
(Описание изменил alx)
Для уменьшения вероятности возникновения аварий, основанных на устаревших данных (сохраненного в памяти контроллера срдержимого регистров аварий ЧРП) предлагается при выполнении сброса аварий ЧРП очищать сохраненное значение регистра аварий.
История изменений (11)
следующий: 3 comment:2 by , 5 лет ago
Таким образом, я не вижу оснований считать аварию 20.1 ложной
Формально может быть и так, контроллер согласно тз действует, но с точки зрения пользователя это баг - т.к. сброс аварий ЧРП прошёл, а привод детектировал 20.1.
Можно обратить внимание, что авария ЧРП вызвавшая 20.1 была снята в ту-же секунду.
10:31:04 Снятие аварии: 1.НУ2A25
Подозреваю, что после сброса аварий ЧРП, контроллер ещё не опросил аварии ЧРП НУ2, на момент принятия решения, и принял решение об аварии 20.1 основываясь уже на устаревшей информации.
Считаю, что мы должны принять какие-то меры для избежания таких случаев.
comment:3 by , 5 лет ago
Replying to san:
Подозреваю, что после сброса аварий ЧРП, контроллер ещё не опросил аварии ЧРП НУ2, на момент принятия решения, и принял решение об аварии 20.1 основываясь уже на устаревшей информации.
Вероятно, что так. Но я, во-первых, не вижу особой проблемы даже сточки зрения пользователя: два ЧРП - это два разных устройства, и аварии в них не обязаны возникать и пропадать строго синхронно. Не вижу проблемы в такой последовательности событий:
- нет аварий ЧРП;
- авария только ЧРП 1 (здесь имеем аварию 20.1);
- авария ЧРП 1 и ЧРП 2 (имеем аварию 20.2);
- авария только ЧРП 2 (опять имеем аварию 20.1);
- нет аварий.
Во-вторых, аварии ЧРП мы можем получать только методом периодического опроса, поэтому всегда есть вероятность запаздывания реакции на изменение состояния.
Считаю, что мы должны принять какие-то меры для избежания таких случаев.
Предлагай меры.
следующий: 6 comment:4 by , 5 лет ago
два ЧРП - это два разных устройства
Это так, но суть аварии 20.2 в том что оба ЧРП получают аварию одновременно (т.е. причина возникновения аварии у них общая) и решать эту проблему они должны вместе.
Предлагай меры.
Пока в голову приходит что-то вроде искусственной задержки после сброса аварий ЧРП - некоторое время после сброса не детектировать аварии ЧРП.
comment:5 by , 5 лет ago
решать эту проблему они должны вместе.
А если мы при общей аварии будем запускать НУ по очереди, то для них в итоге будут выставлены неоптимальные настройки диапазона, а то и вовсе выйдет так что одна установка не сможет тащить привод и привод встанет по окончанию попыток АПВ, вместо успешной работы на двух НУ на чуть пониженной частоте.
comment:6 by , 5 лет ago
Replying to san:
два ЧРП - это два разных устройства
Это так, но суть аварии 20.2 в том что оба ЧРП получают аварию одновременно
Тогда в ТЗ неверно сформулировано условие аварии 20.2 - там нет никакого требования одновременности. Если, например, авария "перегруз по току" сначала возникнет только в ЧРП 1, а через пол-часа возникнет на ЧРП 2, то условие аварии все равно выполнится, хотя никакой одновременности и близко нет...
Предлагай меры.
Пока в голову приходит что-то вроде искусственной задержки после сброса аварий ЧРП - некоторое время после сброса не детектировать аварии ЧРП.
Может быть просто производить сброс аварий ЧРП при возникновении аварии, а не при снятии? Тогда задержка АПВ будет той самой "искусственной задержкой", о которой ты говоришь выше...
следующие: 8 10 comment:7 by , 5 лет ago
Еще один вариант - по факту выполнения сброса аварий ЧРП сбрасывать и флаги аварий у себя в памяти (которые были получены при последнем опросе), так как и без нового опроса понятно, что в этот момент аварий там быть не должно. Это, наверное, самый простой вариант, не требующий внесения изменений в ТЗ.
следующий: 9 comment:8 by , 5 лет ago
Replying to alx:
Еще один вариант - по факту выполнения сброса аварий ЧРП сбрасывать и флаги аварий у себя в памяти (которые были получены при последнем опросе), так как и без нового опроса понятно, что в этот момент аварий там быть не должно. Это, наверное, самый простой вариант, не требующий внесения изменений в ТЗ.
А сейчас программа берет информацию из этих флагов, при том что в ЧРП аварии уже нет?
Офтоп: предлагаю всем ознакомиться и высказаться в тикете #201
comment:10 by , 5 лет ago
Replying to alx:
Еще один вариант - по факту выполнения сброса аварий ЧРП сбрасывать и флаги аварий у себя в памяти (которые были получены при последнем опросе), так как и без нового опроса понятно, что в этот момент аварий там быть не должно. Это, наверное, самый простой вариант, не требующий внесения изменений в ТЗ.
Согласен с таким вариантом.
comment:11 by , 5 лет ago
| Краткое описание: | При снятии аварии 20.2 ложно регистрируется авария 20.1 → При сбросе аварий ЧРП очищать прочитанные ранее флаги аварий |
|---|---|
| Описание: | изменено (отличие) |
| Приоритет: | Срочно → средний |
| Решение: | invalid |
| Состояние: | closed → reopened |
| Тип: | баг → улучшение |
Раз достигнуто согласие, переоткрою тикет.
Я проанализировал приведенный журнал. Вот какие события возникали в станции:
Таким образом, я не вижу оснований считать аварию 20.1 ложной - в обоих случаях условие аварии было выполнено (имелся флаг аварии "перегруз по току" только одной из двух разрешенных ЧРП).