Ввод в эксплуатацию систем автоматизации и диспетчеризации

В. В. Панкратов, директор ООО «ВВП»

Н. В. Шилкин, доцент МАрхИ

Эта статья является продолжением материала, опубликованного в журнале «АВОК», 2008, № 8.

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

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

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

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

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

У обоих этих подходов есть плюсы и минусы, и всегда необходимо четко представлять возможные достоинства и недостатки того или иного подхода. Можно предположить, что при минимальной стоимости или даже свободном распространении подобных программных пакетов расширится число организаций, заинтересованных в его приобретении. Но, с другой стороны, всегда следует иметь в виду, что количество программистов, способных квалифицированно работать с достаточно сложным технологическим оборудованием, ограничено. Любая пусконаладочная организация обязана обеспечить гарантию на поставленную систему. По действующему законодательству минимальный срок гарантии составляет один год, однако многие крупные компании увеличивают его. Особенно это актуально при строительстве или реконструкции каких-то крупных и сложных объектов (например, аэропортов), работы на которых продолжаются зачастую не один год. В этих условиях существование программного обеспечения, не контролируемого производителем, может привести к возникновению некоторой проблемы. Пусконаладочная организация осуществляет запуск системы, ввод ее в эксплуатацию и предоставляет гарантию на свою работу. Но здесь возникает вопрос: кто, в свою очередь, даст гарантию пусконаладочной организации, что оборудование работает именно на том программном коде, который был создан программистами этой организации, если программный пакет для его создания будет распространяться свободно и возможность для модификации этого кода появляется у специалистов, квалификация которых неизвестна? Иными словами, совершенно непонятно, как может пусконаладочная организация гарантировать работу системы при гипотетической возможности неквалифицированного вмешательства в алгоритм ее работы. Это вопрос технологической безопасности, как минимум, оборудования, функционирующего на объекте, а зачастую и потенциальной угрозы жизни людей, находящихся на объекте.

Возможную заинтересованность в приобретении такого программного пакета могла бы также высказать организация, эксплуатирующая объект, на котором находится такое оборудование. В ходе эксплуатации нередко бывают ситуации, когда возникает необходимость произвести какие-то изменения в программной среде. Укомплектованная система всегда имеет некоторый резерв по входам/выходам, поскольку с учетом кратности используемых модулей всегда остаются незадействованные порты, а зачастую заказчик просит предусмотреть резервные входы/выходы. Появляется техническая возможность модернизировать систему, подключить дополнительные модули. У эксплуатирующей организации появляется выбор – выполнить эти работы своими силами или привлечь специализированную организацию. На сегодняшний день программное обеспечение позволяет отследить все манипуляции, связанные с работой контроллера: перезагрузка ядра системы в контроллер всегда фиксируется. Можно отследить, когда и с каким ключом была осуществлена такая загрузка. В конечном итоге в результате загрузки в контроллер некорректно написанного программного обеспечения может произойти выход из строя оборудования (разморозка системы, заклинивание и выход из строя насосов и т. д.). Нет полной ясности, следует ли рассматривать подобный выход из строя оборудования как гарантийный случай. Разумеется, с точки зрения пусконаладочной организации подобные случаи никоим образом не могут быть отнесены к гарантийным. Возникает потенциально конфликтная ситуация.

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

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

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

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

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

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

Объекты рассчитываются на достаточно длительный срок эксплуатации, и инженерное оборудование в них, в том числе и системы автоматизации, также должно функционировать достаточно длительный срок. Нет никакой гарантии, что организация, осуществлявшая пусконаладку оборудования, будет успешно вести свою деятельность в течение этого длительного срока. Какие-то фирмы разоряются, кто-то уходит с рынка, и наоборот, появляются новые компании. Понимая это, крупные пусконаладочные организации никогда не используют в отношении конечного потребителя метод «выкручивания рук». Уходя с объекта, серьезные фирмы обязательно оставляют заказчику полный комплект документации и все электронные версии программного кода. Если служба эксплуатации объекта приобрела необходимый программный пакет, она всегда при наличии квалифицированного персонала имеет возможность изучить алгоритм работы системы, изменить его или модернизировать. Даже если такого программного пакета у службы эксплуатации нет, всегда есть возможность вызвать специалистов в данной области, обладающих всеми необходимыми инструментами, в данном случае – необходимыми программными средствами. Эти специалисты, получив резервную копию программного кода и необходимую документацию, имеют возможность очень быстро разобраться в его алгоритме и внести соответствующие изменения.

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

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

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

