Обработка данных захвата прибора

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

Другое требование - как можно скорее выйти из обратного вызова onDataAcquisitionEvent(), чтобы избежать потери данных в датчике.

Это единственное требование до тех пор, пока эта часть продукта не будет работать на 110% во всех полевых условиях.

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

«В большинстве случаев» не имеет значения. Кодируйте наихудший случай, потому что onDataAcquisitionEvent() не может тратить время на размышления о непредвиденных обстоятельствах.

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

Уничтожьте данные в источнике. Укажите, сколько выборок потребуется для обработки аномального случая, и попытайтесь предоставить это количество с постоянной частотой выборки плюс запас в 20%.

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

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

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

Используйте структуру данных, которая в основном является двусвязным списком, чтобы при ее росте вам не нужно было перераспределять все, и у вас также есть доступ O (1) к нужным вам образцам.

Если ваша память недостаточно велика для хранения данных за несколько секунд (а это должно быть - одна выборка каждые 200 мс? 5 выборок в секунду), вам нужно посмотреть, можете ли вы выдержать чтение из вспомогательной памяти, но это пропускная способность и в вашем случае это не имеет ничего общего с вашим дизайном и требованием «как можно скорее прекратить обратный вызов».

Рассмотрим реализацию очереди, которая не требует блокировки (помните: только один читатель и один писатель!), Чтобы ваш обратный вызов не остановился.

Если ваш обратный вызов действительно быстрый, подумайте о том, чтобы отключить прерывания / назначить ему высокий приоритет. Может не понадобиться, если он никогда не может блокироваться и имеет правильный приоритет.

Вопросы: (1) насколько хорош этот дизайн и каковы подводные камни, и (2) какой дизайн может быть лучше. Спасибо.

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

Длина такого массива (= фрагмент данных) либо фиксированная (более простой код), либо переменная (гибкая, но некоторая обработка может усложняться).

В качестве второго варианта дизайна вам, вероятно, следует игнорировать историю на этом архитектурном уровне и отбросить эту функцию ...

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

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