ГОСТ Р МЭК 61784-1—2016
Все блоки CD DLPDU, отправленные от LAS DLE как часть его деятельности по выполнению пла
на. а не от DLCEP, принадлежащего LAS DLE. содержат явно заданный адрес пункта назначения дли
ной. которая была согласована в МЭК 61158-4-1.8.2.1.1. идолжны пренебречь как адресом источника,
так и SD-параметрами.
П р и м е ч а н и е — Формат адреса очень короткой длины всегда реализуется с помощью коротких адресов
в любом ассоциированном CD DLPDU.
5.2.2.2.4.12 МЭК 61158-4-1, 8.2.2.2
П р и м е ч а н и е — Ниже приведенные процедуры либо не включены, либо включены частично по следую
щим причинам:
МЭК 61158-4-1, 82.2.2. перечисление d.1): данный профиль не включает в себя явное планирование запро
сов DL-данных;
МЭК 61158-4-1. 8.2.2.2, перечисление d.2.ii): функциональные характеристики доставки данных из МЭК
61158-4-1, 8.22.2 не включены в данный профиль.
Если запрос принят, на что указывает возвращенный статус «успех» («success») на запрос
DL-DATA, то по завершении запроса, успешном или же в случае отказа. DLE должен выпустить под
тверждение DL-DATA с тем же идентификатором запроса, как и указанный DLS-пользоватолем в
соот ветствующем примитиве запроса DL-DATA. передавая статус запроса DLS-пользователю.
Источник DCLEP, указанный в запросе DL-DATA, должен быть привязан либо к явной (управляе
мой пользователем) очереди или неявной (управляемой DLE) очереди. Если очередь заполнена или
если указанная длина DLSDU. P0(L), является неверной, или если DLCEP-состояние VC(ST) не являет
ся состоянием ГОТОВ К ПЕРЕДАЧЕ ДАННЫХ (DATA-TRANSFER-READY). то DLE должен немедленно
вернуть соответствующее подтверждение DL-DATA. указывая причину отказа (сбоя).
В противном случае:
a) DLE должен создать и запустить таймер запроса пользователя Ty(MCD). длительность кото
рого основана на указанной пользователем максимальной задержке подтверждения для примитивов
DL-DATA. Если указанное значения было отличным от UNLIMITED, то длительность данного таймера
должна быть равной этой указанной пользователем максимальной задержке подтверждения; в
против ном случае длительность должна быть равна 60 с. DL-менеджмент способен пренебречь
этими пред почтительными вариантами длительности;
b) DLE должен назначить следующий не назначенный номер последовательности N = VC(N) за
просу и связанному с ним DLSDU;
c) DLE должен инициализировать переменную Vs,N(SS), основываясь на длине. PN(L), N-ro
DLSDU. чтобы указать на то, что все сегменты N-го DLSDU нуждаются в передаче, а никакие другие
сегменты данного DLSDU;
d) DLE должен добавить запрос в очередь запроса пользователя DLCEP-адреса, QA(UR), следу
ющим образом;
1) не используется.
2) i) если N > VC(A) + PC(WS) и отправляющий DLCEP являются КЛАССИЧЕСКИМ (CLASSICAL)
или БЕСПОРЯДОЧНЫМ (DISORDERED) одноранговым устройством, то запрос должен быть помещен
в третий раздел QA(UR),
3) в противном случае, если перечисление 2) не применимо, то третий раздел QA(UR) пустой, и
потому запрос должен быть помещен во второй раздел QA(UR). a DLE должен добавить в очередь не
запланированной услуги (unscheduled-service) DLE, Q(US). ссылку на Q„(UR) того же приоритета как и
только что присоединенный запрос.
П р и м е ч а н и е — Q(US) никогда не нуждается в большем числе ссыпок на QA(UR), чем число блоков
DLSDU. ожидающих передачу или повторную передачу.
DLE должен увеличивать VC(N).
5.2.2.2.4.13 МЭК 61158-4-1. 8.2.2.3.1
П р и м е ч а н и е — Следующие процедуры либо не включены, либо включены частично по причинам, при
веденным ниже:
МЭК 61158-4-1, 8.2.2.3.1. перечисления a), b.i), b.iii), b.iv): функциональные возможности доставки данных по
МЭК 61158-4-1,8.2.2.3.1 не включены в данный профиль:
77