eBus на тепловом насосе Ochsner

[InSAn]

это не совсем то, что мне нужно

Тогда говорите, что нужно - я обратно собрал макетку :D

20160506224145.txt

[InSAn]

01 c6 a5 59 12 - тут не могу увидеть дату и время 10.03.2016 06:17

С передаваемыми значениями вообще мрак.

Например, команда 0700:

... ... 19 86 17 ... ... ... ... - здесь время 11:56:13

Чтобы получить дату и время, нужно значения перевести в шестнадцатеричный вид

... ... 0x13 0x56 0x11 ... ... ... ... - и получаем секунды, минуты и часы

[fim]

С передаваемыми значениями вообще мрак.

Например, команда 0700:

... ... 19 86 17 ... ... ... ... - здесь время 11:56:13

Чтобы получить дату и время, нужно значения перевести в шестнадцатеричный вид

... ... 0x13 0x56 0x11 ... ... ... ... - и получаем секунды, минуты и часы

ebusd умеет такие форматы date, time читать

пробовал все - ничего не подошло

пробовал еще пару тройку "фокусов" - нет толку

вообще такое:

 

c6;a5;59;12; 10.03.2016 06:17

c6;a5;bc;11; 10.03.2016 03:40

c1;a5;1f;1e; 05.03.2016 08:31

c0;a5;49;19; 04.03.2016 11:53

c0;a5;49;19; 04.03.2016 10:11

c0;a5;e3;18; 03.03.2016 06:44

 

я написал John Baier, а он отписался, мол пришли полностью

может он "увидит"

 

например про мои f8 говорит, что я последующие байт зря пропустил

"the 76 degrees are stored in two consecutive bytes: 0xf8 0x02.

((0x02 * 256) + 0xf8) / 10 = 76

This is datatype UIN with divider 10."

 

Может, вынести наш диалог о eBus в отдельную ветку?

не возражаю

Змінено 7 травня 2016 користувачем fim

[InSAn]

ebusd умеет такие форматы date, time читать

Я тоже уже умею, когда известен формат

 

пробовал все - ничего не подошло

пробовал еще пару тройку "фокусов" - нет толку

вообще такое:

 

c6;a5;59;12; 10.03.2016 06:17

c6;a5;bc;11; 10.03.2016 03:40

c1;a5;1f;1e; 05.03.2016 08:31

c0;a5;49;19; 04.03.2016 11:53

c0;a5;49;19; 04.03.2016 10:11

c0;a5;e3;18; 03.03.2016 06:44

А это в какой команде?

 

например про мои f8 говорит, что я последующие байт зря пропустил

А это где? Змінено 8 травня 2016 користувачем InSAn

[InSAn]

Помогите, плз, разобраться с ответом в телеграмме:

01 - отправитель

15 - получатель

06 21 - команда

04 - кол-во байт в запросе

00 80 00 40 - запрос (согласно 22102.csv - temperature outside)

... - crc запроса

00 - ack

10 - кол-во байт в ответе

----------------------------------------------

00 80 0D 02 F4 01 0C FE BD 00 - ответ

----------------------------------------------

... - crc ответа

00 - ack

 

 

Как интерпретировать ответ? В 22102.csv указано только два параметра: "param" и "tempt".

Смотрю _templates.csv:

- param - command;maxs;mins

- tempt:temperature - SIN/10

Как это понять?

 

Или я не туда смотрю?

 

Добавлено через 51 минуту

- param - command;maxs;mins

 

Кажется разобрался...

param = command;maxs;mins

command = group;value;type;unit

значит:

param = command group;value;type;unit;maxs;mins

group = UCH

value = BI0:7

...

и т.д.

В итоге ответ разбирается так:

00 80 0D 02 F4 01 0C FE BD 00

UCH;BI0:7;HEX;HEX;SIN;SIN;SIN/10

=

00 - UCH

80 - BI0:7

0D - HEX

02 - HEX

F4 01 - SIN

0C FE - SIN

BD 00 - SIN/10

Верно?

 

А где найти описания "UCH", "BIO:7", "SIN" и т.п.?

Подозреваю, что:

UCH - unsigned char

SIN - signed integer

HEX - 16-ричное значение

А остальное?

 

Добавлено через 37 минут

