Sfera-perm.ru

Сфера Пермь
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Opc сервер для счетчиков псч

OPCDataStore (OPC Server) v2.41 — программа OPC-сервер

Программа (OPC-сервер) предназначена для автоматизации сбора информации с приборов производства НПП «Элемер» и передачи считанных данных другим программам верхнего уровня, поддерживающих OPC-технологию (большинство современных SCADA-систем).

OPC (OLE for Process Control) — набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления. OPC-технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.

В спецификации OPC для обмена данными определены два компонента: OPC-клиент и OPC-сервер.

OPC-сервер — компонент, получающий данные во внутреннем формате устройства или системы и преобразующий эти данные в формат OPC. OPC-сервер является источником данных для OPC-клиентов.

OPC-клиент — компонент, принимающий от OPC-серверов данные в формате OPC и преобразующий их во внутренний формат устройства или системы.

OPC-клиент общается с OPC-сервером посредством строго определенных в спецификации интерфейсов, что позволяет любому OPC-клиенту общаться с любым OPC-сервером. Однажды созданный OPC-сервер позволяет подключать устройство к широкому кругу программного обеспечения (SCADA-системам, HMI и др.), поддерживающего спецификацию OPC.

Использование OPC-технологии позволяет с легкостью использовать различные приборы и измерительные системы разных производителей при построении многофункциональных автоматизированных систем управления технологическими процессами (АСУТП) с возможностью масштабирования и взаимозаменяемости программных и аппаратных средств.

Основные функции программы

Основные функции программы следующие:

  • многопортовый, многоприборный и многоканальный сбор данных с приборов, выпускаемых НПП «Элемер»;
  • периодический опрос приборов согласно конфигурируемым настройкам;
  • автоматический поиск приборов на портах с возможностью ручного добавления и изменения;
  • установка индивидуальных интервалов опроса для каждого канала;
  • передача данных другим программам, поддерживающим OPC-технологию;
  • обработка нештатных ситуаций (отсутствие данных от приборов по истечение заданного времени (timeout), ошибка в данных и т.п.);
  • управление и конфигурация из программы верхнего уровня любого прибора в измерительной сети согласно его протокола обмена;
  • обеспечение возможности работы как на отдельном ПК, так и в составе локальных сетей;
  • транслирование тэгов других OPC-серверов в каналы OPCDataStore.

Программа поддерживает одновременный сбор данных с большого количества приборов, объединенных в единую измерительную сеть и подключенных к последовательным портам ПК. Универсальность OPC-технологии и ПО OPC Server позволяет использовать в одной сети приборы различного типа, с разным количеством опрашиваемых каналов и подключенные через один или несколько COM-портов.

Существует возможность сконфигурировать периодичность опроса каждого прибора (канала) в сети.

Процесс передачи данных осуществляется с помощью технологии COM/DCOM, при этом используется внутрипроцессорный сервер, созданный в соответствии со стандартом OPC. Данный сервер осуществляет полный анализ подключений и передает диагностическую информация по OPC-каналам.

Программа может быть использована для чтения измеряемых величин и отображения их на дисплее ПК в реальном масштабе времени.

Обмен с приборами осуществляется через последовательный интерфейс связи RS-232/485 с использованием ASCII-протокола передачи данных.

OPCDataStore позволяет с помощью программу верхнего уровня, поддерживающей интерфейс OPC, организовать обмен данными с любым прибором в сети согласно протокола обмена для приборов соответствующего типа.

Также программа имеет в своем составе встроенный OPC-клиент, с помощью которого возможно получение данные каналов других OPC-серверов и транслирование полученных значений в каналы OPC-сервера. Программа предназначена для работы с OPC-клиентом, установленном на другом ПК в локальной сети, либо на локальном компьютере.

OPCDataStore 2.34 — новая версия от 19.10.2007 г.

