асуип https support russianpost ru portal

Countable Data Brief

Russianpost. ru is tracked by us since April, 2011. Over the time it has been ranked as high as 2 029 in the world, while most of its traffic comes from Russian Federation, where it reached as high as 73 position. Support. russianpost. ru receives about 24. 69% of its total traffic. It was owned by several entities, from FGUP “Russian Post” to JSC Russian Post, it was hosted by Internet Assigned Numbers Authority, JSC “Russian Post” and others. While RUCENTER-REG-RIPN was its first registrar, now it is moved to RU-CENTER-RU.

Support. russianpost has the lowest Google pagerank and bad results in terms of Yandex topical citation index. We found that Support. russianpost. ru is poorly ‘socialized’ in respect to any social network. According to MyWot, Siteadvisor and Google safe browsing analytics, Support. russianpost. ru is a fully trustworthy domain with no visitor reviews.

Награды проекта

Проект в «Почте России» награжден специальным призом конкурса «ITSM-проект года 2017»(ITSMFRussia).

Профиль компании

АО «Почта России» – федеральный почтовый оператор, входит в перечень стратегических предприятий РФ. Предприятие охватывает 10 макрорегионов, в его структуре – 82 региональных филиала, 759 почтамтов и около 42 000 отделений почтовой связи. Предоставляя услуги почтовой связи на всей территории России, «Почта России» объединяет один из самых больших трудовых коллективов – около 350 тысяч почтовых работников.

Ежегодно «Почта России» принимает около 2,5 млрд писем и счетов (из них 1 млрд – от госорганов) и обрабатывает порядка 297 млн посылок. Почтовый оператор обслуживает около 20 млн подписчиков в России, которым доставляется 1 млрд экземпляров печатных изданий в год. Ежегодный объем транзакций, проходящий через «Почту России», составляет более 3,3 триллиона рублей (пенсии, платежи и переводы).

Предпосылки проекта

В рамках реализуемой «Почтой России» стратегии цифровой трансформации создание комплексной автоматизированной системы управления ИТ (АСУИП) – технологической основы для внедряемого Единого центра поддержки пользователей – стало одной из приоритетных задач предприятия.

Основные факторы, обусловившие необходимость создания АСУИП:

различный уровень зрелости процессов и различное качество ИТ-услуг для потребителей в разных регионах работы почтового оператора;
высокая степень неопределенности состава и структуры ИТ-процессов;
децентрализованная структура полномочий в части оперативных решений по управлению ИТ-процессами при централизованной системе принятия стратегических решений и контроля;
отсутствие прозрачности в работе внешних поставщиков ИТ-услуг (подрядных организаций).

Исполнителем проекта по созданию АСУИП была выбрана российская компания NAUMEN, обладающая многолетним опытом в области разработок и внедрения ITSM-систем на основе собственных решений.

Благодаря построению комплексной системы обеспечен качественно новый уровень обслуживания пользователей. Процессы предоставления ИТ-услуг централизованы и унифицированы с охватом всех макрорегионов, что позволило повысить в разы показатели результативности. К работе в новой АСУИП подключены более 6900 специалистов ИТ компании. Одновременно в Naumen Service Desk работают более 3500 пользователей. Система спокойно выдерживает высокую нагрузку. Так, количество различных атомарных транзакций в пике – до 2 миллионов в час, обеспечивается штатными средствами платформы NAUMEN. При этом в реализованной архитектуре имеется большой потенциал по поддержанию планового уровня производительности АСУИП в случае многократного увеличения объемов

Цели и задачи проекта

Обеспечение стабильной работы важных для бизнеса систем и компонентов ИТ-инфраструктуры;
Обеспечение единого стандарта качества оказания ИТ-услуг в масштабах всей распределенной структуры предприятия;
Минимизация простоя операционных окон, оказывающих почтовые услуги населению, за счет качественной техподдержки, оперативному выявлению и устранению сбоев в ИТ;
Повышение лояльности клиентов:
• централизация и унификация процессов ИТ-управления;
• организация единой службы ServiceDesk;
• автоматизация ИТ-деятельности со сквозным процессным охватом;
• создание интеллектуального пользовательского web-портала с предоставлением пользователям ИТ-услуг мобильного доступа к сервисам портала;
• построение сервисного подхода за рамками ИТ (управление бизнес-процессами);
• построение механизма контроля внешних поставщиков услуг в соответствии с договорами об уровне обслуживания;
• разработка модели отчетности по качеству оказания ИТ-услуг.

Созданное NAUMEN решение – по сути это можно назвать multitenancy в единой инсталляции с прозрачным обменом данными между всеми участниками компании и сквозным контролем всех участников. Система позволяет менеджерам корпоративного центра получать единую управленческую отчетность по всем филиалам и подрядчикам, а также – вовлекает мелких подрядчиков в единые процессы заказчика, предоставляя им унифицированный Service Desk. Автоматически выстраивает услуги и запросы в «пирамиды», где нижестоящие услуги и запросы поддерживаются вышестоящими. При этом обработка запросов осуществляется одновременно по всей «пирамиде». Такой механизм позволяет легко анализировать структуру взаимной поддержки услуг и отдельные услуги, оперативно выявлять нарушения параметров предоставления услуг. Реализованный принцип существенно снижает трудозатраты и повышает качество предоставления услуг

О проекте

В настоящий момент завершены два из четырёх этапов крупного проекта, реализуемого компанией NAUMEN в «Почте России».

Новая автоматизированная система (АСУИП) была запущена в опытно-промышленную эксплуатацию сначала в пилотных макрорегионах (Москва, Санкт-Петербург, Дальний Восток), а затем тиражирована на остальные регионы присутствия почтового оператора (7 макрорегионов).

Работы по двум этапам включали задачи разного уровня сложности, в т. , проектирование и автоматизацию процессов управления инцидентами, запросами на обслуживание и изменениями, разработку документации, обучение работе в системе ИТ-специалистов «Почты России» и подрядчиков. Комплексная система успешно интегрирована в единую технологическую среду управления деятельностью «Почты России». За счет разработанного NAUMEN универсального интеграционного механизма реализовано взаимодействие с внешними и внутренними системами: обеспечивается эффективный обмен данными со службой каталогов Active Directory, системой мониторинга, почтовым сервисом, телефонией.

