Метро 2014. Автоматизация метрополитена на платформе S5

Если посмотреть на историю развития нашей компании, то можно увидеть, что с начала 1990-х годов компания «ТоксСофт» начала разработку АСУТП электролиза «ТРОЛЛЬ», которая была внедрена на более чем 3000-х электролизерах. Два десятилетия разработки пяти версии системы «ТРОЛЛЬ» и её младшей версии «СТЭЛА» позволили накопить большой опыт в создании специфичных систем автоматизации и диспетчеризации. В результате родилась платформа S5 — программно-аппаратный комплекс для разработки систем автоматизации и диспетчеризации.

Для этого есть несколько объективных причин:

• эксплуатационным службам заказчика требуется понимать, что они будут эксплуатировать;
• требуется объяснение, почему решения на основе платформы S5 стоят настолько дешевле конкурирующих систем;
• устройство платформы дает понять, для каких задач наиболее применимы решения на основе платформы S5.

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

Для удобства понимания разделим статью на разделы:

1. Постановка задачи автоматизации метрополитена
2. Структура и составные части системы управления службами метрополитена
3. Платформа S5

Итак, представляем проект «Модернизация системы диспетчеризация движения поездов и системы единого времени Тбилисского метрополитена», выполненный на платформе S5.

Постановка задачи автоматизации

Тбилисский метрополитен состоит из двух линий и 22-х станций (16 на первой и 6 на сабурталинской линии). Первая очередь была запущена в 1966 году. Все станции кроме одной введены в строй до 1989 года. Последняя станция была сдана в 2000 году по старому проекту. Тбилисский метрополитен построен по советскому проекту, аналогично большинству метрополитенов на территории бывшего СССР. Задача проекта состояла в решении двух задач: модернизации системы диспетчеризации движения поездов и подсистемы единого времени.

I. Диспетчеризация движения поездов

Движение поездов в советских метрополитенах управдляется с помощью релейной системы МРЦ (маршрутно-релейная сигнализация). МРЦ установлено на 7-ми из 22-х станции Тбилисского метро, и управляют поездами на всех станциях и перегонах. В паре с МРЦ работает шкаф системы диспетчеризации (ДЦ — диспетчерская централизация), забирает информацию с МРЦ и выдает на верхний уровень диспетчера движения поездов. В Тбилиси два диспетчера, по одному на каждую линию метро. Кроме того, от диспетчера управляющие команды передаются на МРЦ.

Изначально ДЦ тоже были релейными схемами, а у диспетчера стоял щит управления с лампочками и переключателями. В 1994 года была модернизация, и установлена Харьковская система диспетчерской сигнализации. У диспетчеров вместо щита появились персональные компьютеры, каждый с двумя мониторами, специализированным графическим интерфейсом.

Спустя 20 лет система морально и физически устарела, больше не выпускаются запасные части. В связи с закрытостью системы, сильно затруднено сопровождение системы.

II. Подсистема единого времени

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

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

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

• добавить таймер, показывающий, сколько времени осталось до прихода поезда;
• иметь большой экран диспетчера, отображающее все метро;
• иметь возможность полноценного доступа через интернет.

Предлагаемые решения должна удовлетворять следующим особым требованиям:

• любая компонента оборудования должна производится не менее 3-мя разными производителями;
• не требовать лицензионных отчислении при внедрении и за весь срок эксплуатации;
• весь исходный код должен быть передан заказчику;
• система должна штатно предусматривать добавление новых подсистем;
• отсутствие связи с верхним уровнем до 3-х суток не должно приводить к потере какой-либо информации на нижнем уровне.

Структура и составные части системы управления

1. Оборудование (аппаратное обеспечение) системы автоматизации

На рисунке приведена структурная схема комплекса технических средств Системы.

Система состоит из следующих аппаратных компонент:

