Здравствуйте, binks, Вы писали:

B>Здравствуйте, swame, Вы писали:

S>>Сталкивался.
S>>Там внутри куча подстандартов на всевозможные темы, нужно уточнять тему.

Сам протокол тут ни при чем.

B>Тема — запрос показаний приборов учёта электроэнергии. Конкретная реализация в ПО "Пирамида 2.0"
B>Возможно я что-то не так понимаю. Но меня смущает возможный рассинхрон при запросе показаний.
B>Делается это в 3 этапа:
B>1. Запрос списка ТУ.
B>2. Запрос списка ПУ и связывание ТУ с ПУ.
B>3. Запрос показаний по списку ТУ.

B>В итоге должен быть массив данных показаний связанный с серийным номером прибора. Серийный номер прибора содержится в описании ПУ. Запрошенные показания содержат ссылку на ТУ (в ТУ есть ссылка на ПУ и следовательно на серийный номер ПУ), из этой ссылки я могу получить серийный номер прибора и привязать к показаниям. Но, если между 1/2 и 3 этапом на стороне сервера смениться привязка ПУ к ТУ, то 3 этапом я получу данные для другого ПУ.

B>Другими словами.

B>На сервер ТУ1-ПУ1
B>1-2. Делаю запрос списков ПУ и ТУ. В итоге у себя имею ТУ1-ПУ1.
B>На сервере меняется привязка, теперь ТУ1-ПУ2.
B>3. Делаю запрос показаний. Получаю ТУ1-ПУ1-Показания (но данные пришли от ТУ1-ПУ2).

B>Такой ситуации пока не встречал, но теоретически она имеет место быть, как мне кажется.

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

B>Сталкивались ли вы с подобным?

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