Крупные поставщики оборудования для систем автоматизации предлагают специальные программные пакеты, позволяющие интегрировать все системы жизнеобеспечения зданий в единую информационную базу. Этот программный пакет имеет свою лицензию и приобретается непосредственно под обслуживаемый объект. Такой пакет уже не является принадлежностью или собственностью пусконаладочной организации, а является собственностью заказчика. Заказчик еще на этапе проектирования закладывает в техническое задание требующийся функционал и необходимость интеграции с устройствами третьих фирм. Эти сторонние устройства могут передавать информацию как транзитно через контроллер (контроллер среднего уровня), так и напрямую непосредственно в сервер. Например, датчики, от показаний которых зависит алгоритм работы системы, всегда подключаются непосредственно к контроллерам. Делается это для того, чтобы возможная авария сервера не влияла на работу системы. Если же показания датчика носят исключительно информативный характер, например, получение сервисных данных со станции холодоснабжения, показания счетчиков учета электроэнергии, то такой датчик подключается к серверу сбора и обработки информации напрямую. Подключение этих датчиков и визуализация их показаний – вопрос выбора интерфейсов, шлюзов передачи данных и вопрос лицензирования этих опций в программном пакете. Стоимость программного пакета зависит от количества точек, причем эта стоимость изменяется абсолютно линейно. Нет необходимости заранее приобретать пакет «с запасом», по мере модернизации и расширения системы одновременно модернизируется и программный пакет.

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

Ядро системы, осуществляющее процесс сбора и обработки информации, работает либо на рабочей станции, либо на сервере (в зависимости от конфигурации системы) и представляет собой, по сути, СУБД, которое формирует и заполняет базу данных путем запроса данных с контроллера и записи их в соответствующие области памяти.

Второй программный пакет – построитель дисплеев, графический пакет, содержащий в себе инструментарий визуализации. Если при программировании контроллера реализация его работы очевидна – известны технические адреса, переменные, то в вопросах визуализации очень многое зависит от личных предпочтений заказчика. Ни один из заказчиков не осуществляет приемку работы непосредственно с контроллера. Демонстрация возможностей, сдача заказчику и приемка системы осуществляется, как правило, со станции диспетчерского управления в диспетчерском пункте. Вся информация отображается визуально, с помощью набора различных мнемосхем. Пусконаладочная организация предлагает заказчику несколько типовых экранов визуализации информации. Однако у заказчика может быть свое видение ситуации, свои предпочтения. Кроме того, есть чисто субъективные предпочтения в выборе цветов, шрифта и пр. Понятно, что отразить все эти моменты в техническом задании просто невозможно. Кроме того, в ходе эксплуатации могут быть вскрыты какие-то нюансы, которым изначально не было уделено должного внимания. Заказчик, имея в своем распоряжении удобный инструментарий, может очень гибко настроить систему отображения информации в зависимости от собственных потребностей. Разумеется, возможности настройки системы для сотрудников разного уровня очень сильно различаются (разграничение доступа).

Третий программный пакет производит опрос неких технических адресов и преобразование информации в абстрактную базу данных. В этом пакете прописываются непосредственно все каналы связи, все протоколы и формируется база данных внутренних точек. Технические адреса на уровне контроллеров всегда задаются латинскими буквами. Посредством этого пакета может быть произведена локализация. Количество языков локализации не ограничено; каждому техническому адресу может быть приведено в соответствие любое русскоязычное обозначение.

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

По завершении всех этапов пусконаладки система передается заказчику либо в опытную эксплуатацию, либо подписывается акт окончания пусконаладочных работ для того, чтобы начал работать гарантийный период. Подрядчик стремится как можно быстрее закончить все работы и уйти с объекта; в то же время заказчик стремится как можно дольше эксплуатировать объект за счет подрядчика, не подписывая эти акты. Здесь многое зависит от истории взаимоотношений подрядчика и заказчика, перспектив дальнейших отношений и т. д. Есть два режима эксплуатации объекта – зимний и летний, когда система работает абсолютно по-разному. Существуют еще два переходных периода, с точки зрения работы инженерных систем они похожи. Заказчик должен принять систему, работающую во всех режимах. Как правило, основные работы по пусконаладке приходятся на осенний период, поскольку все основные работы (запуск тепловых пунктов, подача теплоносителя) ориентированы на начало отопительного периода. Система автоматизации программируется целиком, но летний режим проверить зимой нельзя. Заказчик может обосновать отказ от подписания акта приемки тем, что он не видел в действии работу системы в летний период. Контраргументом здесь является представление всех распечаток программы работы системы в летний период, а также то обстоятельство, что обязательный минимальный гарантийный срок (один год) затронет и этот летний период и все выявленные недостатки будут устранены по гарантии.

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