Помимо учетных алгоритмов и инструментов в основе автоматизированной системы, разработанной NAUMEN, – прогрессивные технологии машинного обучения и обработки естественного языка, которые обеспечивают интеллектуальную обработку больших массивов данных с охватом всех процессов обслуживания, создавая ценности для различных групп пользователей на основе смыслового анализа информационных потоков. Интеллектуальная система способна выполнять автоматическую классификацию и маршрутизацию запросов, анализировать массовые инциденты и рекомендовать способы решения проблем, автоматически определять ответственных и формировать рабочие группы, – все эти технологические инновации ускоряют работу техподдержки, исключают простой, снижают затраты и улучшают бизнес-процессы предприятия.

В системе реализован современный web-портал самообслуживания, содержащий личный кабинет, встроенную Базу знаний, навигатор запросов, ленту новостей и прочие удобные сервисы для пользователей ИТ-услуг. Портал очень востребован среди пользователей и на сегодня является основным каналом передачи запросов в службу поддержки: через него поступает 77% от общего количества входящих обращений. Сотрудники почты легко и быстро оформляют запрос в личном кабинете, заполняя поля формы с использованием подсказок поисковой строки. Введенные запросы система автоматически структурирует, классифицирует и маршрутизирует исполнителям. Для самостоятельного решения вопроса можно воспользоваться статьями Базы знаний с рекомендациями, которая пополняется автоматически за счет машинного интеллекта.

Отдельное внимание было уделено задаче повышения контроля за работой подрядных организаций. Как отмечает Сергей Емельченков, зам. гендиректора «Почты России» по информационным технологиям и развитию новых продуктов, «у «Почты России» появилась управляемая собственная точка централизованного контроля – внедренные процессы и технологии позволили отказаться от слабо контролируемых служб поддержки подрядчиков по разным ИТ-услугам, заменив их на единую централизованную службу поддержки».

На текущий момент в системе обрабатываются запросы 170 тысяч пользователей, в перспективе услуги будут оказываться всем 350000 почтовым сотрудникам макрорегионов.

Дальнейшее развитие проекта будет связано с расширением процессного охвата и интеллектуализацией АСУИП. Наряду с предоставлением ИТ-услуг интеллектуальная система будет использоваться как рекомендательный сервис для решения задач HR-службы, помогать выявлять центры влияния внутри коллективов подразделений. Также планируется использование возможностей системы в управлении процессами административно-хозяйственного и жилищно-коммунального отделов (АХО и ЖКО) «Почты России».

Масштабы проекта

Каталог услуг насчитывает 280 позиций;
Обслуживается 160 000 сотрудников ПР;
Обеспечивается управление более 720 000 КЕ;
Обработано более 3 000 000 обращений;
Происходит до 2 млн различных атомарных транзакций (например, изменений статусов и атрибутов) в час;
Работает 6 900 исполнителей по услугам;
Одновременно в системе до 3 500 исполнителей / пользователей

Результаты проекта

Создание на основе передовых разработок NAUMEN инновационной multitetancy-системы – АСУИП –является одним из важных шагов «Почты России» в достижении главной стратегической цели предприятия – стать эффективной, клиентоориентированной и высокотехнологичной компанией, надежным и современным поставщиком почтовых, логистических и финансовых услуг для всей страны.
Возможности единой отказоустойчивой систем обеспечивают централизованное управление свыше 500 объектами разветвленной ИТ-инфраструктуры и около 200 услугами, оказываемыми пользователям всех филиалов и отделений почтовой связи.
Внедрение АСУИП обеспечивает качество клиентского обслуживания и эффективность работы не только ИТ, но и всего предприятия в целом, за счет:
• уменьшения трудоемкости рутинных операций, выполняемых ИТ-специалистами и почтовыми сотрудниками (пользователями ИТ-услуг);
• создания механизма сквозного контроля качества и получения единой управленческой отчетности по всем филиалам и подрядчикам;
• повышения прозрачности предоставления ИТ-услуг в целом и подрядными организациями, в частности.

Для чего нужна регистрация запросов и работа по процессам?

2
Запросы имеют четко определенного ответственного
Запросы имеют четкий срок выполнения
Наиболее важные запросы обрабатываются в первую очередь
Механизм независимого контроля работы подрядчиков
Запросы не теряются
Деятельность по всему предприятию более управляемая, однотипная и
прозрачная для руководства
Построение процессов управления ИТ

Цель презентации

3
Рассказать специалистам об основах системы Naumen
Service Desk в рамках процессов:
Управление Каталогом услуг
Управление
Инцидентами
и
Запросами
обслуживание (ЗНО)
Управление Запросами на изменение (ЗНИ)
Построение процессов управления ИТ
на

Объекты, с которыми выполняется
работа в системе
Услуга
–
действия
или
возможности,
предоставляемые
5
сервисными
подразделениями для Потребителей
ИТ-услуга – Услуга которая базируется в основном на использовании
информационных технологий и предоставляется Пользователям. включает в себя людей, Процессы, технологии. Построение процессов управления ИТ
ИТ-услуга

Объекты, с которыми выполняется работа
в системе
6
Инцидент – событие, которое не является частью нормальной работы Услуги, ведущее/способное
привести к остановке предоставления Услуги или снижению уровня ее качеств;
Запрос на обслуживание (ЗНО) – запрос от Пользователя на поддержку функционирования Услуги,
информацию, консультации или документацию;
Массовый ЗНО – запрос на обслуживание, по которому требуется провести одинаковые работы по
нескольким единицам оборудования или для нескольких расположений
Массовый инцидент – инцидент, являющийся причиной множества других инцидентов. Решение
инцидентов, вызванных массовым инцидентом в АСУИП производится автоматически, синхронно с
массовым инцидентом
Композитный запрос – составной запрос, состоящий из последовательности дочерних запросов
Эти объекты обрабатываются в рамках процесса Управления Инцидентами и Запросами на
обслуживание
Построение процессов управления ИТ

Объекты, с которыми выполняется
работа в системе
7
Предложение об изменении (ПОИ) – поступившее от Пользователя предложение об Изменении
Услуги;
Запрос на изменение (ЗНИ) – запрос, содержащий описание Изменения в текущих функциях Услуги или
дополнительных функций Услуги
Предложения об изменениях и Запросы на изменения обрабатываются в рамках процесса
Управления Изменениями
Построение процессов управления ИТ

Объекты, с которыми выполняется
работа в системе
8
Головной запрос – запрос, которые имеет дочерние запросы;
Дочерний запрос – запрос, который создан в рамках другого запроса. Дочерний запрос может иметь
связанные с ним дочерние запросы;
Задача – задание на выполнение работ в определенный срок определенному исполнителю (только в
управлении изменениями);
Построение процессов управления ИТ

