А есть ещё какой то метод ,кроме кольцевого?.Это касается не только получасовок , а месячных , суточных.
Другого никогда не встречал 
В этом счетчике еще журналы событий представлены как кольцевой буфер, а месячные и суточные имеют жестко фиксированную структуру и содержат данные только за текущий и прошлый период.
Кольцевой буфер, действительно, наиболее удобный метод хранения периодических данных при ограниченной памяти.
Методы бывают разные, но ПО счетчика может скрывать внутреннюю структуру данных, и по протоколу отдавать в другом виде - как правило, более удобном для чтения. Например, в виде линейного скользящего буфера, где индекс 0 всегда соответствует самой свежей записи (Elgama, Элвин). Или в виде массива с доступом по метке времени, где начало и конец задаются в наиболее естественном виде для семантики данных (Landis, EMH, SL7000).
В данном случае (Энергия-9) внутренняя организация не скрывается, а "пролазит" в протокол. И тогда программа опроса сама должна вычислять абсолютные индексы для доступа к внутреннему буферу счетчика, т.е. работать на более низком уровне, чем это необходимо по смыслу.
И это еще не худший случай.
Есть счетчики, которые заставляют использовать буквально байтовую адресацию к внутренней памяти, снимая с себя всю ответственность за правильность чтения. Например, A1800 имеет, по протоколу, структуры данных нефиксированного размера, которые сильно зависят от конфигурации. Для запроса нужно нетривиально вычислить смещение и размер в байтах внутри виртуальной таблицы (буфера). А потом также нетривиально разобрать полученный блок данных. В общем, никакого сервиса, один гемор
Но чемпион по созданию проблем программистам АСКУЭ - это счетчик Облик.
Ранние версии этого счетчика имели тупо линейный буфер профиля нагрузки, который заполнялся до конца, после чего запись прекращалась. Чтобы вновь разрешить сохранение, нужно подать специальную команду стирания профиля (!). Кто не успел, тот опоздал.
В новых версиях буфер стал "типа кольцевым", но извращения не закончились
Есть два сегмента для архива профиля нагрузки, один (текущий) заполняется, другой пока не трогается, потом они меняются. Но! внутри сегмента есть массив индексов и массив упакованных (сжатых по RLE) данных профиля, растущие друг другу навстречу (!) с разных концов буфера. Короче, ночной кошмар программиста
Понятно, что разработчик хотел сэкономить память (и он кое-чего достиг - периоды без нагрузки сжимаются очень хорошо
, но ценой больших затрат на чтение - чтобы взять заданный диапазон из архива, требуется прочитать один или два немаленьких сегмента (49к и 57к) целиком.
Форум проєктувальників електричних та слабострумних мереж