• станционный шкаф контроллера (ШК) — в ШК расположен контроллер ODROID, модули ввода-вывода, ИБП, и др;
• шкаф контроллера часов (ШЧ) — используется вне станций, аналогичен ШК, только не содержит модели ввода-вывода;
• комнатные часы устанавливаются в помещениях и офисах метрополитена для показа точного времени;
• платформенные часы и таймеры устанавливаются на платформах станции взамен (и в дополнение) используемых сейчас;
• сервер Системы, на которых работает ПО диспетчерского уровня. Используется оборудование существующих серверных стоек метрополитена;
• компьютерная Ethernet сеть для связи всех интеллектуальных компонентов системы между собой. Используется существующая высоконадежная оптоволоконная сеть метрополитена;
• компьютеры АРМов для установки ПО на всех уровнях управления и контроля.

2. Структура программного обеспечения.

На рисунке цветом обозначены:

– стандартные программные компоненты, используются свободное программное обеспечение сторонних производителей;
– стандартные для платформы S5 программные компоненты;
– проектно-специфичные программные компоненты.

Программное обеспечение всех частей Системы полностью написано на платформе S5, и естественно, использует один язык программирования – Java и одно средство разработки – Eclipse.

Программные компоненты:

• Серверное ПО диспетчерского уровня является центральной частью системы. С одной стороны, оно получает информацию от ШК и контроллеров часов, а с другой стороны предоставляет информацию АРМам, получает команды от операторов и передает на станционный уровень. Осуществляет все функции контроля, управления, накопления, предоставления информации.
• Нижний уровень (станционное ШК) непосредственно получает и выдает сигналы с существующей МРЦ, передает на сервер, обрабатывает команды в реальном времени, формирует сигналы для модулей вывода и т.п.
• Верхний уровень (АРМ) является компонентом, связывающим Систему с человеком. В реальном времени показывает всю информацию по подсистемам, дает возможность оператору формировать команды управления, вместе с серверным программным обеспечением осуществляет все функции информационно-управляющей (ИУС) системы: планирование, анализ, отчеты, работы с документами и т.п.

S5: Платформа для разработки систем управления

Платформа S5 – это средство для разработки систем автоматизации. Что именно представляет из себя эта платформа? Платформа S5 — это:

1. Программное обеспечение платформы S5
2. Методика проектирования систем автоматизации
3. Требования к аппаратному обеспечению
4. Требования к специалистам, сопровождающим систему

I. Программное обеспечение платформы S5

Еще раз отметим, что все ПО пишется на одном языке — Java, используется одна среда разработки — Eclipse. А ПО S5 в первую очередь является набором библиотек на языке Java и предназначен для программиста. Библиотеки реализуют функционал всех частей системы так, чтобы программисту надо было писать код, специфичный для конкретной системы.

ПО современных систем автоматизации и диспетчеризации состоит из трех основных частей: нижний уровень (НУ), сервер и рабочие места (АРМ).

Далее мы рассмотрим как реализуется ПО в известных системах и на платформе S5 с некоторым упрощением изложения во имя упрощения :).

Нижний уровень

Нижний уровень решает следующие задачи:

• взаимодействовать с внешним миром (с технологическими объектами управления – ТОУ): считывать значения датчиков, выдавать сигналы на исполнительные устройства;
• управлять ТОУ в соответствии с заложенными алгоритмами;
• передавать данные в другие части системы в реальном времени, получать информацию и команды по сети.

Таблица 1. Отличия реализации нижнего уровня ПО на базе стандартных систем и на платформе S5

Реализация НУ с помощью стандартных систем

Реализация НУ с помощью платформы S5

ПО НУ выполняется на программируемых логических контролерах (ПЛК). Распространены ПЛК фирм Siemens, Allen-Bradley, Schneider Electric и т.п. ПЛК программируются на соответствующих стандарту IEC 61311 языках.  Каждый производитель поставляет собственную среду разработки. ПЛК содержит как процессор, так и концентрируемый набор модулей ввода/вывода. Сетевое общение с другими частями системы реализуется встроенными и закрытыми средствами. Сторонним (не от производителю ПЛК) программам доступ к данным с ПЛК предоставляется с помощью стандартного программного интерфейса OPC.

Платформа S5 позволяет подключить существующий, и создать новый нижний уровень на основе ПЛК используя OPC. В таком случае нет никаких особенностей построения НУ.  Нижний уровень создается на основе технологий S5. В этом случае в качестве контроллера используется любой одноплатный компьютер, удовлетворяющий требованиям к аппаратному обеспечению.