Изменения в версии 2.34:

  • добавлена поддержка новых приборов, в том числе РМТ 69 и РМТ 59;
  • несколько изменён и ускорен алгоритм опроса приборов;
  • увеличена помехоустойчивость путём введения перезапроса на сбойных каналах;
  • добавлена функция автоисключения из опроса неотвечающих каналов/приборов;
  • появилась возможность изменять тип передаваемых по ОРС-каналу данных (строка или число);
  • для приборов ИРТМ 2402/М3 добавлены ОРС-тэги с состоянием уставок на каналах;
  • упрощена система команд для работы с тэгом ‘device exchange’;
  • исправлена проблема утечки памяти при работе с приборами ИРТМ 2402/М3;
  • другие изменения.

OPCDataStore 2.40 — новая версия от 9.06.2008 г.

Изменения в версии 2.40:

  • добавлена команда быстрого обмена с РМТ 59 (работает только с новой прошивкой приборов). Период опроса 12 каналов — 130 мс на скорости 57600. Внимание. Период опроса задаёт первый канал прибора РМТ 59. Для максимальной частоты опроса установите период опроса Channel1 равным 0 сек;
  • числовые данные по ОРС-каналу стали типа float (4 байта) вместо double;
  • реализовано чтение дискретных входов приборов ИРТМ 2402/М3Ех-2;
  • проведён анализ скорости обмена с ИРТМ 2402/М3 — 1 прибор за 20 мс при скорости 57600;
  • существенно ускорены функции алгоритма чтения значений приборов по СОМ-порту;
  • добавлена функция синхронизации времени в приборах ИРТМ 2402/М3 и РМТ 59 с возможностью изменения периода синхронизации в настройках программы.

OPCDataStore 2.41 — новая версия от 9.07.2008 г.

Изменения в версии 2.41:

  • исправлена ошибка утечки памяти при работе с приборами РМТ 59;
  • в настройках программы добавлена возможность изменения числа перезапросов к прибору до получения ошибочного значения канала.

OPC server

ОРС-серверы производства Kepware

Kepware — мировой лидер в коммуникационном программном обеспечении для автоматизации предлагает уникальный опыт в области встроенных устройств связи и технологии ОРС server. Основное направление разработок Kepware – драйверы коммуникации с контроллерами автоматизации, устройствами ввода/вывода и полевыми устройствами. Драйверы работают с операционными системами Microsoft Windows Desktop, Server и Embedded (Windows CE и Windows NT/XP Embedded). На данный момент существует свыше 130 коммуникационных протоколов.

ОРС-серверы, разработанные ИнСАТ:

  • OPC-сервер Modbus Universal MasterOPC
  • OPC сервер для связи со счетчиками «Меркурий»
  • OPC сервер для связи со счетчиками «Энергомера»
  • OPC сервер для протокола SNMP
  • OPC-сервер протокола МЭК-61850
  • OPC-сервер для связи с SCADA-пакетом MasterSCADA
  • OPC-сервер для связи с контроллерами MasterPLC

OPC-серверы в стандарте OPC DA и OPC HDA других производителей.

Отличия OPC-серверов разработки ИнСАТ от OPC-серверов других производителей

Наши серверы имеют ряд достоинств по сравнению с другими производителями. Среди этих преимуществ можно выделить:

Расширенная функциональность в рамках технологии OPC:

  • наш OPC server создание произвольной иерархии групп переменных;
  • индивидуальная настройка контроллеров групп и переменных;
  • удаленный с других компьютеров доступ к серверу;
  • поддержка расширителей портов и 8-канальных адаптеров;
  • мониторинг значений переменных;
  • первичная обработка и преобразование типа переменной;
  • присвоение значений переменным;
  • возможность защиты от записи;
  • временная блокировка опроса переменных;