Услуги и Запросы
Группы сотрудников
9
Головной запрос
Запрос
(Обращение)
Управление
инцидентами
Запросы на
обслуживание
Предложения об
изменении
0я линия
1я линия
2я линия
3я линия
Дочерний запрос
1я
2я
линия
линия
3я
линия
4я линия
4я
линия
Каталог услуг
Корневое правило
Услуга
Компонент
Услуги:
Внутренняя
(пользовательская, почтовая)
Внешняя (поддерживающая,
подрядчики)
Компонент
Обязательно указывается
при создании запроса
Дочернее правило
Вид запроса
Построение процессов управления ИТ
Правило
назначения
ответственных
Правило для
поддерживающих
услуг (подзапросы)
Вычисляются снизу вверх
Создается для услуги, указываются ответственные на 1,2,3,4 линиях
поддержки Может быть одно правило для нескольких услуг

Структура услуги и принципы ее поддержки
Внутренняя услуга
1-я линия
Группа 1
2-ая линия
Внешняя
услуга 2
3-я линия
Группа 3
Внешняя
услуга 3
Менеджер
МР
Головной запрос
Группы Почты
России
Группы Почты
России
Группы Почты
Группа 2
4-я линия
11
Менеджер
услуги
Запрос может быть назначен как на группу, так и на услугу
России
Дочерний Запрос
Группы
Подрядчиков
Группы
Подрядчиков
Группы
Подрядчиков

Роли и Оргструктура
Роли:
• Менеджер Каталога услуг
• Менеджер процесса ФГУП АУП
• Менеджер процесса макрорегиона
• Менеджер услуги
• Менеджер по развитию услуги
• Пользователь, Инициатор, Автор
• Ключевой пользователь (Координатор объекта
обслуживания)
• Специалист 0-ой линии поддержки
• Специалист 1-ой линии поддержки
• Специалист 2-4-ой линии поддержки
• Согласующий
• Руководитель группы
• Дежурный группы
• Административный куратор
• Владелец процесса
12
Оргструктура:
АУП ФГУП (Корпоративный центр)
• Макрорегион (Федеральный округ)
• УФПС (Город)
• Почтамт
• ОПС (Почтовое отделение)

Ответственность за запросы
13
• За каждый запрос существует один ответственный – это текущая линия
поддержки
• За поддерживающий запрос также ответственна текущая группа поддержки
• Ответственный за головной запрос ответственен за выполнение запроса
перед пользователем/бизнесом
• Ответственный за дочерний запрос ответственен за выполнение запроса
перед ответственным за головной запрос

Периоды учета Регламентного времени обработки
SLA
Реакция
SLA
SLA
Ожидание
информации
Выполнение
Согласование
Регистрация
Запроса
SLA
Периоды, в которых учитывается
Регламентное время обработки
Периоды, в которых не учитывается
Регламентное время обработки
SLA
16
Периоды, в которых Регламентное время
обработки учитывается только при
определенных условиях
Привлечение подрядчика
Закрытие
Оповещение о
решении
Закрытие
Запроса

Расчет Крайнего срока обработки
17
Регламентное время обработки Запроса
16 часов
Пользователь: ОПС в Услуга: Western Union
Рабочее место оператора
Екатеринбурге
График предоставления
поддержки Услуги
8х5 (9:00 – 18:00 ЕКБ)
3 часа
Регистрация Запроса
чт 15:00 24. 2016
Ночь. Вне графика
График предоставления поддержки
Услуги
8х5 (9:00 – 18:00 ЕКБ)
8 часов
Выходные. Вне графика
График предоставления
поддержки Услуги
8х5 (9:00 – 18:00 ЕКБ)
5 часов
Крайний срок обработки
пн 14:00 28. 2016
(Запрос должен быть решен)

Общая схема процесса
19
INC. Общая схема Процесса управления инцидентами
Этап
Получатель
услуг
Запрос зарегистрирован в
Naumen Service Desk
В управление
конфигурациями
Требуется
переклассификация
Требуется
обновление CMDB
Классификация
запроса изменена
Функция Service Desk
Запрос уточнен
INC-1
Маршрутизация и
устранение
инцидента
Запрос выполнен
Управление знаниями
Функция Service Desk
Запрос
возобновлен. Руководите
ль группы/
Дежурный
Специалисты
Создание
Запросов
Запрос отклонен
Управление Изменениями
Нет постоянного
решения
Требуется Эскалация
Требуется
ЗНИ
Управление Проблемами
В управление
Изменениями
INC-2 Оперативный
контроль Процесса
Корректирующие
действия приняты
Менеджер
процесса
Выявлено
нарушение
Процесса
Требуется Эскалация
Владелец
процесса
Роль, на которую
эскалируют
Участник
процесса
Naumen
Service Desk
ЗНИ реализован
Приняты
административные
действия
Построение процессов управления ИТ
Запрос уточнений
Обработка приостановлена,
Инцидент привязан к Массовому
инциденту

Маршрутизация и выполнение Запросов
20
INC-1. Маршрутизация и устранение инцидента
Naumen Service Desk
Этап
Запрос
зарегистрирован
Из SD-1 Регистрация
запросов
Запрос
возобновлен
Из SD-5 Закрытие
Управление
изменениями
Классификация
Запроса изменена
Из SD-2 Классификация
запросов
Из CHG-13
Реализовано
экстренное
ЗНИ
В CHG-1
Создание
экстренного ЗНИ
Возникла потребность в проведении
работ по Услуге
В SD-1 Регистрация запросов
INC-1. 1 Определение
группы исполнителей
Функция Service Desk
Управление
изменениями
INC-1. 5 Создание
Запросов по
поддерживающим
Услугам
INC-1. 6 Контроль
Дочерних запросов
В CHG-1
Создание ЗНИ
Нет ни обходного
ни постоянного
решения
Обработка приостановлена,
Инцидент привязан к
Массовому инциденту
В управление
Проблемами
Управление знаниями
Да
Есть обходное,
постоянное решение
и требуется ЗНИ
Требуется Эскалация. В INC-2 Оперативный контроль Процесса
Управление знаниями
Запрос выполнен
В SD-5
Закрытие запроса
Да
Есть обходное,
постоянное решение и
требуется ЗНИ
Специалист
Да
Да
INC-1. 3
Диагностика и
устранение
Является
следствием
массового
инцидента?
Нет
Требуется
инициация
Массового
инцидента?
Нет
Требуется
дополнительная
информация?
Нет
Необходима
переклассифика
ция?
Нет
Требуется
привлечение
соисполнителя/
подрядчика?
Нет
Требуется
привлечение
следующей лини
поддержки?
Нет
Требуется
эскалация?
Нет
Применено
постоянное
решение
Да
Да
Да
INC-1. 2
Принятие в
ответственность
Запрос передан на
классификацию
В SD-2
Классификация
запросов
INC-1. 7 Создание
Массового инцидента
Функция Service Desk
Варианты
решения
Есть только
обходное
решение
INC-1. 4 Фиксация
конечных
результатов
Запрос отклонен
В SD-5
Закрытие запроса
В PRB-1 Создание
проблемы
Управление
изменениями
Получатель услуг/
Инициатор/Локальный
координатор
получателей услуг
Дежурный
группы
Функция Service Desk
Функция Service Desk
Обработка приостановлена,
Инцидент привязан к
Массовому инциденту
Функция Service Desk
Запрос уточнен
Из SD-3 Коммуникации с
получателями услуг
Запрос передан на уточнение
В SD-3 Коммуникации с получателями
услуг
Построение процессов управления ИТ
В управление
Проблемами
Требуется
обновление CMDB
В управление
конфигурациями