В состав S5 входит библиотека L2 (сокращенно от LowLevel) для создания нижнего уровня. Фактически, это программа, которая запускается на нижнем уровне. Программа содержит весь код работы с сетью, взаимодействия оборудованием, «аквариума для рыбок» — модулей, специфичных для конкретной системы.

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

Конфигурация модулей ввода-вывода и их соответствие данным системы заносится в текстовые конфигурационные файлы *.devcfg. Вот пример описания одного дискретного входа из файла dispatch.devcfg

Код алгоритмов пишется на языке Java в среде Eclipse (собственно говоря, весь код системы так и пишется). Платформа в виде библиотеки L2 предоставляет API доступа к входам/выходам, другим модулям, сети и верхнему уровню, хранимым данным и др. Напомню, что библиотека и программа L2 — это одно и то же. При запуске на контроллере L2 — программа, при программировании в Eclipse — библиотека. Созданные модули представляют собой jar-архивы с исполняемым кодом и сопутствующими файлами настроек.

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

• программа L2 (в виде файла l2_core.jar);
• конфигурационные файлы модулей в/в — dispatch.devcfg, clocks.devcfg (соответственно, для подсистем диспетчеризации и единого времени);
• модули и конфигурации алгоритмов — DispatchDlm.jar / dispatch.dlmcfg и ClockDlm.jar / clock.dlmcfg.

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

Сервер — центральная часть систем на базе платформы S5. Скучно перечислять функции сервера (обработка данных в реальном времени, долговременное хранение, работа с НУ и АРМами и т.п.), поскольку все серверы всех систем осуществляют одни и те же функции.

Следует только сказать несколько слов о том, какие есть особенности у сервера S5 с точки зрения эксплуатации и с точки зрения разработки. Сервер S5 состоит из трех компонент:

• Сервер приложения (Java EE application server) с кодом платформы S5. В Тбилисском метро используется Red Hat Wildfly AppServer;
• СУБД для хранения данных, используется MySQL (точнее, его клон СУБД mariadb);
• сервер для web-клиентов, точнее контейнер сервлетов. Используется Tomcat.

Каждый из этих компонент может быть запущен на отдельных компьютерах, хотя для Тбилисского метро со всеми задачами справляется один сервер. А на этапе разработки, у программистов зачастую на ноутбуках крутятся одновременно и НУ, и сервер, и АРМ и все это в режиме отладки в среде разработки Eclipse. В общем, несмотря на грозные слова «сервер приложения», «СУБД», «web-сервер» и т.п., все они достаточно легковесны, пока не имеют дела с большими объемами данных в реальном времени. 

Установленный и работающий сервер S5 практически не требует настройки или обслуживания. Хотя, при необходимости все задачи работы с сервером решается мощной утилитой командной строки s5admin. Практически все возможности сервера доступны с помощью s5admin. Утилиту можно запустить как на самом сервере, так и на удаленной машине, подключившись к серверу по сети.

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

А вот с точки зрения разработчика, ПО сервера S5 имеет множество решений, направленных на повышение производительности именно разработчиков. Но это, увы, не тема обсуждения. Следует упомянуть только о том, что все функции сервера сгруппированы в службах, а службы содержатся в одной точке входа под названием ServerAPI. Примеры служб:

• sysdescr — уже упомянутое описание системы, позволяет программно создавать, редактировать и получать описания иерархии классов предметной области;
• objservice — содержит перечень всех объектов системы, по мере работы системы появляются новые объекты, старые исчезают (но остаются в истории!).
• currdata — в реальном времени сообщает текущие значения всех данных, которые меняются во времени;
• userservice — управление пользователями системы и их правами;

Есть также службы справочников, команд, событий, исторических данных, реестр настроек, конфигуратор АРМов и др. Доступ ко всем службам есть не только на сервере, но и на клиентах (НУ и АРМах).

В службах важно то, что приложение специфичный код на сервере тоже пишется в виде служб. Точнее, единственный способ на сервере иметь приложение-специфичный код — это оформить его в виде службы S5. Побочный бонус появляется в том, что приложение-специфичные службы, будучи равноправны со встроенными службами, также доступны и вне сервера — на НУ и АРМах.

Верхний уровень (ВУ) — АРМы

