Промышленная автоматизация: кто пропишет алгоритмы интеграции

- Как можно классифицировать интегрированные системы в промышленности по поколениям?

- Классификация, безусловно, важна в любой сфере техники и науки, в том числе в автоматизированных системах управления производственными процессами. По поколениям развития, мне кажется, общепринятой классификации нет. Но вполне можно предложить свою классификацию. Определимся, что речь идет об автоматизированных системах диспетчерского управления (АСДУ) и интегрированных с ними системах. Мы не рассматриваем АСУ предприятия в целом, системы класса ERP, OLAP и другие. Также отметим, что классификация применим к предприятиям газовой промышленности и предлагается для некогда входящих в СССР, включая Россию.

Из критериев оценки АСДУ можно выделить – поколения техники и базового программного обеспечения; развитость уровня средств автоматизации – КИПиА; развитость средств связи; функции АСДУ; уровень интеграции приложений между собою и с другими системами (теми же ERP). Важную роль играют и размеры бюджетов, выделяемых на создание систем.

Основываясь на этих критериях можно классифицировать АСДУ следующим образом:

1. Устаревшие системы 60- 80х годов: ЭВМ с закрытой архитектурой, небольшой уровень оснащенности датчиками (КИПиА), устаревшие системы связи (часто играют ключевую роль в построении АСДУ – ограничения и на структуру, и на функции), ограниченные функциональные возможности и отсутствие интеграции; значительные бюджеты поглощаются высокой стоимостью техники.

2. Практически устаревшие локальные системы на базе ЭВМ с открытыми операционными системами UNIX – поколение, «мелькнувшее» в нашей стране в 90х годах и сегодня почти везде передающее «эстафету» поколению «3». Несоизмеримо более удобные средства работы с системой, большая открытость интерфейсов обмена информацией часто «компенсировалась» малым объемом автоматизации и низкоскоростными каналами связи. Реализуется интеграция с базами данных, с расчетными задачами, моделями ГТС.

3. «Локальные системы на базе персональных ЭВМ начального уровня – поколение конца 80 – начала 90-х годов. Определяющим фактором является неразвитость уровня КИПиА и связи при высокой стоимости ЭВМ, а также начальный характер программного обеспечения. Такие системы делались на «рубеже эпох» при общей нехватке средств и, как правило, обладали ограниченными функциями.

4. Локальные и слабо-интегрированные системы SCADA: 90-е годы – настоящее время. Данный тип АСДУ ориентирован практически на решение одной задачи – удаленный контроль и управление технологией (компрессорный цех, телемеханика) в реальном масштабе времени, интеграция с другими системами не реализована, прежде всего, из-за первоначального отсутствия такой задачи, системы успешно работают локально и передают «вышестоящей» диспетчерской несколько отчетных параметров по понятному протоколу.

5. Начальные интегрированные решения – 2000е годы (до 2008-2009), системы класса SCADA и MES. Решив проблему сбора данных, заказчики как правило переходят к интегрированным решениям. Для АСДУ газовой промышленности это, прежде всего, SCADA, Журнал диспетчера, расчеты диспетчера, моделирование трубопроводов, планирование ремонтов. Решения все еще испытывают влияние старых каналов связи и бюджетные ограничения, плюс малый опыт создания таких систем – в результате часто уровень интеграции реально оказывается невысоким.

6. Развивающиеся интегрированные решения (2008/2009 – наше время). Обозначенный рубеж в газовой промышленности во многом связан с принятием Стратегии информатизации ОАО «Газпром». Проектируемые с данного момента системы изначально предполагают большой объем функциональности и требуют высокого уровня интеграции компонентов – функциональной и территориальной. Бюджеты и каналы связи перестают играть существенную роль в определении функций и структуры системы – бюджеты становятся больше, а вычислительная техника доступнее. Однако в качестве ограничений начинает выступать отсутствие опыта создания таких систем и отсутствие подходящего базового ПО. Поэтому, как правило, реализованная функциональность оказывается существенно скромнее той, которая была описана в Техническом задании.

Согласно предложенной классификации, сейчас мы находимся в рамках 4го и 6-го поколений, которые часто развиваются параллельно. Наметился переход от 6-го к 7-му поколению: накопление опыта работы, новая мощная вычислительная техника и более-менее понятные способы взаимодействия разных программных систем позволяют создавать системы с новыми функциями и новым уровнем интеграции.

- Насколько необходима и оправдана интеграция информационных систем разного уровня?

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