Комплексный запрос
27
Внутренний запрос
• Внутренний
запрос 1
• Внутренний
запрос 2
Расположение
1/
Конфигурацион
ная единица 1
Расположение
2/
Конфигурацион
ная единица 2
Расположение
4/
Конфигурацион
ная единица 4
Расположение
3/
Конфигурацион
ная единица 3
• Внутренний
запрос 4
Построение процессов управления ИТ
• Внутренний
запрос 3

Описание статусов обработки
30
Статусы, отражающие ожидания выполнения работ/действий по запросу:
Ожидает 1 линии/ Ожидает 2 линии/ Ожидает 3 линии/ Ожидает 4 линии –
ожидает принятия в работу на соответствующей линии поддержки;
Ожидает уточнений – ожидает уточнения информации от пользователя,
после уточнения информации запрос возвращается в предыдущий статус;
Ожидает переклассификации – ожидает принятия на переклассификацию,
для запросов не корректно классифицированных (Услуга, Вид запроса,
Срочность, Расположение, Оборудование);
Ожидает подтверждения
– ожидает от пользователя подтверждения
выполнения работ
Построение процессов управления ИТ

Описание статусов обработки
Статусы, отражающие выполнение работ/действий по запросу:
В работе 1 линии/ В работе 2 линии/ В работе 3 линии/ В работе 4 линии –
выполняются работы на соответствующей линии поддержки;
На переклассификации – выполняются работы по переклассификации
(Услуга, Вид запроса, Срочность, Расположение, Оборудование);
На согласовании – выполняются согласования по запросу;
Возобновлён – пользователем, возобновлены работы по запросу;
Статусы, отражающие завершение всех работ по запросу:
Закрыт – финальный статус запроса, переход из которого в какие-либо
другие статусы невозможен
Построение процессов управления ИТ
31

Описание обработки Предложений об
изменениях
Пользователь/
Инициатор
1-я линия
Менеджер по
развитию
услуги
Менеджер по
развитию
услуги
Создание
ЗНИ(ЗНИ)
33
Менеджер по
развитию
услуги
Менеджер по
развитию
услуги
Менеджер по
развитию
услуги
На согласовании
В реализации
Рассмотрено
Закрыт
ПОИ принято
к реализации
Создание
Предложения
об изменении
1-я линия
Ожидает
рассмотрения
Уточнение информации
Пользователь/
Инициатор
Расширенная модель
Анализ и
консолидация
Рассмотрено
Упрощенная модель
ПОИ не
принято к
реализации
Процесс управления Изменениями
Закрыт
Менеджер по
развитию
услуги

Описание обработки Запросов на
изменения
Менеджер
по
изменению
Регистратор Менеджер
изменения по развитию
(+Инициатор) услуги
ПОИ
ПОИ
ПОИ
Создание
ЗНИ
Проверка и
назначение
34
Планирование
и анализ
Обновление
ЗНИ
Подготовка
экспертного
заключения
Передача плана
Консолидация
Реализация
Согласование
работ
экспертных
Изменения
Изменения
Исполнителю
заключении
Анализ и оценка
внедренного
Изменения
Закрытие
Задачи
Задачи
Участник
Комитета по
изменениям
Эксперты
Регистратор
изменения
(+Инициатор)
Процесс управления Изменениями
Исполнитель
+ Роли:
• Менеджер процесса
• Владелец процесса
ПОИ
ПОИ
ПОИ

Описание обработки облегченных
Запросов на изменения
35
Менеджер
по
изменению
Регистратор
Менеджер
изменения по развитию
(+Инициатор)
услуги
ПОИ
ПОИ
ПОИ
Опционально
Создание
ЗНИ
Проверка и
назначение
Согласование
Изменения
Реализация
Изменения
Планирование
и анализ
Обновление
ЗНИ
Участник
Комитета по
изменениям
Анализ и оценка
внедренного
Изменения
Закрытие
ПОИ
ПОИ
ПОИ
Задачи
Исполнитель
Регистратор
изменения
(+Инициатор)
Процесс управления Изменениями
+ Роли:
• Менеджер процесса
• Владелец процесса

Управление изменениями
CHG – Процесс управления изменениями
Из управления
проблемами
Возникла
потребность
в изменении
Из управления
проектами
CHG-2 Создание ЗНИ
CHG-4 Обновление
Запроса на
изменение
Из оперативного
контроля других
процессов
Из
административн
ой деятельности
Менеджер по развитию Услуги
CHG-5
Планирование и
анализ
Управление
Проблемами
CHG-7 Консолидация
экспертных
заключении
CHG-9 Передача
плана работ
Исполнителю
ЗНИ закрыт
Управление
Конфигурациями
В управление
Каталогом услуг
Функция Service
Desk
Запрос передан на уточнение
В SD-3 Коммуникации
с получателями услуг
Функция Service
Desk
ПОИ передано
на классификацию
В SD-2 Классификация запросов
ПОИ Отклонено
Эксперт
CHG-6 Подготовка
экспертного
заключения
Исполнитель
работ
Управление
конфигурациями
CHG-10 Реализация
Изменения
Участник
комитета по
изменениям
Управление релизами
CHG-8 Согласование
изменения
Менеджер
процесса
Требуется
Эскалация. Из любой
процедуры
Процесса
Роль, на
которую
эскалируют
Корректирующие
действия приняты
Владелец
процесса
CHG-13
Оперативный
контроль Процесса
Требуется
Эскалация
Передано
административному
руководству
Выявлено
нарушение
Процесса. Из любой
процедуры
Процесса
Построение процессов управления ИТ
В управление
проектами
В оперативный
контроль других
процессов
управления
В административную
деятельность
CHG-3 Проверка и
назначение
CHG-1 Обработка
ПОИ
Зарегистрированное
Предложение
об изменении
В управление
проблемами
CHG-12 Закрытие
Создана связь
с существующим ЗНИ
Участник
процесса
В управление
конфигурациями
Управление
Инцидентами
Функция Service
Desk
Naumen
Service Desk
В управление
инцидентами
CHG-11 Анализ и
оценка внедренного
Изменения
Менеджер изменения
Пользователь
Регистратор
изменения
Из управления
инцидентами
36

