Обнаружение и устранение переполнений

Question

у нас есть детектор частиц, запрограммированный на использование 16-битного и 8-битного буферов.Время от времени наблюдаются определенные [предсказанные] пики потоков частиц, проходящих через него;все в порядке.Что такое нет хорошо то, что эти потоки обычно достигают величин, превышающих емкость буферов для их хранения;таким образом, происходят переполнения.На графике они выглядят так, как будто поток внезапно падает и снова начинает расти.Можете ли вы предложить [в основном] точный метод обнаружения точек данных, страдающих от переполнения?

P.S.Детектор физически недоступен, поэтому исправить его "правильным способом" путем замены буферов, похоже, не представляется возможным.

Обновить: Некоторые пояснения по запросу.Мы используем python в процессе обработки данных;технология, используемая в самом детекторе, довольно неясна (относитесь к ней так, как будто она была разработана совершенно не связанной третьей стороной), но она определенно проста, т. е.не работает "настоящая" операционная система, просто какие-то низкоуровневые устройства для записи показаний детектора и реагирования на удаленные команды, такие как включение питания.Повреждение памяти и другие проблемы сейчас не являются проблемой.Переполнения происходят просто потому, что разработчик детектора использовал 16-битные буферы для подсчета потока частиц, и иногда поток превышает 65535 частиц в секунду.

Обновление 2: Как отметили несколько читателей, предполагаемое решение было бы как-то связано с анализом профиля потока для обнаружения резких спадов (напримерна порядок величины) в попытке отделить их от нормальных колебаний.Возникает еще одна проблема:могут ли восстановления (точки, где исходный поток падает ниже уровня перелива) быть обнаружены простым запуском программы коррекции по отношению к восстановленному (с помощью x ось) профиль потока?

Answer 1

int32[] unwrap(int16[] x)
{
   // this is pseudocode
   int32[] y = new int32[x.length];
   y[0] = x[0];
   for (i = 1:x.length-1)
   {
      y[i] = y[i-1] + sign_extend(x[i]-x[i-1]);
      // works fine as long as the "real" value of x[i] and x[i-1]
      // differ by less than 1/2 of the span of allowable values
      // of x's storage type (=32768 in the case of int16)
      // Otherwise there is ambiguity.
   }
   return y;
}

int32 sign_extend(int16 x)
{
   return (int32)x; // works properly in Java and in most C compilers
}

// exercise for the reader to write similar code to unwrap 8-bit arrays
// to a 16-bit or 32-bit array

Answer 2

Конечно, в идеале вы бы настроили программное обеспечение детектора на максимальное значение 65535, чтобы предотвратить обман, который вызывает ваше горе.Я понимаю, что это не всегда возможно, или, по крайней мере, не всегда возможно сделать быстро.

Когда поток частиц превышает 65535, происходит ли это быстро или поток постепенно увеличивается, а затем постепенно уменьшается?Это имеет значение в том, какой алгоритм вы могли бы использовать для обнаружения этого.Например, если поток поднимается достаточно медленно:

true flux     measurement  
 5000           5000
10000          10000
30000          30000
50000          50000
70000           4465
90000          24465
60000          60000
30000          30000
10000          10000

тогда у вас, как правило, будет Большой отрицательное падение происходит в те моменты, когда вы переполнены.Гораздо большее отрицательное падение, чем у вас будет в любое другое время.Это может послужить сигналом о том, что вы переполнены.Чтобы найти конец периода времени переполнения, вы могли бы найти большой скачок к значению, не слишком далекому от 65535.

Все это зависит от максимально возможного истинного потока и от того, насколько быстро он повышается и понижается.Например, возможно ли получить более 128 тысяч отсчетов за один период измерения?Возможно ли, чтобы одно измерение равнялось 5000, а следующее - 50000?Если данные недостаточно корректны, вы, возможно, сможете сделать только статистическое суждение о том, когда у вас произошел перерасход.

Answer 3

Ваш вопрос должен содержать больше информации о вашей реализации - какой язык / фреймворк вы используете?

Переполнение данных в программном обеспечении (о чем, я думаю, вы говорите) является плохой практикой, и его следует избегать.Пока вы видите (странный вывод данных) - это только один побочный эффект, который возможен при переполнении данных, но это всего лишь верхушка айсберга тех проблем, которые вы можете видеть.

Вы вполне можете столкнуться с более серьезными проблемами, такими как повреждение памяти, что может привести к громкому сбою программ или что-то похуже, неясно.

Есть ли какая-либо проверка, которую вы можете сделать, чтобы предотвратить переполнение в первую очередь?

Answer 4

Я действительно не думаю, что вы можете исправить это, не исправив базовые буферы.Как вы должны определить разницу между последовательностями значений (0, 1, 2, 1, 0) и (0, 1, 65538, 1, 0)?Ты не можешь.

Answer 5

Как насчет использования HMM, где скрытое состояние - это то, находитесь ли вы в переполнении, а выбросы представляют собой наблюдаемый поток частиц?

Сложной частью было бы создание вероятностных моделей для переходов (которые в основном будут кодировать временную шкалу пиков) и для выбросов (которые вы можете построить, если знаете, как ведет себя поток и как переполнение влияет на измерение).Это вопросы, относящиеся к конкретной предметной области, поэтому, вероятно, готовых решений там нет.

Но если у вас есть модель, то все остальное - подгонка ваших данных, количественная оценка неопределенности, моделирование и т.д. - является рутиной.

Answer 6

Вы можете сделать это только в том случае, если фактические переходы между последовательными значениями намного меньше 65536.В противном случае артефакт долины, вызванный переполнением, неотличим от реальной долины, о чем вы можете только догадываться.Вы можете попытаться сопоставить переполнения с соответствующими восстановлениями, одновременно анализируя сигнал справа и слева (предполагая, что существует узнаваемая базовая линия).

Кроме этого, все, что вы можете сделать, это скорректировать свой эксперимент, повторив его с другими исходными потоками частиц, чтобы реальные долины не перемещались, а артефактные перемещались к точке переполнения.