Наш OPC server имеет гибкие возможности пользовательского интерфейса:

  • конфигурирование с наследованием настроек
  • импорт списков переменных из систем программирования контроллеров
  • имитация значений переменных в целях отладки по одному из нескольких законов
  • общая оболочка для нескольких OPC-серверов, упрощающая эксплуатацию и настройку серверов, а также снижающая затраты на их приобретение
  • возможность ввода комментариев ко всем элементам конфигурации
  • экспорт конфигурации в файл документации для печати
  • полнофункциональная демоверсия
    Повышенная надежность и развитая диагностика
  • автоматическое восстановление соединения в случае разрыва связи с контроллером
  • вывод сообщений о нарушениях работы сервера в специальное окно и сохранения их в файле протокола
  • формирование признаков качества каждого значения, передаваемого программе-клиенту и отображения их в таблице значений OPC-сервера
  • вывод содержимого передаваемых по каналу связи пакетов данных в специальное окно и сохранение их в файле
  • наличие специальной программы для резервирования получаемых данных
    Средства работы через Интернет
  • возможность доступа OPC-клиентов через Интернет
  • поддержка технологии SLa-ON™ (ProLAN) для просмотра и анализа данных из OPC-серверов с помощью обычных браузеров
    Открытость и следование стандартам
  • соответствие последним редакциям международного стандарта технологии OPC Data Access в полном объеме (многие серверы удовлетворяют только части требований)
  • импорт и экспорт конфигураций в формате CSV (может быть создана в любой электронной таблице, например Exсel, или базе данных типа Access
  • инструментарий для разработки пользователем собственных OPC-серверов
  • большинство серверов протестировано со следующими SCADA-пакетами: InTouch, Fix, Genesis, Master SCADA, RSView, Trace Mode (если Вы проверяли наши серверы с другими SCADA-пакетами — просьба сообщить)

Новый OPC-сервер от Моха способен повысить эффективность любой SCADA-системы

В настоящее время модули ввода/вывода способны получать данные как с помощью опросов, так и в результате приёма оповещения о произошедших событиях. Существуют некоторые общие правила, которые позволяют определить, какой метод обновления данных лучше подходит для конкретных задач.

Около десяти лет назад модули ввода/вывода сигналов были простыми неинтеллектуальными устройствами. Они могли делать только две вещи: измерять показания (температуры, давления, событий и др.) и по запросу отправлять полученные данные в цифровом виде. По этой причине стандарт OPC (технология OLE для управления процессами) представляла собой модель опроса «клиент-сервер», то есть центральный OPC-сервер настраивался на опрос датчиков сигналов. Но поскольку сервер мог и не знать заранее об изменениях в показаниях датчиков, его можно было запрограммировать на опрос различных устройств с определенной периодичностью, что в итоге могло привести к большим нагрузкам на сети.

В это же время компании, являющиеся лидерами в производстве систем сбора данных, представили интеллектуальные устройства удаленного ввода/вывода, которые способны самостоятельно инициировать установку соединения с OPC-сервером. Например, модули серии ioLogik от компании Moxa способны отслеживать значение сигналов и самостоятельно передавать эти данные в программу Active OPC Server, в которой используется «технология связи по событию». Это позволяет нагружать сеть связи исключительно в моменты изменения состояния сигналов.

Позднее, уже в 2008 году, OPC Foundation сумел стандартизировать в едином OPC-стандарте (OPC UA) схему «оповещение по событию» (report by exception), использующую систему «подписка и мониторинг элемента» (subscription and monitored item). Это создало множество новых способов построения распределенных систем сбора данных. OPC UA является совершенно новым стандартом, который позволяет настраивать вид взаимодействия OPC-сервера с различными устройствами ввода/вывода непосредственно в SCADA-системе.

В данной статье мы объясним разницу между «обновлением данных в результате опроса» и «обновлением данных в связи с возникновением события», а также озвучим некоторые общие правила, которые позволяют определить, какой метод больше подходит для конкретных устройств ввода/вывода. Кроме того, мы представим Вашему вниманию новое решение от компании Moxa – сервер MX-AOPC UA.

Обновление данных в результате опроса или события

В течение многих лет «обновление данных путем опроса» было промышленным стандартом связи между OPC-серверами и клиентами. Сегодня же перед инженерами стоит выбор между обновлением данных путем проведения опроса или в результате возникновения события. Выбор зависит от частоты изменения контролируемых сигналов, а также от уровня необходимой точности. Если показания датчиков часто меняются, то и записываться в SCADA они должны постоянно – это позволит получить полную картину изменений данных. С другой стороны, для датчиков, которые меняют свои показания довольно редко, требуется совсем небольшая пропускная способность сети.

Для управления передачей данных между OPC-сервером и SCADA-клиентами в технологии OPC UA используется функция «подписки и мониторинга элемента». С помощью нее SCADA-клиенты могут присоединяться к набору наблюдаемых элементов, после чего сервер «публикует» показания, получаемые с предварительно настроенной частотой (Рисунок 1). В данном случае «публикует» означает, что сервер отправляет полученные показания клиенту.


Рисунок 1: Функция управления и мониторинга устройств

Для того чтобы данная функция работала на устройствах ввода/вывода должны быть настроены два режима: интервал выборки и интервал публикации (Рисунок 2). Интервал выборки представляет собой скорость, с которой сервер проверяет наличие изменений в контролируемых устройствах. А интервал публикации – скорость, с которой сервер отсылает уведомления клиенту. Интервал выборки может быть короче, чем интервал публикации, и зарегистрированные данные могут вставать в очередь на сервере до тех пор, пока не истечет интервал публикации. В этот момент сервер посылает клиенту все уведомления.


Рисунок 2: Пример настройки для управления и мониторинга устройств

Используя механизм «оповещения по событию», можно существенно экономить сетевой трафик в тех ситуациях, когда состояние системы на протяжении длительного времени не меняется и, соответственно, показания устройств ввода/вывода не передаются. Это особенно актуально, когда частота изменения значений гораздо ниже, чем интервал опроса, например, при мониторинге открытия/закрытия редко используемой двери. Этот механизм, оповещения при возникновении события, экономит вычислительные ресурсы как клиента, так и серверов, поскольку уменьшается обработка тайм-аутов и повторных попыток передачи данных. Кроме того, если частота изменения значений выше, чем интервал опроса, а точность данных имеет решающее значение, обновление данных в виде исключения станет наилучшим решением для такой системы.

Стоит учитывать, что этот метод может привести к возникновению проблем, если в течение короткого промежутка времени будет необходимо передать большой объем данных. Это может вызвать перегрузку сети. Эту проблему можно решить, установив, например, «мертвую зону» для аналоговых данных или «обрезав» данные с числовыми вычислениями еще до момента их отправки.

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

Для того чтобы получать данные с подключенных устройств большинство серверов OPC UA используют протоколы опросного типа, например, Modbus. Но опрос, производимый по сотням или даже тысячам тегов, не будет эффективным. Если оборудование поддерживает передачу данных как в результате опроса, так и события, то у Вас появляется возможность выбрать наиболее подходящий способ чтения данных по классификатору (Рисунок 3), тем самым увеличивая эффективность работы.

Точность данных
Частота изменения данных
КритичноНе критично
Высокая частотаОбновление данных по событию
(с установлением соответствующей «мертвой зоны»)
Обновление данных методом опроса
(с коротким интервалом выборки)
Низкая частотаОбновление данных в результате событияОбновление данных методом опроса

Рисунок 3: Выбор метода передачи данных: по опросу или по событию

Сервер Moxa OPC UA — MX-AOPC UA

В сервере MX-AOPC UA расширена запатентованная компанией Moxa технология мониторинга «Active OPC». Кроме того, сервер поддерживает протокол Modbus и обеспечивает надежность передачи данных между устройствами и удаленной SCADA-системой.

Компания Moxa была инициатором создания технологии сбора данных «по событию», представив свой сервер «Active OPC». Запатентованный сервер MX-AOPC UA позволяет получать данные, собранные как с помощью опросов, так и в результате произошедших событий (Рисунок 4).


Рисунок 4: Выбор типа связи MX-AOPC UA

Логика проектирования сервера была основана на выполнении пользовательских задач. На рисунке 5 показано, каким образом пользователи могут создавать группы устройств, например, под названиями «SiteA» и «SiteB». В данном примере каждый узел использует один и тот же модуль ввода/вывода ioLogik E1210, чтобы контролировать состояние насоса.


Рисунок 5: Группировка устройств на основе задач пользователя

При настройке SCADA-системы имена тегов (Рисунок 6) представлены наиболее удобным для чтения способом.


Рисунок 6: Удобные имена тегов

Широкий выбор оборудования Moxa для сбора данных

Компания Moxa представляет широкий спектр надежных промышленных решений, предназначенных для сбора данных, в том числе простое в использовании программное обеспечение, позволяющее выполнять задачи в области промышленной автоматизации. Дополнительно к ставшим популярным модулям ioLogik серий Ethernet E1200 и E2200, а также GPRS/3G-серии ioLogik W53xx, в 2015 году стали доступны для заказа следующие модули удаленного ввода/вывода серии ioLogik E2500:

  • ioLogik 2512: модули с 8 x DI, 8 x DIO, программирование Click&Go Plus
  • ioLogik 2512-T: модули с 8 x DI, 8 x DIO, программирование Click&Go Plus, с диапазоном рабочих температур -40°

+75 C°

  • ioLogik 2542: модули с 4 x AI, 12 x DIO, программирование Click&Go Plus
  • ioLogik 2542-T: модули с 4 x AI, 12 x DIO, программирование Click&Go Plus, с диапазоном рабочих температур -40°

    Получить более подробную техническую консультацию, взять на тестирование и приобрести оборудование MOXA в России можно у официального партнера производителя – компании «Ниеншанц-Автоматика»: (495) 980-64-06, (812) 326-20-02, (343) 311-90-07, (383) 330-05-18 или e-mail: sales@moxa.ru,support@moxa.ru.

    Оригинал новости представлен на сайте компании Moxa Inc.

    Кроссплатформенный OPC UA Сервер

    В общем, потребовалось передавать данные по OPC UA, загвоздка в том, что пилить свою реализацию нет времени, а сервер должен работать на x86-64 Windows & Linux, а так же на ARMv7.

    Может есть какие-то либы или sdk для создания данного сервера, можно платные, цена в несколько тыщ баксов значения не сыграет.

    • Ссылка

    А то, что перечислено в Wikipedia уже смотрели и ничего не подошло?

    • Показать ответ
    • Ссылка

    И что тебя смутило в http? если не брать бинарную реализацию?

    • Показать ответ
    • Ссылка

    Эм, смотрел только в русской вики и даже не видел этих ссылок, спасибо. Буду смотреть =)

    • Ссылка

    Брать надо обе ибо заказчик хочет

    • Показать ответ
    • Ссылка

    Там тебя пнули где посмотреть, есть реализации на пистонет, жабе, выбирай на вкус

    • Показать ответ
    • Ссылка

    Какой пистонет и жаба на ARMv7, смеётесь что ли?

    • Показать ответы
    • Ссылка

    понятно, каши не сваришь, раз такой очередной удивленный возглас

    Тогда бы писал конкретней, что тебе хочется — си, плюсы

    И то и другое тоже есть

    • Показать ответ
    • Ссылка
    • Показать ответ
    • Ссылка

    Тогда бы писал конкретней, что тебе хочется — си, плюсы

    • Ссылка

    Warning: The sample server is not a complete server, and a number of security related features are missing. Please refer to Mantis Issue #3949 for details.

    • Показать ответ
    • Ссылка

    можно платные, цена в несколько тыщ баксов значения не сыграет.

    ты вот весь такой противоречивый

    тут походу не вопрос надо задавать, а сразу в джоб

    • Показать ответ
    • Ссылка

    А в чём противоречие?! В том, что сервер по ссылке не готов, а мне нужен готовый сервер в продакшен. Если есть платный аналог, это тоже устроит, просто выберу что больше подходит под задачу, всё равно окупиться.

    Pthon / Mono / Java — не подходят, ибо на железке с армом кроме OPC там уже вертится миллион служб и производительность ОЗУ на исходе.

    C / C++ или другой язык не будет иметь значение, главное чтобы был C ABI.

    тут походу не вопрос надо задавать, а сразу в джоб

    О да конечно, что бы получить чей-то недовысер который ровно столько же придётся адаптировать под проект, как если бы я взял опенсурсное решение.

    • Ссылка

    нет такого, под никсами используется МЭКовский протокол, который обычно поддерживается нашими сырьевиками

    • Показать ответ
    • Ссылка

    Эм. Кем используется? 0_о

    • Показать ответ
    • Ссылка

    газовиками/нефтевиками и прочими алмазными шахтами. или у вас прям под нужды производства? О_о

    • Показать ответ
    • Ссылка

    У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0

    • Показать ответы
    • Ссылка

    • Показать ответ
    • Ссылка

    У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0

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

    • Показать ответы
    • Ссылка

    У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0

    а есть разница? мэк все поддерживают в 2к17, но часто заказчики все протоколы просто называют орс, тк он брат сестры директора, но тз выдать надо. постоянно у кого-то появляется желание забомбить орс под никсы и все заканчивается на мэк 🙂

    • Ссылка

    Мы вот для заведения датчиков и счётчиков модбасим, в основном.

    • Показать ответы
    • Ссылка

    Мы вот для заведения датчиков и счётчиков модбасим, в основном

    это если к компу со скадой напрямую цеплять датчики. орс или мэк появляются когда система дофига распределенная, особенно с узкими каналами до сервера со скадой и логами. по спутнику или gprs модбас особо не погоняешь 🙂

    • Показать ответ
    • Ссылка

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

    И у меня стойкое ощущение, что он не понимает, что такое OPC и хотит его прям в контроллер запихать.

    • Показать ответ
    • Ссылка

    В реальности всё наоборот. По gprs гоняют modbus TCP и на 9600 (условно) спокойно сливают данные за считанные секунды.

    У меня в практике только один случай был, когда к скаде напрямую (завод, витая пара до объекта 1 км) подключение.

    МЭК в этом отношении хуже модбаса, т.к. он ASCII (соответственно числа передаются текстом: 112432.34 против 4 байт в модбасе, например).

    • Показать ответы
    • Ссылка

    А нет, вру. Ещё по радиоканалу оборудование было. «Напрямую» можно считать потому что радио просто удлиняло кабель. А так в системе как com порт виделось и объекты по-очереди надо было опрашивать.

    • Ссылка

    В реальности всё наоборот. По gprs гоняют modbus TCP и на 9600 (условно) спокойно сливают данные за считанные секунды.
    У меня в практике только один случай был, когда к скаде напрямую (завод, витая пара до объекта 1 км) подключение.
    МЭК в этом отношении хуже модбаса, т.к. он ASCII (соответственно числа передаются текстом: 112432.34 против 4 байт в модбасе, например).

    похоже мы немного о разных реальностях 🙂

    Если на объекте под пару сотен датчиков, а до него только спутник, или, в лучшем случае, gprs, и на это все требование, чтобы оператор имел возможность реагировать на нештатные ситуации в реальном времени. Т.е. чтобы если например давление закинет, или пожар какой, он не ждал по несколько минут. Если все это добро опрашивать напрямую через modbus tcp, то нужно будет интервал опроса выставлять в совершенно неприличные значения. При этом обычно на таких объектах состояние +/- стабильное, а трафик платный, поэтому постоянный опрос такого количества устройств с получением одних и тех же значений обойдется неадекватно дорого. Вот тут и пригождается ОРС или МЭК: на узлах выставляются уставки на параметры и их приоритезация по любой упоротой логике, контроллер на месте опрашивает все по модбасу и только если изменение параметра выходит за уставку передает по спутниковому каналу. ПрофИт.

    • Ссылка

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

    Да нафига мне МЭК которого нет в контракте?! Есть только OPC UA по ТЗ =)

    • Показать ответ
    • Ссылка

    Да нафига мне МЭК которого нет в контракте?! Есть только OPC UA по ТЗ =)

    • Показать ответ
    • Ссылка

    Спасибо, мне на такую херню везёт, то OPC, то транслятор какой-то надо написать, ну ёпрст, весь год такой =)

    • Ссылка

    И у меня стойкое ощущение, что он не понимает, что такое OPC и хотит его прям в контроллер запихать.

    голоса
    Рейтинг статьи
    Читайте так же:
    Во все ли дома поставят общедомовые счетчики
  • Ссылка на основную публикацию
    Adblock
    detector