А где найти описания "UCH", "BIO:7", "SIN" и т.п.?

 

Нашел!

 

Добавлено через 11 минут

В итоге ответ разбирается так:

00 80 0D 02 F4 01 0C FE BD 00

UCH;BI0:7;HEX;HEX;SIN;SIN;SIN/10

=

00 - UCH

80 - BI0:7

0D - HEX

02 - HEX

F4 01 - SIN

0C FE - SIN

BD 00 - SIN/10

Верно?

 

Ок, вернемся с нашему полученному ответу...

Два последних байта (BD 00 - SIN/10) - температура на улице:

word(00, BD) = 189

SIN/10 = 189 / 10 = 18,9 C

 

А что другие восемь байт дают? Зачем они? Есть какое-то описание?

Змінено 8 травня 2016 користувачем InSAn

[InSAn]

Начал по чуть-чуть парсить данные

 

[fim]

В итоге ответ разбирается так:

00 80 0D 02 F4 01 0C FE BD 00

UCH;BI0:7;HEX;HEX;SIN;SIN;SIN/10

=

00 - UCH

80 - BI0:7

0D - HEX

02 - HEX

F4 01 - SIN

0C FE - SIN

BD 00 - SIN/10

Верно?

если быть точным (т.е. max & min отвечающие реальности), то SIN/10 (я пока так прописл себе в _templates.csv)

 

по дате John Baier таки "увидел":

"c6;a5;59;12; 10.03.2016 06:17

c6;a5;bc;11; 10.03.2016 03:40

c1;a5;1f;1e; 05.03.2016 08:31

c0;a5;49;19; 04.03.2016 11:53

c0;a5;49;19; 04.03.2016 10:11

bf;a5;e3;18; 03.03.2016 06:44

 

the first two bytes is the number of days since 1.1.900.

the second two bytes is the number of minutes starting from monday in that week.

in order to decode it, new datatypes have to be added to ebusd source."

 

пока не проверял щас дошол до компа попробую

 

А что другие восемь байт дают? Зачем они? Есть какое-то описание?

в смысле?

первые два байта (group;value) - группа как в меню блока управления

третий (type) - шаг 0.1°C, 1°C и т.д. (важно при проверке правильной/корректной последующей записи/изменении значения например целевых температур или температур кривых)

четвертый (unit) - например °C

max, min

у мну так:

$ ebusctl r -f -c heatpump twv
7;0;0d;°C;100.0;0.0;19.1

первые два бита: "00-007 TWV temperature"

третий - работаю пока

max, min - понятно

19.1 °C

 

Вы об этом?

 

А это где?

да по мылу мы рубимся

я думал просто f8

а он подсказал надо брать два бита f8 и следующий 02, т.е. а8 02 и применить datatype UIN/10 - проверено - ОК

 

зы по температурам могут быть разные форматы не обязательно SIN/10

посмотрите у меня в csv

ochsner_ebusd_csv.zip

Змінено 8 травня 2016 користувачем fim

[InSAn]

первые два байта (group;value) - группа как в меню блока управления

Это я и имел в виду.

 

третий (type) - шаг 0.1°C, 1°C и т.д.

Откуда Вы это взяли? В смысле, где это написано? Я в документации не нашел.

 

у мну так:

$ ebusctl r -f -c heatpump twv
7;0;0d;°C;100.0;0.0;19.1

Я ebud'ом не пользуюсь - разбираюсь вручную

 

посмотрите у меня в csv

Спасибо, глянул. Но не нашел команд 0503 и 0501:

Формат записи (NN, CRC и ACK удалены):
QQ->ZZ (PB SB): DB1 DB2 ... DNn
x03->x10 (0503): 00 80 0D 02 F4 01 0C FE AF 00 
x13->x10 (0503): 48 41 04 2A 9F 05 00 00 9C 04
x03->x10 (0503): 46 41 04 28 FF FF 00 00 01 A6 
x13->x10 (0503): 35 81 00 00 FF 00 00 00 00 00
x03->x10 (0503): 60 80 0D 02 E8 03 00 00 D6 00
x03->x10 (0503): 10 05 DF 00 01 00 21 00

x10->x03 (0501): 00 00 32 12 00 00 00 00 00 00
x10->x13 (0501): 00 00 0A 12 00 00 00 00 01 00

 