Интерфейс системы
44
Основной вкладкой для работы в системе специалистов, является вкладка «Запросы». На вкладке
«Запросы» располагаются вложенные вкладки:
Мои активные – перечень всех запросов, назначенных на текущего сотрудника, и запросы, которые
находятся «В очереди». Суть этой закладки – показать все объекты, с которыми сотруднику необходимо
работать, тем самым минимизировав переключение сотрудника на какие-либо другие вкладки. По
результатам завершения работы над запросом (Предоставление решения), он пропадает с закладки
В группе – перечень запросов, в ответственности групп сотрудника;
Прошли обработку – перечень запросов, в которых принимали участие сотрудники линий поддержки
(предоставляли решение, либо эскалировали на другие линии);
На контроле – перечень запросов, в которых сотрудники группы контролируют состояние (к примеру
ожидают ответа от Пользователя);
Все запросы – все запросы, доступные участнику процесса входящих в состав управленческих ролей
процесса (Менеджер услуги, менеджер процесса и т. ), с возможностью настройки и сохранения
видов;
Построение процессов управления ИТ

Обработка запроса
48
Передача запроса на следующую линию
Специалист может передать запрос на следующую линию. Если он выходит за
границы его компетенции. Для
передачи
запроса
на
следующую
линию
обработки
воспользоваться кнопкой «Передать на следующую линию»
Построение процессов управления ИТ
требуется

Обработка запроса
49
Запрос уточнений
Запрос может быть переведен в ожидание, если:
для
продолжения
работ
специалисту
необходима
дополнительная
информация от заявителя;
необходима приостановка по просьбе пользователя. Для перевода в ожидание требуется воспользоваться кнопкой «Запросить
уточнения»
Запрос уточнений разрешен для использования только ограниченное
количество раз, заданное в настройках процесса
Построение процессов управления ИТ

Обработка комплексного запроса
Основные особенности Комплексного запроса
Тип запроса «Комплексный» присваивается автоматически, если в запросе
указано несколько единиц оборудования или несколько расположений;
Для комплексного запроса не учитывается регламентное время обработки;
Для комплексного запроса, после принятия на выполнение специалистом 2ой линии, автоматически будут созданы дочерние запросы. Дочерние
запросы создаются отдельно на каждую единицу оборудования, либо на
расположения
Построение процессов управления ИТ
53

Завершение обработки запроса
56
Завершение запроса
По окончанию обработки запроса необходимо завершить его выполнение и
задокументировать решение. Для завершения работ по запросу требуется воспользоваться кнопкой
«Предоставить решение»
Результат работ (коды решения, коды закрытия):
Решение предоставлено – если решили
Не согласован (ранее называлось Отклонено) – если можем выполнить но не будем (не согласовали руководители, например)
Отменено пользователем – если пропала потребность в выполнении (обошлись, не актуально, сами решили)
Возврат на переклассификацию – если неверно маршрутизирован
Эскалировать – если не поняли что случилось или не можем выполнить
Дублирование – уже существует полностью идентичный запрос
Построение процессов управления ИТ