Таблица 2. Отличия реализации верхнего уровня ПО на базе стандартных систем и на платформе S5

Реализация ВУ с помощью стандартных систем

Реализация ВУ с помощью платформы S5

В стандартных системах для построения АРМа используется специализированное программное обеспечение. Для АСУТП — это HMI часть SCADA пакеты (например, Siemns Simatic WinCC или GE Proficy iFix). Для систем с элементами ИУС используются пакеты типа OSIsoft PI или Wonderware. Чаще же всего используются заказные системы (просто самописные программы под конкретную задачу).

Платформа S5 предлагает набор библиотек и средства для облегчения создания ЧМИ (человеко-машинный интерфейс), попросту АРМа. Эти средства включают в себя: Один АРМ для всего — сколько бы разных АРМов не требовала система, пишется одна программа АРМа, что убыстряет разработку, облегчает сопровождение и повышает надежность. Идея заключается в том, что один АРМ содержит все экраны, и все функции, которые нужны во всех АРМах. Служба «Конфигуратор АРМов» платформы S5 позволяет настроить видимую часть АРМа для каждого пользователя индивидуально. То есть, что увидит пользователь, запустив АРМ зависит от того, что ему предоставил администратор. Разработчик же создает одну программу полнофункционального АРМа; singlesourcing — этим термином обозначается возможность используемой технологии Eclipse RCP/RAP. Суть в том, что та самая одна программа АРМа одинаково запускается как в виде отдельного приложения «толстый клиент», так и из браузера «тонкий клиент», просто зайдя на заданную страницу. На рисунке внизу показан как раз Web-клиент, запущенный в браузере. Разница между «толстым» и «тонким» клиентом, только та, которая привносится браузером (например, в web-клиенте нельзя использовать клавишу F5, его перехватывает браузер и обновляет страницу). И конечно, разработчик может сделать разными разные версии. Например, в АРМе Тбилисского метро, в web-клиенте отсутствуют кнопки подачи команд, дабы не смущать пользователей, которым запрещено управление поездами из далей интернета. ServerAPI — это такой бонус для разработчиков. На всех уровнях системы (НУ, сервер, АРМ) доступен один, и собственно единственный интерфейс доступа к данным и функциям системы, называемый ServerAPI. Модули, использующие только ServerAPI (то есть, не работающие с оборудованием НУ и пользователем как в АРМе) одинаково работают в любом окружении. В частности, создав например, алгоритм анализа сменных данных, его одинаково успешно можно запустить и на НУ, на сервере и на АРМе. Может такая функциональность не особенно и нужно, однако позволяет одному разработчику с одинаковой легкостью писать код для любой части системы.

Для тех, кто знаком с парадигмой создания GUI средствами Eclipse RCP, не требуется объяснять, что такое перспектива, view или JFace виджеты, которые и позволяют создавать интерфейс любой сложности, и не мешают создать интерфейс произвольной простоты.

II. Методика проектирования систем

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

Таблица 3. Отличия моделей данных для стандартных АСУТП и для платформы S5

Модель данных в «обычных» АСУТП

Модель данных в платформе S5