Интеграция должна быть вертикальная (по уровням управления – для России это необходимо в силу иерархической системы диспетчерского контроля) и горизонтальная – по приложениям. Последние годы развитие каналов связи сняло большинство вопросов вертикальной интеграции. Что касается горизонтальной – то задача простого сбора и начального анализа данных решена относительно давно.

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

- Какие основные требования сегодня предъявляют к промышленной автоматизации?

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

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

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

- Каковы особенности и тенденции рынка интегрированных систем?

- Базируясь на опыте известных проектов, можно сказать, что рынок реально интегрированных систем находится пока еще в начальной стадии (если вспомнить классификацию – мало где мы реально переходим к «7-му уровню»). Хотя финансирование становится все более и более масштабным, теоритические задумки и поставленные цели не могут не поражать размахом. Однако не всегда задуманное реализуется в полной мере. Причин несколько.

Во-первых, малый реальный опыт системных интеграторов в области реальной интеграции действительно различных и сложных современных приложений. Тому есть объективные причины – проекты в России начались недавно, и для появления такого опыта просто нужно время.

Во-вторых, отсутствие самих приложений или декларативность функционала этих приложений (я не хочу упрекнуть кого либо из разработчиков в лукавстве при анонсировании функционала – в качестве единичных экземпляров в отрасли функционирует очень много интересных и интеллектуально-емких программ: проблема заключается в их «отчуждении» от места первого написания и применения; кроме того, огромное число программ находится на уровне НИОКР).

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

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

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

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

Однако время лечит, и по имеющимся ощущениям через несколько лет (и реализованных проектов) ситуация может измениться.

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

- А с какими основными проблемами сталкивается рынок промышленной автоматизации?

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

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

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

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

- Какова роль проектных институтов?

- Проектные институты в российском варианте – это уникальные организации, не имеющие прямых аналогов в западной (ЕС) школе проектирования и создания систем автоматизации. После распада СССР определенное время большая часть институтов переживала кризис, но уже к середине –концу 90-х годов ведущие коллективы смогли преодолеть «межвременье», набрать кадры и, пользуясь достаточно высокими инвестициями ОАО «Газпром», воссоздать проектное дело. Сегодня в создании системы принимают участие проектировщик (проектный институт), системный интегратор-разработчик, поставщики компонентов решения, а также пуско-наладочные и другие организации. Ведущими являются роли института и системного интегратора, зачастую они совместно выполняют проект.

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

Помимо «старых» «государственных» институтов (их отличает наличие в имени приставок «Гипро.» - государственный институт проектирования…; «ВНИПИ…» - всесоюзный/всероссийский научно-исследовательский проектный институт…), появились новые проектные организации меньшей численности, но зачастую также выполняющие все необходимые проектные работы. Это положительные моменты. Отрицательные же заключаются в том, что не все коллективы вышли на современный уровень проектирования систем. Часто перед ними и не ставится такая задача, так как помимо разработки собственно АСДУ в проектном деле есть огромное число других задач. Другой отрицательный момент видится в системе тендеров. Помимо удлинения проектирования, тендеры не позволяют сложиться устойчивому научно-техническому взаимодействию, не разрешают работать «на будущее», сопровождать и развивать собственные системы.

- Насколько российские предприятия готовы вкладываться в новые разработки, покупать новые продукты?

- Могу судить о больших компаниях. Готовы, заинтересованы, вкладываются. Тенденции перечислены выше – большие системы, большие продукты, большие задачи. Результат пока более частный и скромный, но все системы активно создаются, заказчики не теряют интерес и надежду, и проектировщики и разработчики должны их оправдать.

- Как вы видите ближайшую перспективу?

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

Можно предположить развитие событий по пессимистичному и оптимистичному сценарию.

По пессимистичному прогнозу все запутаются окончательно во все более усложняющихся вопросах менеджмента, безопасности и синхронизации, и энергия разработчиков (плюс средства инвесторов) будет «уходить в свисток».

Можно спрогнозировать и оптимистический прогноз. Интеграторы научатся рано или поздно интегрировать. «Начальство» смирится с тем, что все сроки срываются и немного снизит жесткость условий реализации проекта. Поставщики решений доделают свои решения, локализуют их (для иностранцев) и научат конечных пользователей извлекать из них практическую пользу. А постоянно развивающиеся аппаратные средства и системы коммуникации помогут интегрировать системы и реализовывать сложные алгоритмы.

Я являюсь сторонником оптимистичного прогноза.