Управленческая отчетность
Количество запросов, находящихся в обработке в начале периода
№ п/п
Число
Услуга / Компонент услуги / Вид запроса подключенных
специалистов
1
1
2
3
4
5
2
Всего
Из них не
принято в
работу
Количество вновь
поступивших на обработку
Всего
Число
поступило на
запросов на
обработку в
Из них с
Из них были
одного
Из них были
За прошлый За отчетный
отчетном
нарушением
возобновспециалиста
уточнены
период
период
периоде
SLA
лены
57
Количество решенных запросов за отчетный период
Всего
Число
запросов на
одного
специалиста
Среднее
время
реакции
Из них с
Из них были
Из них были
нарушением
возобновуточнены
SLA
лены
Количество запросов, находящихся в обработке на конец периода
Из них с
оценкой
Средняя
оценка
Всего
Из них не
принято в
работу
Из них с
нарушенным
SLA
Из них были
уточнены
Прогнозная
Из них были
длительност
возобновь решения (в
лены
дн. )
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Внутренние услуги
1С – Автоматизированная система
коммерческого учета (АСКУ)
1С – Автоматизированная система
коммерческого учета (АСКУ)
1171
0
0
0
0
0
0
13583 (-)
13583
11,6
12986
(95,6%)
11,1
17:51
888
1571
402
6265
4,8
597 (4,4%)
249
258
174
19
17
357
0
0
0
0
0
0
893 (-)
893
2,5
888 (99,4%)
2,5
50:5
171
121
32
228
4,7
5 (0,6%)
0
2
3
1
2
1С Бухгалтерия (АСБНУ)
800
0
0
0
0
0
0
2682 (-)
2682
3,4
2482 (92,5%)
3,1
24:50
294
382
103
1198
4,8
197 (7,3%)
68
99
55
5
30
151
0
0
0
0
0
0
160 (-)
160
1,1
129 (80,6%)
0,9
110:4
77
27
1
40
4,7
31 (19,4%)
22
29
1
0
90
734
0
0
0
0
0
0
4467 (-)
4467
6,1
4302 (96,3%)
5,9
45:15
637
395
79
1738
4,9
165 (3,7%)
95
87
27
2
14
1С Единая Информационная Система
консолидированной отчетности
1С Зарплата и управление персоналом
(ЗУП)
6
1С:Поддержка методологического центра
5
0
0
0
0
0
0
3 (-)
3
0,6
1 (33,3%)
0,2
72:16
0
0
1
1
5,0
1 (33,3%)
1
1
0
0
375
7
1С:Сервис репликации ИБ
11
0
0
0
0
0
0
4 (-)
4
0,4
2 (50,0%)
0,2
9:28
0
0
0
1
5,0
2 (50,0%)
2
2
0
0
375
8
1С Управление автотранспортом
123
0
0
0
0
0
0
159 (-)
159
1,3
153 (96,2%)
1,2
74:7
33
4
1
46
4,9
2 (1,3%)
1
2
1
0
5
9
” 2 – Предоставить полномочия в 1С
2
0
0
0
0
0
0
3 (-)
3
1,5
2 (66,7%)
1,0
3983:34
2
0
0
0
0
1 (33,3%)
0
1
0
0
188
10
Active Directory – Exchange
777
0
0
0
0
0
0
5084 (-)
5084
6,5
4924 (96,9%)
6,3
15:50
245
505
167
2964
4,9
160 (3,1%)
80
26
21
3
12
11
Becsys – удаленный доступ к компьютеру
56
0
0
0
0
0
0
70 (-)
70
1,3
56 (80,0%)
1,0
1:5
0
6
1
43
5,0
14 (20,0%)
13
11
0
1
94
12
Call-центр
10
0
0
0
0
0
0
11 (-)
11
1,1
11 (100,0%)
1,1
37:13
3
0
0
1
5,0
0 (0%)
0
0
0
0
0
13
LAN/SAN
12
0
0
0
0
0
0
2 (-)
2
0,2
2 (100,0%)
0,2
0:49
1
0
0
0
0
0 (0%)
0
0
0
0
0
14
OneClick
5
0
0
0
0
0
0
30 (-)
30
6,0
5 (16,7%)
1,0
487:24
3
0
0
0
0
25 (83,3%)
25
25
0
0
1875
15
Oracle BI (отчёты)
0
0
0
0
0
0
0
22 (-)
22
0
7 (31,8%)
0
0:00
6
0
0
0
0
15 (68,2%)
15
15
0
0
804
16
R52 Сервис Печати и сканирования
2
0
0
0
0
0
0
3 (-)
3
1,5
3 (100,0%)
1,5
0:58
1
0
0
1
3,0
0 (0%)
0
0
0
0
0
160
0
0
0
0
0
0
166 (-)
166
1,0
161 (97,0%)
1,0
16:27
15
14
5
100
5,0
5 (3,0%)
3
2
0
0
12
17
0
0
0
0
0
0
20 (-)
20
1,2
20 (100,0%)
1,2
6:53
1
0
1
12
4,8
0 (0%)
0
0
0
0
0
38
0
0
0
0
0
0
194 (-)
194
5,1
183 (94,3%)
4,8
16:54
16
6
21
65
4,8
11 (5,7%)
0
2
2
2
23
17
18
19
SCCM System Center Configuration
Manager
Seldon – система мониторинга торговых
площадок
VPN Доступ к внутренней сети
Предприятия из Интернет (Check Point)
20
WEB-Монитор Банк Открытие
21
Web-портал Работа в почте
22
23
Web-портал Страхование
(insurance. russianpost. ru,
strahovanie. russianpost. ru)
Web-сервис “Заполнение данных формы
103”
0
0
0
0
0
0
0
4 (-)
4
0
0 (0%)
0
0:00
0
0
0
0
0
4 (100,0%)
4
4
0
0
–
108
0
0
0
0
0
0
167 (-)
167
1,5
155 (92,8%)
1,4
113:43
74
7
1
49
4,9
10 (6,0%)
6
10
2
0
24
65
0
0
0
0
0
0
56 (-)
56
0,9
54 (96,4%)
0,8
14:24
15
0
2
11
4,9
2 (3,6%)
1
2
0
0
14
40
0
0
0
0
0
0
21 (-)
21
0,5
20 (95,2%)
0,5
569:8
13
0
1
6
4,3
1 (4,8%)
1
0
0
0
19
24
WesternUnion
626
0
0
0
0
0
0
3719 (-)
3719
5,9
3455 (92,9%)
5,5
145:5
777
179
45
687
4,8
264 (7,1%)
167
125
24
1
29
25
WinPost
776
0
0
0
0
0
0
5777 (-)
5777
7,4
5431 (94,0%)
7,0
36:57
636
248
50
1932
4,9
341 (5,9%)
156
122
29
5
24
84
0
0
0
0
0
0
44 (-)
44
0,5
41 (93,2%)
0,5
41:59
8
4
0
5
4,8
2 (4,5%)
2
2
0
0
18
93
0
0
0
0
0
0
62 (-)
62
0,7
57 (91,9%)
0,6
82:40
12
8
1
29
4,8
5 (8,1%)
0
0
4
0
33
0,2
1 (100,0%)
0,2
0:32
0
0
0
0
0
0 (0%)
0
0
0
0
0
18,7
66:37
6042
1293
384
10667
4,8
1525 (4,6%)
667
979
137
18
18
0,6
49:54
10
5
3
18
4,8
1 (3,0%)
0
1
1
0
12
26
27
28
29
30
Автоматизированная почтовая станцияпочтамт (АПС)
Автоматизированная система
мониторинга транспортных средств
(АСМТС)
Автоматизированная система управления
и расчетов за услуги пунктов
коллективного доступа (АСУРПКД)
Автоматизированное рабочее место
(АРМ)
Автоматическая телефонная станция
(АТС)
Построение процессов управления ИТ
6
0
0
0
0
0
0
1 (-)
1
1671
0
0
0
0
0
0
32818 (-)
32818
19,6
31277
(95,3%)
52
0
0
0
0
0
0
33 (-)
33
0,6
31 (93,9%)