Используется практически единственная сущность «тег» для установления связи между реальным миром и программной реализацией. Тег представляет собой именованное, типизированное значение, изменяемое во времени. Используется система именования тегов. У разных производителей платформ автоматизации существуют по разному реализованные средства групповых операции и даже подобия объектно-ориентированного сопровождения тегов в проекте. Тем не менее, теги составляют линейный список всех сигналов в системе. При необходимости работы с хранимыми данными, отчетами, аналитикой и статистикой приходится использовать различные средства, имеющие собственные понятия и средства работы с данными предметной области (SQL, табличные процессоры, встроенные скриптовые языки, языки высокого уровня до Java, C#, Delphi). Можно сказать, что в силу разных причин, в «обычных» АСУТП отсутствует единая модель и единый способ работы с данными предметной области (данными ТОУ).

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

Описание системы и хранение свойств объектов реализуют модули sysdescr и objservice сервера Системы. Существует разные способы работы с описанием системы: с помощью программы с графическим интерфейсом, административной консолью s5admin, программно, через API модуля sysdescr.

Ну хорошо, есть описание системы. Как его использовать? И что оно дает? Зачем оно нужно?

Использование: сначала надо подумать и спроектировать систему. Проанализировать предметную область, описать его (сначала на бумаге), а потом ввести описание в систему.

Что это дает: по факту описания, в системе появляются все, что описано. Например, сказано в описании, что есть «поезд» у которого есть «номер» и «скорость», и сказано, поездов 6 штук. Соответственно, в хранилище (в базе данных) появились, условно говоря, таблица «поезда», со столбцами «номер», «скорость» и шесть записей в ней. Можно сразу писать код, рассчитанный на работу с описанными данными (на НУ, сервере, АРМе — везде).

Нужно для того, чтобы использовать все стандартные механизмы хранения и обработки данных, встроенные в библиотеки S5. К примеру, сказав, что есть справочник «Уставки скоростей», сразу начинает работать встроенный редактор справочников — можно в АРМе создавать и удалять уставки скоростей.

Методика проектирования систем на платформе S5 заставляет: сначала проанализировать предметную область, потом сформулировать результаты в формате объектно-ориентированного описания системы, и только после этого приступить к программированию. Системный анализ — одно из самих интересных этапов разработки больших систем. Но обсуждение собственно методики анализа предметной области и составления описания системы выходит за рамки настоящей статьи.

Даже не освоив эффективные приемы объектно-ориентированного анализа, по самому факта наличия предварительного проекта резко повышает качество и надежность создаваемых на платформе S5 систем.

III. Требования к аппаратному обеспечению систем на платформе S5

Сразу поясним — речь идет о требованиях к аппаратному обеспечению нижнего уровня, когда НУ тоже делается на основе S5, а не используется «обычные» решения на базе ПЛК. В требованиях же к остальным частям (сервер, компьютеры АРМов) нет никаких особенностей: комфортная работа выбранной операционной системы (поддерживаются все Windows, Linux, MacOS), работа Java версии 7 и выше. А всякие память, мощь процессора, объем диска и другие требования зависят от масштаба задачи (количества объектов в системе, количество одновременно работающих пользователей и т.п.).

Итак, именно требования к аппаратному обеспечению отличает S5 от любых других (известных автору) платформ разработки. Главное отличие в том, что единожды разработанная программа НУ работает на любом оборудовании, удовлетворяющий сумме требованиям.

Не звучит? А имеется в виду следующее: подходящее оборудование можно использовать в любое момент жизненного цикла системы. Например, при внедрении в качестве контроллера использовался одноплатный контроллер RaspberryPI (ARM архитекутра, 32 бита) и модули ввода вывода Phoenix с RS-485 интерфейсом. После нескольких лет эксплуатации можно заменить на одноплатный компьютер Octagon Systems (Intel архитектура, 64 бита) и модули ввода-вывода B&R с Ethernet интерфейсом. Масимум, что потребуется — это изменение настроек в текстовых файлах конфигурации на конкретном контроллере.

Другими словами — отсутствует такая проблема, как стандартный вопрос заказчика «А это оборудование будет выпускаться еще 10 лет?». Ответ простой — неважно. Не будет выпускаться и не надо, гарантировано будет десятки других моделей, которыми вы можете заменить оборудование.

Еще раз повторим, что платформа S5 в части оборудования контроллерной платформы полностью отменяет привязку заказчика к одному производителю, будь то Siemеns или Schneider Electric.

Для того, чтобы понять как такое возможно, рассмотрим собственно требования к аппаратному обеспечению нижнего уровня со стороны платформы S5. Уточним, что требования относятся только к контроллеру (в смысле процессорный модуль) и периферии (модули аналогового и дискретного ввода-вывода).

Требования к процессорному модулю

• одноплатный компьютер с возможностью запуска операционной системы Linux;
• возможность запуска среды Java SE версии 7 или выше;
• частота процессора не ниже 500 Мгц;
• ОЗУ не менее 256 Мбайт;
• разъем для флеш-карты (SD/MicroSD) емкостью не менее 8 ГБайт;
• наличие порта Ethernet 100 Мбит с разъемом RJ-45;
• порты UBS 2.0 не менее 2 шт. (разъем тип А или microUSB);
• встроенные часы реального времени со встроенной или внешней батареей;
• видео адаптер с выходным разъемом HDMI или VGA.
• Вот и всё.

Обратите внимание, что в требованиях нет ни архитектуры процессора (Intel, ARM), ни разрядность (32/64 бита), наличие каких-либо шин (PCI, SATA, i2c). Только надо учесть, что для «тяжелых» задач (особенно, при наличии графического интерфейса на НУ) могут быть более жесткие требования по мощности процессора и объему ОЗУ.

Получается, что в настоящее время существует много производителей оборудования в диапазоне цен $50-$300, которые производят десятки моделей подходящих контроллеров. Конкретно в проекте Тбилисского метро используются контроллеры Odroid-U3 (см. выше), мощность которого (при цене $65 в Корее) на порядок выше, чем потребности текущих задач.

Требования к модулям ввода/вывода

• наличие модулей всех типов в линейке (дискретные входы и выходы на 24VDC и 220VAC, аналоговый в/в различной разрядности, скорострельности и диапазонов);
• возможность наращивания количества модулей и гибкого конфигурирования по типам;
• возможность самодиагностики, надежность, температурный диапазон и т.п.

А особое требование со стороны платформы S5 одно: >подключение к процессорному модулю по протоколу Modbus.

Поддерживается как Modbus через Ethernet TCP/IP, так и последовательный интерфейс RS-485 (для чего используется переходник USB на RS-485).

Модули в/в с поддержкой Modbus также производится многоми компаниями по всему миру и их выбор дело вкуса и стоимости.

Надо также обратить внимание на возможность подключения практически любой нестандартной периферии к НУ на основе S5. Задача подключения состоит из двух частей:

1. Физическое подключение. Подключение по Ethernet или USB осуществляется напрямую к контроллеру. Для RS-485 переходник USB на RS-485. Другие соединения нужно привести опять же к одному из Ethernet, USB, RS-485. «Драйверы» для этих соединений входят в состав библиотек L2.
2. Программное подключение. В настоящее время платформа S5 «из коробки» поддерживает стандартный протокол Modbus и специализированные протоколы LGCCP (работы с часами и таймерами) и протокол работы оборудования нашей системы ТРОЛЛЬ. Если информация о протоколе существует, то его несложно реализовать на языке Java. Библиотека L2 платформы S5 имеет средства для работы с нестандартными протоколами.

Проблемы с подключением нестандартной периферии могут возникнуть при отсутствии открытой информации о протоколе обмена.

IV. Требования к специалистам, сопровождающим систему

В сравнении легче понять требования к инженерам-программистам, сопровождающим систему, поэтому, сравним «обычную» систему (АСУТП, АСДУ) и систему на платформу S5.

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

Часть системы	Требования стандартных АСУТП	Требования платформы S5
Нижний уровень, алгоритмы управления	Аппаратная платформа: ПЛК (напр. Siemens S7-300, Schneider Modicon M340) Язык программирования: IEC 61311 совместимый, от поставщика ПЛК Среда разработки: от поставщика ПЛК (напр. Simatic Step 7, Unity Pro)	Аппаратная платформа: персональный компьютер Язык программирования: Java Среда разработки: Eclipse
Cервер, информационно-управляющая часть	Аппаратная платформа: персональный компьютер Язык программирования: какой-либо из языков высокого уровня (Java, C#, C++, JavaScript) Среда разработки: может быть любым (Eclipse, IDEA, VisualStudio, Delphi и др.)
АРМ (обычный и web-клиент)	Аппаратная платформа: персональный компьютер Язык программирования: специфичный для среды разработки (схожый с JavaScript или Visual Basic) Среда разработки: от поставщика ПЛК (напр. WinCC, Vijeo Citect)

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

Для обслуживания ПО решения на платформе S5, вне зависимости от масштаба, достаточно одного инженера-программиста, с хорошим знанием языка Java, и естественно, API библиотек платформы S5. Также следует обратить внимание, что среда разработки Eclipse также является открытым программным обеспечением, не требующим каких либо лицензионных выплат (и сравните со стоимостью типового набора комплекта средств разработки «обычного» решения).

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

В заключение

В заключение хотелось бы еще резюмировать преимущества разработки систем автоматизации на платформе S5:

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

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