Добавлено через 3 минуты

PS: По 0501 - странно, что длина данный 10 байт, т.к. по OSI-7 должна быть 5 байт.

[fim]

 

 

Это я и имел в виду.

 

Откуда Вы это взяли? В смысле, где это написано? Я в документации не нашел.

в документации контроллера TEM SE 6001 WPC (но для Ochsner идут некоторые особенности/отличия)

 

Я ebud'ом не пользуюсь - разбираюсь вручную

 

Спасибо, глянул. Но не нашел команд 0503 и 0501:

Формат записи (crc и ack удалены):
QQ->ZZ (PB SB): DB1 DB2 ... DNn
x03->x10 (0503): 00 80 0D 02 F4 01 0C FE AF 00 
x13->x10 (0503): 48 41 04 2A 9F 05 00 00 9C 04
x03->x10 (0503): 46 41 04 28 FF FF 00 00 01 A6 
x13->x10 (0503): 35 81 00 00 FF 00 00 00 00 00
x03->x10 (0503): 60 80 0D 02 E8 03 00 00 D6 00
x03->x10 (0503): 10 05 DF 00 01 00 21 00

x10->x03 (0501): 00 00 32 12 00 00 00 00 00 00
x10->x13 (0501): 00 00 0A 12 00 00 00 00 01 00

 

Добавлено через 3 минуты

PS: По 0501 - странно, что длина данный 10 байт, т.к. по OSI-7 должна быть 5 байт.

0503 и 0501 - еще не разобраны/определены

и для 0503 есть две позиции в OSI-7, но длина и там и там другая, т.е. имхо OSI-7 для наших 0503 и 0501 применять нельзя

 

у меня примерно так:

031005030a010000002512ff3f0000
100305010a00000a0c000000000000
100305010a00000a0d000000000000
100305010a00000a0e000000000000
100305010a00000a0f000000000000
100305010a00000a10000000000000

 

разберем потихоньку, я так думаю

 

зы а Вы можете посмотреть, что мне Джохн написал, а то я шо-то не въеду

а хотелось бы пока не уехал с дачи закончить с "service_report error_data"

упс

 

c6 a5 59 12  //10.03.2016 06:17
c6 a5 bc 11  //10.03.2016 03:40
c1 a5 1f 1e  //05.03.2016 08:31
c0 a5 49 19  //04.03.2016 11:53
c0 a5 e3 18  //04.03.2016 10:11
bf a5 74 12  //03.03.2016 06:44

 

"the first two bytes is the number of days since 1.1.900.

the second two bytes is the number of minutes starting from monday in that week.

in order to decode it, new datatypes have to be added to ebusd source."

Змінено 8 травня 2016 користувачем fim

[fim]

хотелось бы пока не уехал с дачи закончить с "service_report error_data"

 

c6 a5 59 12  //10.03.2016 06:17
c6 a5 bc 11  //10.03.2016 03:40
c1 a5 1f 1e  //05.03.2016 08:31
c0 a5 49 19  //04.03.2016 11:53
c0 a5 e3 18  //04.03.2016 10:11
bf a5 74 12  //03.03.2016 06:44

 

"the first two bytes is the number of days since 1.1.900.

the second two bytes is the number of minutes starting from monday in that week.

in order to decode it, new datatypes have to be added to ebusd source."

сушняк... пошел водички попить и... до меня дошло

(формат UIN) 0xa5 * 256 + 0xc6 = 42438 т.е. количество дней с 01.01.1900 г

и время получается

[InSAn]

в документации контроллера TEM SE 6001 WPC (но для Ochsner идут некоторые особенности/отличия)

О! А я искал доки по ТЕМ, но ничего стоящего не нашел. Поделитесь?

 

0503 и 0501 - еще не разобраны/определены

и для 0503 есть две позиции в OSI-7, но длина и там и там другая, т.е. имхо OSI-7 для наших 0503 и 0501 применять нельзя

Да, для 0503 описывается блок 01h и 02h. А в моем случае блоки 00h, 10h, 35h, 46h, 48h, 60h.

 

Добавлено через 3 минуты

у меня примерно так:

 

03 10 0503 0a 01 0000002512ff3f0000

 