Управленческая отчетность
Головное
подразделение
УФПС Новосибирской
области
УФПС Новосибирской
области
УФПС Московской
области
Номер
запроса
101695
101699
101781
Дата регистрации
01. 2016 06:42:33
01. 2016 07:15:59
01. 2016 11:58:52
Статус
Пользователь
Подразделение
пользователя
Расположение
пользователя
Головная услуга
Сервисный
компонент
Закрыт
Кукушко
Наталья
Геннадьевна
Нераспределе. ЕАС. ОАСУ
ЕАС. Проблемы с
РПО/Data Cloud транспортом. Отправка данных
Закрыт
Кононенко
Марина
Игоревна
Группа
производственно
го контроля
ЕАС. Посылки,
ЕАС. Посылочный
EMS и мелкие
бизнес и экспресс
пакеты – Вручение
доставка
РПО
Отдел
Слабких Павел
информационны
Андреевич
х технологий
143921 ЧЕРНОЕ
ЕАС. Поступление
ЕАС. Проблемы с
накладных из/в
транспортом. ОПС
125445 УФПС г. Москвы-филиал
ФГУП Почта
России ММП 4
ОПС 445
Закрыт
УФПС г. Москвы
101857
01. 2016 14:52:12
Закрыт
Мизяев Кирилл
Александров. Коммерческий
отдел
SoCall
102065
01. 2016 21:58:03
Закрыт
Эрелт Павел
Андреевич
SoCall
Вид запроса
Консультация
60
Краткое описание
Описание
Загрузка данных в АСКУ
В ОПС 632160 Усть-Тарка 28 июня
проводили прием партионных
почтовых отправлений от
корпоративных клиентов. Должна
ли информация о приеме
автоматически загружаться в
систему АСКУ или информацию о
приеме как и раньше надо заносить
в систему АСКУ вручную?
В ОПС 632901 у РПО
№17096798032828 в Журнале РПО
невозможно выдать РПО с не встает вид операции из-за этого
наложенным платежом
невозможно выдать РПО,
накладную завершили. Скрин во
вложении
Критичная
ошибка
не работает транспорт в
опс 143907. АСУИП Naumen
Service Desk
(Наумен)
Консультация На support. russianpost. ru не
по
вижу всех сделаных мной
использован. Обращений
АСУИП Naumen
Service Desk
(Наумен)
Консультация
по
использован. Тестовая консультация
Добрый лень. В ОПС 143907 с
06. 2016 не отрабатывается
транспорт. Силами ОИТ
неоднократно транспорт
перезапускался. TV 1090438272
pass 111111
На support. russianpost. ru не вижу
всех сделаных мной Обращений
Закройте пожалуйста
Выгрузка специальной таблицы для анализа (В том числе Excel)
Построение процессов управления ИТ

Промышленное программирование, или Пара слов об АСУ ТП

Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т. и т.

Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.

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

Поскольку область обширная, несмотря ни на что развивающаяся, местами противоречивая и спорная, буду стараться обобщать не в ущерб достоверности, но не могу избежать перекоса в свою область — то оборудование, софт и сферу, с которыми лично я сталкивался.

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

Верхний уровень

Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество SCADA-систем (от англ. supervisory control and data acquisition — диспетчерское управление и сбор данных). Это в некотором роде расширенный аналог IDE, в котором скомпилированная «программа» и выполняется.

Системы SCADA

Вообще, если отбросить академизм, то на предприятии для всех кроме асушников скада выглядит вот так:

А если совсем не повезёт, то вот так:

Скады неявно можно разделить на серверную и клиентскую части. Опрос полевых устройств и сбор данных производится сервером (обычно, через ПЛК), с сервера клиенты забирают эти данные к себе на монитор. Сами по себе понятия «серверная» и «клиентская» части условны. Фактически разделение производится по лицензиям на компоненты скады, а политика лицензирования у каждого производителя своя. Вплоть до разделения на: количество обрабатываемых сигналов с поля, драйвера протоколов, количество рабочих станций, возможность создания веб-интерфейса, мобильного интерфейса, да и вообще целые куски функционала могут быть за отдельные денжеки. Чаще проще обратиться к поставщику, предоставив исходные данные по проекту, чтобы помогли с подбором лицензий.

Подразумеваются два режима функционирования: режим разработки и режим выполнения (runtime). Не обязательно эти режимы взаимоисключающи: можно редактировать проект на одном АРМе, инженерном, заливать его, он обновится на пользовательских. Это очень важно — изменять проект без простоев и отключений, потому что технологический процесс прерывать нельзя, и операторы всегда должны иметь возможность его контролировать. В скаде создаются графические интерфейсы, настраиваются источники данных с полевых устройств, она отвечает за взаимодействие пользователя (оператора, диспетчера, технолога) с происходящим на производстве, а также за архивирование всех нужных данных в БД.

Архивирование — одна из обязательных функций, очень важно иметь возможность «вернуться назад во времени» для разбора полётов в случае чего-то непредвиденного либо для глобального анализа при медленных, длительных процессах. Например, недавно геологи попросили меня выгрузить табличкой данные по давлению нефти на скважинах за последний год.

Периодически скада складывает все собранные данные в БД. Их потом можно посмотреть в виде графиков (называем их трендами), а при необходимости, если оговорено в ТЗ на АСУТП, реализуется выгрузка в виде отчётов в эксель или ещё как-нибудь. Архивация сделана по-разному: в MS SQL; MS Access; в ту же MS SQL, но по своему хитрому алгоритму с дополнительной архивацией; а у кого-то вообще в свою собственную бинарную БД.

Особым пунктом в скадах идёт информирование оператора: текущие сообщения и аварийные. Они тоже обязательно архивируются. В общем виде сообщения делятся на текущие и важные (аварийные). Текущие прячут подальше, но журнал аварийных всегда выводится на экране оператора. К текстовым аварийным сообщениям привязываются звуковые, чтобы кто-нибудь не проспал ЧП

Рынок SCADA

Самыми распространёнными, по-моему, считаются скады производства Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.

Я лично работал с виндовыми: Invensys Wonderware InTouch и более мощной System Platform, с Iconics Genesis32 — и с (пока ещё?) малоизвестной B&R APROL под SLES (формально, это не совсем скада, а покруче — из-под апрола программируются и сами контроллеры).

По поисковым запросам, например, SCADA, HMI можно посмотреть примеры интерфейсов и мнемосхем.

Внешний вид и юзабилити по приоритету, увы, находятся на последнем месте. Причём, это касается не только рантайма, но и разработки. Для разработки в каждой скаде существуют как минимум дефолтные библиотеки символов — от кнопок и прочих контролов до графических изображений насосов, труб, задвижек, ёмкостей. Здесь-то и могли бы умные разработчики SCADA-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder,

, stronger, и о пользователях пока думают мало.

Средний уровень

Средний уровень — ПЛК, программируемые логические контроллеры. Здесь всё достаточно просто, чаще всего физически ПЛК состоят из отдельных модулей. Для программирования у каждого ПЛК есть своя среда разработки, иногда она объединена со средой для создания SCADA.

Состав ПЛК

Модули бывают такие:

блок питания;
процессорный;
дискретных входов;
дискретных выходов;
аналоговых входов;
аналоговых выходов;
температурных входов;
интерфейсные/коммуникационные.

Контроллер B&R серии X20

