вторник, 7 июня 2011 г.

Transaprent Ready - Сервис отправки электронных сообщений (e-mail)

Привет тебе, читатель se-automation! Сегодня я хотел бы рассказать от сервисе отправки email сообщений контроллерами Schneider-Electric. Итак, сервис e-mail сообщений позволяет приложению ПЛК уведомлять пользователя о возникновении контроллируемых ситуаций, используя email клиент, работающий в Ethernet-модуле. Обычно ПЛК автоматически генерирует короткие электронные сообщения, что-бы сообщить пользователю о:
  • тревогах;
  • возникновении событий;
  • производственных отчетах;
  • напоминаниях о необходимости тех. обслуживания;
  • изменениях в производственном цикле;
  • другой информации, которая разработчикам системы покажется важной.



Сервис требует создания предопределенных заголовков (headers) сообщений (включающих имя отправителя, адреса получателей, и тему сообщения) которые могут использоваться с любым телом сообщения. Некоторые устройства позволяют включать в письмо текущие параметры машины или процесса динамически в ходе выполнения приложения (M340 со встроенным Ethernet и в меньшей мере Premium и Quantum со внешними модулями или встроенными Ethernet портами); другие устройства позволяют использовать лишь предопределенные сообщения (Factory Cast HMI модули Premium и Quantum, а также Factory Cast HMI шлюзы ETG30xx). Обычно при разработке, возможные ситуации требующие оповещения оператора классифицируются и для каждой группы ситуаций создается свой шаблон.
Понятно, что такой сервис ни в коем случае не должен заменять собою стандартную систему АПС на основе SCADA или панели ЧМИ, но будет полезен как дополнительная возможность информирования. Также необходимо учитывать возможные задержки сообщений на стороне SMTP-сервера, которые зависят от очереди сообщений и скорости их обработки. Таким образом, критичные оповещения такой системе врядли можно поручить, но сервисная или статусная информация через email - это вполне удобно.
Рассмотрим детальнее работу сервиса. Собственно работа мало чем отличается от стандартного взаимодействия email клиента и SMTP-сервера, но все же. Как уже говорилось выше, работа сервиса электронных сообщений возложена на email-клиент, встроенный в комуникационный модуль Ethernet (встроенный в ПЛК либо размещенный в одной корзине с процессором). При возникновении события, требующего оповещения, Ethernet модуль использует протокол SMTP (стандартный порт №25) для связи с почтовым сервером. Почтовый сервер в свою очередь, доступен для всех клиентов сети предприятия либо имеет доступ к Internet. Далее, в случае принадлежности указанного адресата получателя другому SMTP-серверу, локальный почтовый сервер передает сообщение удаленному почтовому серверу, либо оставляет его у себя, пока адресат не запросит новые сообщения через POP3 или IMAP протокол.

  1. - возникновение отчетного события;
  2. - срабатывание функции отправки сообщения;
  3. - пересылка сообщения почтовому серверу;
  4. - если необходимо, передача сообщения другому почтовому серверу;
  5. - сохранение сообщения в почтовом ящике адресата;
  6. - отображение сообщения почтовым клиентом получателя.
Повторюсь, что обработка сообщения почтовыми серверами занимает некоторое время, поэтому в почтовым клиенте получателя оно появляется с задержкой. Задержку вполне возможно оценить если учетные записи отправителя и получателя находятся на одном почтовом сервере.
Рассмотрим пример формирования сообщения при отказе одного из насосов насосной станции. В примере используется функциональный блок SEND_EMAIL для встроенного Ethernet порта ПЛК M340.
Примечание: блок SEND_EMAIL на даном этапе (Unity Pro 4.1) работает лишь со встроенным Ethernet портом контроллеров BMX P32 2020/BMX P34 2030/BMX P34 20302. NOE модулями M340 функция отправки сообщений не поддерживается.
В ПЛК Premium и Quantum отправка сообщений реализуется несколько иначе. Об этом мы и поведем речь далее.
Итак, первым отличием настройки email в Premium/Quantum от M340 является то, что первичная настройка сервиса SMTP производится через встроенный Web-сервер контроллера, а не средствами Unity Pro при разработке проекта. Хотя, необходимо заметить, поля для заполнения остаются теми же, а также остаются все те же 3 header-а. Вторым и наиболее существенным отличием является использование для отправки сообщений функционального блока SEND_REQ вместо SEND_EMAIL, и вместе с этим связаны все остальные отличия.
Ко входу ADR мы подключаем блок преобразования адресов ADDR, которому в свою очередь подсовываем адрес в следующем текстовом формате: {сеть.станция}корзина.модуль.канал.SYS, где сеть.станция это X-WAY адрес Ethernet-модуля. Для моего примера адрес будет выглядеть следующим образом:
Для отправки сообщений с помощью SEND_REQ вход CODE всегда должен получать значение 0x37 (16#37).
EMIS является буфером отправки сообщения, который формируется следующим образом:
Заголовок Значение Байт № Регистр №
Сегмент 0x96 1 1
Тип 0x15 2
Адрес 0x00 2 2
4
Кол-во символов +2 0x00 5 4
<=240 6
Заголовок письма 1, 2 или 3 7 5
0x00 8
Текст письма


У меня массив получился вот таким:
где 0E это количество символов сообщения + 2, а 16#0001 это использование первого заготовленного header-а. Обратите внимание на порядок следования байтов в словах.
GEST - это массив управляющей информации на четыре слова, в котором указывается таймаут, результирующий код операции и, ВНИМАНИЕ, размер буфера EMIS в байтах (2-й байт 4-го регистра).
Выход RECP не выполняет никакой функции, однако 2-х регистровый массив для корректности необходимо прилинковать.
Несколько иначе отправка электронных сообщений настраивается в Factory Cast HMI модулях. В этом случае все возможные варианты сообщений настраиваются на этапе программирования и в процессе работы не могут быть изменены (за исключением подстановки значения переменной на момент отправки сообщения). Зато общее количество сообщений ограничено значением 100 (чего будет достаточно для большинства небольших систем), а также добавлена возможность работы с 2-мя различными почтовыми серверами одновременно.

Комментариев нет:

Отправить комментарий