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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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