Странно... Ваша команда 0503 с первого блока, но не соответствует OSI 7, т.к. имеет 10 байт (0a).

[fim]

О! А я искал доки по ТЕМ, но ничего стоящего не нашел. Поделитесь?

так было, а я не ту ссылку давал, сорри

вот со стр. 20 про "про 8 битов"

кстати max, min тоже имеет разный формат для разных температур (в моих csv, которые я скинул они ока одинаковые)

у них там много интересного

 

Да, для 0503 описывается блок 01h и 02h. А в моем случае блоки 00h, 10h, 35h, 46h, 48h, 60h.

я пока не парюсь 0503, 0501 и т.д.(QQ ZZ 0621 04 02c60040, QQ ZZ 0621 04 02c80040, QQ ZZ 0621 04 01cc0042, QQ ZZ 0621 04 01960042, QQ ZZ 0621 04 01940048,...), т.к. это уже имхо высший пилотаж "увидеть" не зная что, я пока берусь за то, что попроще

или Вы считаете, что мастер-мастер "телеграммы" нужно разобрать в первую очередь?

 

зы а Вы можете подсказать где у ebusd задаются datatype (я в с++ )

я так понимаю здесь (правильно?), просто хочу попробовать задать новый тип date&time (4 битов) для данных об ошибках

Змінено 9 травня 2016 користувачем fim

[GeoTeplo]

Я за вами двумя наблюдаю!

 

P.S. Подписываюсь на тему.....

[InSAn]

я пока не парюсь 0503, 0501

...

или Вы считаете, что мастер-мастер "телеграммы" нужно разобрать в первую очередь?

ХЗ Просто их много... Вот и подумал - вдруг есть инфа по них...

 

зы а Вы можете подсказать где у ebusd задаются datatype (я в с++ )

я так понимаю здесь (правильно?), просто хочу попробовать задать новый тип date&time (4 битов) для данных об ошибках

Да, там - в массиве

static const dataType_t dataTypes[]

Но лучше уточнить у автора

[fim]

Начал по чуть-чуть парсить данные

так плата уже пришла и вы читаете и пишите?

а скан FB?

Но лучше уточнить у автора

написал автору вопрос

но и себе коротенький bash сделал - работает

Я ebud'ом не пользуюсь - разбираюсь вручную

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

 

первые два байта (group;value) - группа как в меню блока управления

не везде корректно отображается, нужно разбираться с форматом, если эти данные вообще полезны

третий (type) - шаг 0.1°C, 1°C и т.д. (важно при проверке правильной/корректной последующей записи/изменении значения например целевых температур или температур кривых)

четвертый (unit) - например °C

тут такое

0x4d=0.5°C

0x01=0.5°C

0x00=1°C

0x8d=1°C

вроде внимательно смотрел

max, min - формат в основном такой как и у самого данного

у мну щас так:

$ ebusctl r -f -c heatpump twv
7;0;0.5°C;°C;100.0;0.0;19.1

или так можно

$ ebusctl r -f -c heatpump twv
7;0;0.5;°C;100.0;0.0;19.1

 

Я за вами двумя наблюдаю!

Александр, есть такая таблица ошибок

есть смысл ее дополнять таким?

и взагалі это все ошибки или только "короткий список"?

[InSAn]

так плата уже пришла и вы читаете и пишите?

а скан FB?

Пока нет - на макетке только читаю. Скан - из среды Ардуино.

 

нужно разбираться с форматом, если эти данные вообще полезны

Я пока не знаю, что полезно, а что нет Ложу в копилку - дальше видно будет... ;)

[InSAn]

Идет очень много команд x10x0A:

10->FE (100A); data - (14): 10 00 D2 00 C1 00 CF 00 00 00 E6 01 00 00 
10->FE (100A); data - (12): 11 01 C4 00 00 00 00 00 00 00 74 00 
10->FE (100A); data - (14): 10 01 CF 00 00 00 D4 00 00 00 E6 01 E3 00 
10->91 (100A); data - (14): D1 15 07 03 03 FF 03 FF 06 03 03 FF 03 FF ; slave - (0): 
10->91 (100A); data - (14): D0 15 6D 03 89 91 18 03 06 03 03 FF EF EF ; slave - (2): C0 00 
10->91 (100A); data - (2): 00 05 ; slave - (8): 10 05 E3 00 01 00 1F 00 

