Преимущества открытой архитектуры в АСУ ТП
Мы как интеграторы сталкиваемся с тем, что проприетарные решения АСУ ТП затрудняют интеграцию с решениями более высокого уровня, модулями аналитики и др. Также они затрудняют модернизацию, техническое перевооружение существующей инфраструктуры АСУ ТП. Поэтому мы поддерживаем проекты с открытой архитектурой, активно участвуем в сообществе Рабочей группы по открытой АСУ ТП, которое разрабатывает технические требования.
Подход, который продвигает РГ по открытой АСУ ТП, предполагает “всеядность” решений. Мы должны обеспечить доступ аппаратной части к любому программному обеспечению. Это реализуется с помощью платформы, которая состоит из набора элементов, позволяющих осуществлять сквозной трансфер данных между нижним и верхним уровнем.
Ранее автоматизация процессов реализовывалась через высоконагруженные аппаратные устройства. Логика процессов, обработка переменных реализовывалась в аппаратных устройствах. Сейчас рост серверных мощностей, облачных серверов, развитие каналов связи позволяют реализовать часть этой логики на внешних серверах, что гораздо более эффективно экономически. На это и нацелена открытая архитектура АСУ ТП. Это позволяет снизить затраты на обслуживание и эксплуатацию высоконагруженных аппаратных средств, требующих к себе повышенного внимания и сервиса.
Мы как интеграторы сталкиваемся с тем, что проприетарные решения АСУ ТП затрудняют интеграцию с решениями более высокого уровня, модулями аналитики и др. Также они затрудняют модернизацию, техническое перевооружение существующей инфраструктуры АСУ ТП. Поэтому мы поддерживаем проекты с открытой архитектурой, активно участвуем в сообществе Рабочей группы по открытой АСУ ТП, которое разрабатывает технические требования.
Подход, который продвигает РГ по открытой АСУ ТП, предполагает “всеядность” решений. Мы должны обеспечить доступ аппаратной части к любому программному обеспечению. Это реализуется с помощью платформы, которая состоит из набора элементов, позволяющих осуществлять сквозной трансфер данных между нижним и верхним уровнем.
Ранее автоматизация процессов реализовывалась через высоконагруженные аппаратные устройства. Логика процессов, обработка переменных реализовывалась в аппаратных устройствах. Сейчас рост серверных мощностей, облачных серверов, развитие каналов связи позволяют реализовать часть этой логики на внешних серверах, что гораздо более эффективно экономически. На это и нацелена открытая архитектура АСУ ТП. Это позволяет снизить затраты на обслуживание и эксплуатацию высоконагруженных аппаратных средств, требующих к себе повышенного внимания и сервиса.
Открытая шина данных
Шина данных (в терминологии стандартов OPAS - OCF) - один из ключевых элементов открытой архитектуры. Именно шина обеспечивает “всеядность” к различному ПО и различным протоколам.
Одна из задач, которая должна быть решена, - быстродействие. Необходимо обеспечить “проброс” данных для реализации логики на верхнем уровне и возврат решения на нижний уровень. Скорость передачи данных должна обеспечить выполнение требований реального времени.
Вторая задача - создание инструментов, чтобы пользователь самостоятельно реализовать дата-провайдер для подключения того или иного аппаратного устройства. Здесь есть трудности, связанные с интеграцией различных аппаратных устройств, привязанных к разным средам разработки. На помощь приходят стандартизированные протоколы, которыми обеспечивается такая интеграция.
Также необходимо решить задачу разметки данных. Шина должна позволять разметить данные, организовать очередь этих данных.
Шина OCF обеспечивает связь полевых устройств, датчиков, оборудования с верхнем уровнем приложений. Шина состоит из DCN-шлюзов, обеспечивающих подключение к шине, разметку данных, трансфер данных. На уровне самой шины используется стек OPC UA. DCN-шлюзы обеспечивают конвертацию протоколов в стек OPC UA и разметку данных для технологии TSN over OPC UA.
DCN -шлюз может быть реализовано программно в самой шине. Шина имеет внутри себя устройство для создания шлюзов. Этой частью сейчас занимается Техническая рабочая группа но конверторам.
Шина данных (в терминологии стандартов OPAS - OCF) - один из ключевых элементов открытой архитектуры. Именно шина обеспечивает “всеядность” к различному ПО и различным протоколам.
Одна из задач, которая должна быть решена, - быстродействие. Необходимо обеспечить “проброс” данных для реализации логики на верхнем уровне и возврат решения на нижний уровень. Скорость передачи данных должна обеспечить выполнение требований реального времени.
Вторая задача - создание инструментов, чтобы пользователь самостоятельно реализовать дата-провайдер для подключения того или иного аппаратного устройства. Здесь есть трудности, связанные с интеграцией различных аппаратных устройств, привязанных к разным средам разработки. На помощь приходят стандартизированные протоколы, которыми обеспечивается такая интеграция.
Также необходимо решить задачу разметки данных. Шина должна позволять разметить данные, организовать очередь этих данных.
Шина OCF обеспечивает связь полевых устройств, датчиков, оборудования с верхнем уровнем приложений. Шина состоит из DCN-шлюзов, обеспечивающих подключение к шине, разметку данных, трансфер данных. На уровне самой шины используется стек OPC UA. DCN-шлюзы обеспечивают конвертацию протоколов в стек OPC UA и разметку данных для технологии TSN over OPC UA.
DCN -шлюз может быть реализовано программно в самой шине. Шина имеет внутри себя устройство для создания шлюзов. Этой частью сейчас занимается Техническая рабочая группа но конверторам.
Стандарты и протоколы
В нашей Технической рабочей группе мы сейчас тестируем различные гипотезы. Одной из таких гипотез является то, что наиболее полный стек для такой интеграционной шины предлагают стандарты OPC UA. Мы планируем проверить эту гипотезу путем создания прототипов, тестовых стендов. Пока мы планируем двигаться в этом направлении.
Использование международного стандарта OPC UA позволит нам в дальнейшем использовать наши продукты для внешнего рынка. Ведь, интеграционная шина может предоставляться нашим сообществом как отдельный продукт, отдельное решение для сбора данных для MES, ERP, систем аналитики.
На полевом уровне, как мы считаем, должен быть реализован отечественный полевой протокол, стандартизированный на стеке российских решений. Такая потребность существует на предприятиях критической инфраструктуры. Это не противоречит тому, что мы делаем, а дополняет функционал нашей шины.
Сейчас мы работаем над описанием информационной модели шины как элемента открытой АСУ ТП. И мы видим активное участие в формировании техтребований представителей таких компаний, как “Еврохим”, “Газпром нефть”, “Лукойл”, “Росатом” и других. Есть возможность доступа к серверным мощностям для того, чтобы собирать прототипы, стенды, на которых мы можем отрабатывать наши гипотезы.
Сложность нашей задачи в том, что мы должны удовлетворять требованиям различных типов производств - и непрерывных, и дискретных. Мы вынуждены отрабатывать гипотезы применимости технологий для различных задач. Для этого нам нужны тестовые стенды.
Первая проблема - это создать требования, которые удовлетворяли бы запросам различных предприятий - и тех, кто использует SCADA+ПЛК, и тех, кто использует РСУ.
Вторая проблема, когда техтребования будут уже созданы, будет найти консенсус между заказчиками и разработчиками-вендорами.
В нашей Технической рабочей группе мы сейчас тестируем различные гипотезы. Одной из таких гипотез является то, что наиболее полный стек для такой интеграционной шины предлагают стандарты OPC UA. Мы планируем проверить эту гипотезу путем создания прототипов, тестовых стендов. Пока мы планируем двигаться в этом направлении.
Использование международного стандарта OPC UA позволит нам в дальнейшем использовать наши продукты для внешнего рынка. Ведь, интеграционная шина может предоставляться нашим сообществом как отдельный продукт, отдельное решение для сбора данных для MES, ERP, систем аналитики.
На полевом уровне, как мы считаем, должен быть реализован отечественный полевой протокол, стандартизированный на стеке российских решений. Такая потребность существует на предприятиях критической инфраструктуры. Это не противоречит тому, что мы делаем, а дополняет функционал нашей шины.
Сейчас мы работаем над описанием информационной модели шины как элемента открытой АСУ ТП. И мы видим активное участие в формировании техтребований представителей таких компаний, как “Еврохим”, “Газпром нефть”, “Лукойл”, “Росатом” и других. Есть возможность доступа к серверным мощностям для того, чтобы собирать прототипы, стенды, на которых мы можем отрабатывать наши гипотезы.
Сложность нашей задачи в том, что мы должны удовлетворять требованиям различных типов производств - и непрерывных, и дискретных. Мы вынуждены отрабатывать гипотезы применимости технологий для различных задач. Для этого нам нужны тестовые стенды.
Первая проблема - это создать требования, которые удовлетворяли бы запросам различных предприятий - и тех, кто использует SCADA+ПЛК, и тех, кто использует РСУ.
Вторая проблема, когда техтребования будут уже созданы, будет найти консенсус между заказчиками и разработчиками-вендорами.
Роль комплексного интегратора на рынке АСУ ТП
С уходом западных вендоров и интеграторов для нас открывается большой рынок. “Ростелеком” видит себя и в роли создателя продуктов, например - доверенных ПАКов. Второе направление - услуги по интеграции. Мы видим себя в роли комплексного интегратора, не привязанного к какой либо отрасли или типу производства.
Мы стремимся реализовать сервисную модель для поддержки наших клиентов. Такую модель может себе позволить только интегратор, обладающий технологическим стеком на базе открытых платформ. Это позволит сделать уже имеющееся ПО комплементарным для большого количества отраслей. Тогда мы сможем взять на себя функции сервисной и технической поддержки продуктов. Мы будем выступать в качестве гаранта работоспособности систем автоматизации.
Комплексный интегратор возьмет на себя функцию финансового гарантирования работоспособности внедряемых продуктов, их интегрируемости с другими продуктами. Мы будем финансово гарантировать достижение просчитываемого эффекта от автоматизации.
С уходом западных вендоров и интеграторов для нас открывается большой рынок. “Ростелеком” видит себя и в роли создателя продуктов, например - доверенных ПАКов. Второе направление - услуги по интеграции. Мы видим себя в роли комплексного интегратора, не привязанного к какой либо отрасли или типу производства.
Мы стремимся реализовать сервисную модель для поддержки наших клиентов. Такую модель может себе позволить только интегратор, обладающий технологическим стеком на базе открытых платформ. Это позволит сделать уже имеющееся ПО комплементарным для большого количества отраслей. Тогда мы сможем взять на себя функции сервисной и технической поддержки продуктов. Мы будем выступать в качестве гаранта работоспособности систем автоматизации.
Комплексный интегратор возьмет на себя функцию финансового гарантирования работоспособности внедряемых продуктов, их интегрируемости с другими продуктами. Мы будем финансово гарантировать достижение просчитываемого эффекта от автоматизации.