Зачем нужен блок питания — понятно. БП сделан отдельным именно модулем, а не устройством, чтобы гарантировать совместимость с данной линейкой ПЛК. Чаще всего входное напряжение у БП 220 В переменного тока, выходное — 24 В постоянного тока.

Процессорный модуль — это голова ПЛК. Внутри у него, само собой, ЦПУ, ОЗУ и ПЗУ, сервисный порт для прошивки и, возможно, коммуникационный порт (ethernet, RS232/422/485, Profibus, etc). Иногда коммуникационный порт используется и как сервисный. Иногда на модуле есть переключатель (у Allen Bradley ещё круче — там натуральный ключ с замочной скважиной) для перевода ПЛК в различные режимы работы. Отдельной кнопки включения/выключения нет, в лучшем случае — тот переключатель, иначе, если есть питание — ПЛК запускается, а выключается и перезагружается «по-варварски» отключением питания.

Контроллер Allen Bradley серии CompactLogix

Дискретные и аналоговые модули обрабатывают соответствующие сигналы. Входные модули принимают эти сигналы с поля, выходные — формируют их.

Дискретный сигнал — это обычно напряжение цепи 24 вольта. Есть 24 — это «1», нет — «0». Бывают модули на 220В, есть модули с проверкой целостности цепи. Дискретные сигналы, приходящие с поля, могут информировать, например, о состоянии насоса включен/выключен. Управляющие дискретные сигналы могут запускать либо останавливать этот насос. Оптимизация здесь не оправдана, поэтому на запуск будет отдельная цепь, на останов — отдельная.

Модули I/O одного типа могут быть объединены: например, один модуль с 16 дискретными входами и 16 дискретными выходами.

Аналоговые входные сигналы — это приходят показания с датчиков. Здесь чаще всего используется токовая петля 4-20 мА, в соотетствие которой ставятся пределы измерения датчика. Начинается от 4 мА для диагностирования обрыва цепи (если меньше 4 мА, значит где-то что-то не в порядке с проводкой).

Рассмотрим на примере уровня жидкости в резервуаре. Стоит уровнемер, он измеряет уровень от 0 до 2 метров. Тогда: уровень 0 метров — это 4 мА, уровень 2 метра — это 20 мА. Промежуточные значения калибруются по ситуации, не всегда 1 метр соответствует 4+(20-4)/2=12 мА, может быть небольшая погрешность, уровень в 1 метр может быть какие-нибудь 12,7553 мА.

Аналоговые выходные — то же, только на управление. Не встречал чтобы использовалось, т. всегда существуют наводки. В измерении это допустимая погрешность, в управлении — нет. Да и неудобно это. Вместо них используется цифровая передача данных по различным протоколам через коммуникационные модули.

Температурные модули замеряют сопротивление в цепи либо термо-ЭДС. Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение.

Интерфейсные (или коммуникационные) модули предоставляют нам порты под RJ45, DB9, DB15, просто клеммники или что ещё бог производителю на душу положит. Помимо реализации непосредственно интерфейса (физического разъёма под коннектор, физического уровня модели OSI) они также реализуют протокол обмена через этот разъём.

Протоколы и интерфейсы

Протоколов напридумывали и используют кучу: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485 и т. Некоторые особо хитрые производители реализуют свои протоколы поверх общепринятых.

Я достаточно тесно знаком с интерфейсами RS232/485 и протоколами Modbus. RS232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). RS485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.

А модбас это в общем-то нехитрая штука, с проверкой целостности пакета по чексумме, подтверждением доставки и корректности запроса — или ответом, почему запрос неверен. В сети модбас есть два вида устройств: master — инициирует обмен; slave — выполняет запросы мастера. Пакет от мастера расходится ко всем слейвам, которые сравнивают адрес назначения со своим, если сходится, то смотрят следующие два байта — это команда работы с регистрами памяти — чтение/запись (за исключением нескольких редко используемых служебных команд), потом байты адреса и непосредственно данных, в конце чексумма. Достаточно подробно и понятно расписано на википедии.

Программная начинка

Первое, что нужно сказать, программа в ПЛК выполняется циклически с определённой частотой. Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.

Второе, это языки программирования. По идее программируются ПЛК на языках, определённых стандартом МЭК61131:

IL (Instruction List) — низкоуровневый ассемблероподобный язык.
LD (Ladder Diagram) — графический язык, представляет собой программную реализацию электрических схем на базе электромагнитных реле. Придумано в лохматые года для тех асушников, которые больше электрики, чем программисты.
IL и LD легко конвертируются друг в друга, кажется, всеми средами программирования. Они не очень читабельны, и потому неудобны для разработки, но в ситуациях, когда внутренней памяти контролера немного, приходится писать на них.
ST (Structured Text) — текстовый паскалеподобный язык. По-моему, из всех пяти самый удобный.
SFC (Sequential Function Chart) — графический высокоуровневый язык. Создан на базе математического аппарата сетей Петри. Описывает последовательность состояний и условий переходов. Ни разу не встречал и не слышал, чтобы где-то использовался.

Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.

Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.

Заключение

Russianpost. ru is tracked by us since April, 2011. Over the time it has been ranked as high as 2 029 in the world, while most of its traffic comes from Russian Federation, where it reached as high as 73 position. Tms. russianpost. ru receives less than 5% of its total traffic. It was owned by several entities, from FGUP “Russian Post” to JSC Russian Post, it was hosted by Internet Assigned Numbers Authority. While RUCENTER-REG-RIPN was its first registrar, now it is moved to RU-CENTER-RU.

Tms. russianpost has the lowest Google pagerank and bad results in terms of Yandex topical citation index. We found that Tms. russianpost. ru is poorly ‘socialized’ in respect to any social network. According to MyWot, Siteadvisor and Google safe browsing analytics, Tms. russianpost. ru is a fully trustworthy domain with no visitor reviews.

Russianpost. ru is tracked by us since April, 2011. Over the time it has been ranked as high as 2 029 in the world, while most of its traffic comes from Russian Federation, where it reached as high as 73 position. 5ballov. russianpost. ru receives less than 5% of its total traffic. It was owned by several entities, from FGUP “Russian Post” to JSC Russian Post While RUCENTER-REG-RIPN was its first registrar, now it is moved to RU-CENTER-RU.

5ballov. russianpost has the lowest Google pagerank and bad results in terms of Yandex topical citation index. We found that 5ballov. russianpost. ru is poorly ‘socialized’ in respect to any social network. According to MyWot and Google safe browsing analytics, 5ballov. russianpost. ru is a fully trustworthy domain with no visitor reviews.