Не в курсе, что это?

 

Добавлено через 46 минут

Я за вами двумя наблюдаю!

Ну, ок... Тогда вопрос.

Разобрал команду 0801 (по OSI-7):

10->FE (0801); data - (8): 9A 14 00 80 00 00 66 19

Получил значения, требующие объяснения:

 

Boiler effective: 20.6 C; Service water effective: 128.0 C;

Что такое "Boiler effective" и "Service water effective"?

 

Emission test: No;

Что такое "Emission test"? Возможные значения (одно из перечня):

00: No

01: Emission BR1

02: STB-test with BR1

03: Emission test BR1+2

04: STB-test with BR1+2

Что обозначают эти значения?

 

Return flow temperature: 25.4 C

Что за температуру возвращает комнатный контроллер?

 

Heating status: BWR not active

Возможные значения (может быть несколько из перечня):

BWR active

Pump release u-block

Boiler 1 in operation

Boiler 2 in operation

Loading pump runs

BW_loading runs

TBF_connect

 

Объясни, плз...

Змінено 10 травня 2016 користувачем InSAn

[fim]

Идет очень много команд x10x0A:

10->FE (100A); data - (14): 10 00 D2 00 C1 00 CF 00 00 00 E6 01 00 00 
10->FE (100A); data - (12): 11 01 C4 00 00 00 00 00 00 00 74 00 
10->FE (100A); data - (14): 10 01 CF 00 00 00 D4 00 00 00 E6 01 E3 00 
10->91 (100A); data - (14): D1 15 07 03 03 FF 03 FF 06 03 03 FF 03 FF ; slave - (0): 
10->91 (100A); data - (14): D0 15 6D 03 89 91 18 03 06 03 03 FF EF EF ; slave - (2): C0 00 
10->91 (100A); data - (2): 00 05 ; slave - (8): 10 05 E3 00 01 00 1F 00 

Не в курсе, что это?

 

на github моих 100А (в неопознанном виде) тоже много

10 fe 100a  0c 110028000000000000004700
10 fe 100a  0c 110029000000000000004700
10 fe 100a  0c 11002a000000000000004700
10 fe 100a  0c 11002b000000000000004700
10 fe 100a  0c 11002c000000000000004700

10 fe 100a  0c 110128000000000000004000
10 fe 100a  0c 110129000000000000004000
10 fe 100a  0c 11012a000000000000004000
10 fe 100a  0c 11012b000000000000004000
10 fe 100a  0c 11012c000000000000004000

10 fe 100a  0c 110200007825010100213500
10 fe 100a  0c 110300007825010000203000

10 fe 100a  0e 10001501de0001010000b0040000
10 fe 100a  0e 10001601df0003010000b0040000
10 fe 100a  0e 10001701e10003010000b0040000
10 fe 100a  0e 10001801e20005010000b0040000
10 fe 100a  0e 10001901e30008010000b0040000

10 fe 100a  0e 10001a01e40006010000b0040000
10 fe 100a  0e 10001b01e5000b010000b0040000
10 fe 100a  0e 10001c01e7000d010000b0040000
10 fe 100a  0e 10001d01e8000f010000b0040000
10 fe 100a  0e 10001e01ea000e010000b0040000
10 fe 100a  0e 10001f01eb000f010000b0040000

10 fe 100a  0e 10002001ec0012010000b0040000
10 fe 100a  0e 10002201ed0015010000b0040000
10 fe 100a  0e 10002301ee0014010000b0040000
10 fe 100a  0e 1000ec00eb0003010000b0040000
10 fe 100a  0e 1000ed00ee000d010000b0040000
10 fe 100a  0e 1000ee00ef000e010000b0040000
10 fe 100a  0e 1000f200ef000f010000b0040000
10 fe 100a  0e 1000fe00ee0013010000b0040000
10 fe 100a  0e 10010000000000000000b004b004
10 fe 100a  0e 100200000000f70000006400c800
10 fe 100a  0e 100276020000f60000006400c800
10 fe 100a  0e 1003000000000000000064000000

пока ХЗ

имхо нужны большИе массивы данных 100А в привязке ко времени (логи) и другим данным

понимание имхо само придет... со временем

