Комментарии 6
61850/8.1 — до сих пор в дрожь бросает от одного его упоминания…
Что-то никак не могу сообразить схему получения данных, которая использовалась для расчётов таблиц. Объясните, пожалуйста, как для DLMS при размере запроса — 12 + 11*n и размере ответа — 12+ 6*n получается около 200 байт на 30 полученных значений, то есть, чуть больше 6 байт на значение? Значения идут пачкой? И почему размер запроса согласно формуле больше, чем ответ?
В протоколе DLMS/COSEM, условно, можно выделить два вида запроса типа GET. Запрос типа GET-Request-Normal и запрос типа Get-Request-With-List. Во всех типах запроса используется параметр типа COSEM Attribute Descriptor который содержит информацию, необходимую для запроса данных, например логическое имя объекта, идентификатор атрибута и др. Отличие GET-Request-Normal от Get-Request-With-List заключается в том, что в первом используется один параметр COSEM Attribute Descriptor, а во втором список параметров COSEM Attribute Descriptor. Таким образом, применяя запрос Get-Request-With-List можно запросить значения атрибутов сразу нескольких объектов COSEM или запросить значения нескольких атрибутов одного объекта COSEM, в общем возможны варианты…
В ответном же сообщении содержатся только запрашиваемые значения. Параметр COSEM Attribute Descriptor в ответном сообщении отсутствует, этим и объясняется то обстоятельство, что размер запроса больше, чем размер ответа. Тем не менее очень часто бывает так, что размер ответа превышает размер запроса, все зависит от размера запрашиваемого значения. Однако надо учитывать, что авторы статьи для расчета размера поля данных TCP рассматривали размер запрашиваемого значения равного четырем байтам, для всех протоколов.
И последнее, в случае запроса типа Get-Request-With-List в ответном сообщении содержится список запрашиваемых значений.
В ответном же сообщении содержатся только запрашиваемые значения. Параметр COSEM Attribute Descriptor в ответном сообщении отсутствует, этим и объясняется то обстоятельство, что размер запроса больше, чем размер ответа. Тем не менее очень часто бывает так, что размер ответа превышает размер запроса, все зависит от размера запрашиваемого значения. Однако надо учитывать, что авторы статьи для расчета размера поля данных TCP рассматривали размер запрашиваемого значения равного четырем байтам, для всех протоколов.
И последнее, в случае запроса типа Get-Request-With-List в ответном сообщении содержится список запрашиваемых значений.
Понятно. Осталось понять, как получается около 200 байт на 30 значений. Если данные считываются через запрос-ответ, то согласно формулам для DLMS на 30 значений уйдёт (12 + 11 * 1) * 30 + (12 + 6 * 1) * 30 = 1230 байт. Если же предположить, что запросом мы подписываемся на получение новых значений, то тогда понадобится (12 + 11 * 1) * 1 + (12 + 6 * 1) * 30 = 563 байт. И только если мы каким-то одним хитрым запросом запросили сразу 30 значений, которые придут пачкой, то выйдет (12 + 11 * 1) * 1 + (12 + 6 * 30) * 1 = 215 байт. Последний вариант выглядит странно, если нужно получить серию измерений от одного датчика, поэтому у меня возник вопрос о схеме получения данных.
Осталось понять, как получается около 200 байт на 30 значений
Видимо так: 12+6*30 = 192.
Понятно, вначале я был невнимателен и не заметил, что оценивается размер одного ответа в зависимости от количества запрашиваемых параметров, а не все необходимые данные, включая запрос.
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение коммуникационных протоколов DLMS/COSEM, SML и IEC 61850 для приложений интеллектуального учета потребления