вот, например пересматривая свои unknown, можно сказать случайно (как-то само по себе), увидел такой же формат даты как и в err_data в команде

01 15 0621 04 02c60040 / 0a 46410428ffff0000bba5 - UIN дней от 01/01/1900г (на выходных проверю)

 

я сначала не мог понять зачем некоторые данные дублируются

может Вы обращали внимание, чо в csv есть tqa и tqa1 и т.п. получаемые разными командами...

потом опять таки можно сказать случайно (как-то само по себе), обнаружил зачем

по одной из команд не будут приходить ответы (значения), например, после отключения и включения ээ

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

кстати " запрос этих данных с блока управления гтн" тоже можно расшифровать групповой командой (ходы записаны), но эт потом, сейчас у мну в планах таймер ("временнАя программа")

[InSAn]

увидел такой же формат даты как и в err_data в команде

01 15 0621 04 02c60040 / 0a 46410428ffff0000bba5 - UIN дней от 01/01/1900г (на выходных проверю)

 

Не оно.

01->15 (0621); data - (4): 02 C6 00 40 ; slave - (10): 46 41 04 28 FF FF 00 00 03 A6

[fim]

Не оно.

01->15 (0621); data - (4): 02 C6 00 40 ; slave - (10): 46 41 04 28 FF FF 00 00 03 A6

2016-02-28 14:05:44.105  011506210402c60040 / 0a46410428ffff0000bba5

bba5 (UIN) -> 42427
03a6 (UIN) -> 42499

$ ./date_calk.sh
Дата ошибки (date 42427)= 28.02.2016

$ ./date_calk.sh
Дата ошибки (date 42499)= 10.05.2016

 

вот и проверили

"Дата ошибки" - внимание не обращаем вырезано с моего проверочного башика даты и времени ошибок (error_data)

[InSAn]

Блин! Неистово плюсую

 

Забыл местами байты поменять

[fim]

думаю еще один unknown из списка можно записать в опознанные

там еще дружок (они в паре с 02c60040 ходют)

01 15 0621 04 02c80040 / 0a 4841042a9f050000b903

должен по идее кольнуться

имхо это время

 

upd

так и есть

2016-02-28 14:05:48.608  011506210402c80040 / 0a4841042a9f0500004603
13:58 (7 мин)

2016-02-28 14:31:55.361  011506210402c80040 / 0a4841042a9f0500006003
14:24 (7 мин)

4603 (UIN) -> 2278
6003 (UIN) -> 2304

$ ./date_calk.sh
Дата (date 42427)= 28.02.2016
Время (time 2278): 13:58
$ ./date_calk.sh
Дата (date 42427)= 28.02.2016
Время (time 2304): 14:24

7мин разницы между компом и гтн и там и там

Змінено 10 травня 2016 користувачем fim

[InSAn]

думаю еще один unknown из списка можно записать в опознанные

 

Рано

Непонятно, что за дата...

[fim]

Рано

Непонятно, что за дата...

 

у мну дата сходится с логом

у Вас сегодня?

т.е. текущая дата

 

зы просто у меня остался длинный лог за 28.02.2016 (40 минут) от туда и смотрю

 

upd

думаю, команда из которой еще посмотреть дату и время (qq fe 0700) составлена еще по "внешнему" стандарту, а остальные (дата и время) все имхо по "внутреннему" т.е. UIN - 01/01/1900

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

Вам в какой-то степени проще, т.к. все datetype пишите сами, а мне...

хоть с++ учи

Змінено 10 травня 2016 користувачем fim

[InSAn]

у мну дата сходится с логом

у Вас сегодня?

т.е. текущая дата

Я имел в виду - что обозначает эта дата в команде? Просто "сегодня"? Или время последнего включения насоса (или еще чего)? И есть ли что-то полезного в остальных байтах?

 

Вам в какой-то степени проще, т.к. все datetype пишите сами, а мне...

хоть с++ учи

Я datatype не пишу, а разбираю "на лету".

 

PS: Да я тоже в с++ не шибко силен

 

Добавлено через 2 минуты

думаю, команда из которой еще посмотреть дату и время (qq fe 0700) составлена еще по "внешнему" стандарту

Я ее "разобрал" одной из первых - она полностью соответствует OSI-7