Торжественное открытие Троицкого моста, построенного по проекту французского строительного общества «Батиньоль», состоялось 16 мая 1903 года, как часть празднеств по случаю 200-летия со дня основания Петербурга. Безусловно, длительная эксплуатация моста в условиях неблагоприятной экологической обстановки, высокий уровень транспортной загрузки, а также то, что за минувшие сто лет на мосту, за исключением замены разводного пролета, не проводилось капитального ремонта, не могли не отразиться на его состоянии — оно было признано крайне неудовлетворительным. Реконструкция уникального объекта была приурочена к 300-летнему юбилею города и, помимо применения современных методов проектирования, таких, как создание электронной модели сооружения, бережного и скрупулезного подхода к проектированию, включала внедрение системы автоматизированного контроля и управления разводкой Троицкого моста. Разработка и внедрение этого решения были поручены городским «Мостотрестом» ЗАО НПП «Промтрансавтоматика».
Система автоматизированного контроля и управления разводкой Троицкого моста — это часть единой информационной системы разводных мостов Санкт-Петербурга. Все данные о состоянии устройств мостов и о готовности к разводке поступают на центральный диспетчерский пульт и в технический отдел «Мостотреста».
Дело в том, что в период навигации каждую ночь через город по Неве проходит до 50 судов. При таком интенсивном судоходстве любые неисправности при разводке конструкций и механизмов разводных мостов недопустимы. Недавний случай, когда при проходе моста затонуло одно из судов и навигация была остановлена на три дня, привел к огромным убыткам, в несколько раз превышающим стоимость самого затонувшего судна. Поэтому расписание разводок соблюдается буквально с точностью до минуты.
Кроме того, на разводку моста отводится 10 мин, но большая часть этого времени уходит на то, чтобы остановить поток машин и пешеходов, которые в последний момент пытаются попасть на другой берег. Поэтому непосредственно на сам процесс разводки остается всего 3—4 мин. Развести мост за такое время возможно только при идеальной работе всех его устройств и механизмов (масса разводного пролета моста — 5000 т!). Малейший сбой в функционировании системы управления может привести к повреждению механизмов моста и нарушению как графика судоходства, так и сообщения между берегами.
Именно поэтому при внедрении системы автоматизированного управления разводкой основное внимание уделялось повышению надежности работы оборудования. Помимо устранения возможных ошибок персонала, диагностический комплекс должен был оперативно отслеживать состояние устройств моста и прогнозировать возможные неисправности. Кроме того, система должна была решать задачу автоматизированного контроля за энергоснабжением устройств моста, системы сигнализации и каналов связи, а также вести архив данных, связанных с эксплуатацией моста с целью последующего анализа работы механизмов и устройств и действий обслуживающего персонала.
Таким образом, управляющая операционная система должна была отвечать самым взыскательным требованиям к надежности и к работе в режиме реального времени. Несвоевременная подача команды могла бы привести к поломке механических устройств моста.
Профиль клиента |
---|
Компания: Местонахождение: Проблема: |
Профиль партнера |
---|
Компания: Местонахождение: Руководитель: Решение: |
Профиль партнера |
---|
Компания: Руководитель: Решение: |
Система управления мостом
Разводные мосты Санкт-Петербурга делятся на механические и гидравлические, и Троицкий мост относится ко второму типу. Практически все критически важные узлы, механизмы и конструкции моста оснащены датчиками на базе микроконтроллеров Atmel. Примерно 30 датчиков следят за давлением масла в гидросистемах. Есть группа датчиков, контролирующая срабатывания аварийных клапанов, на случай аварийного выброса масла, и группа датчиков, контролирующих ток (двигателей, гидрозолотников, которые переключают на разводку или на наводку). Всего насчитывается около сотни датчиков.
АСУ Троицкого моста — это трехуровневая система, включающая контроллеры, управляющий компьютер и компьютер пульта механика. Управляющий компьютер опрашивает контроллеры, анализирует результаты измерений, управляет процессом разводки моста и передает результаты на компьютер пульта механика по сети Ethernet. Информация с датчиков передается управляющему компьютеру по интерфейсу RS-485. В тех случаях, когда требования к скорости реакции приложения на изменение сигнала не позволяют применять медленный RS-485, сигнал подключается к плате PCL-730 фирмы Advantech. Компьютер пульта механика, работающий под управлением Microsoft Windows 98, отображает информацию, протоколирует и передает данные на центральный диспетчерский пульт по выделенной линии.
«Решение о выборе операционной системы для управляющего компьютера мы принимали тяжело и осторожно, — вспоминает генеральный директор ЗАО НПП «Промтрансавтоматика» Евгений Лейбович. — Альтернатива была такая — поставить какой-то контроллер в управление и жестко зашить в него алгоритмы управления насосами без всякой операционной системы. Но все же нам хотелось иметь расширяемую многозадачную систему, и притом не самодельную, а промышленную. В итоге выбор пал на QNX 4.25».
ЗАО НПП «Промтрансавтоматика» |
Образовано в 1999 году, правопреемник ТОО «Стек», созданного в 1994 году. Традиционная сфера деятельности НПП «Промтрансавтоматика» — разработка и внедрение электронных автоматизированных систем, построенных с применением микропроцессоров и промышленных компьютеров. Эти системы применяются в метрополитене Петербурга, на разводных мостах города, на железнодорожном транспорте и в других областях, где необходим тензометрический контроль мостовых и других инженерных сооружений, контроль и измерение линейных размеров и перемещений. |
Дополнительное соображение, которое заставило сделать выбор в пользу QNX, — это возможность «посадить» ОС на флэш-диск. В этом случае перезагрузка машины под QNX занимает секунды. «Если сработал сторожевой таймер, то через секунду контроль над процессом разводки будет восстановлен. А система Windows гораздо дольше перезагружается», — объясняет Евгений Лейбович.
Компания-невидимка
Поскольку операционная система QNX не слишком известна на нашем рынке, стоит хотя бы тезисно рассказать об истории ее создания и эволюции. Компания QSSL, разработавшая операционную систему QNX, была организована в 1980 году выпускниками канадского университета в Ватерлоо Дэном Доджем и Гордоном Беллом. Сначала компания называлась Quantum Software Systems, а ее продукт — QUNIX (Quantum UNIX). После вежливого письма адвокатов компании AT&T (которой в то время принадлежала торговая марка Unix) имя продукта изменили на QNX. Спустя некоторое время изменили и название самой компании — на QNX Software Systems (http://www.qnx.com).
Первый программный продукт, получивший коммерческий успех, назывался просто QNX и работал на процессорах 8088-й серии. Затем, в начале 80-х, была выпущена операционная система QNX2. Она до сих пор успешно применяется во многих ответственных системах. Примерно в 1991 году появилась ОС QNX4 с улучшенной поддержкой 32-разрядных операций и стандарта POSIX. И, наконец, в 1995 году была заявлена новая модификация ОС семейства QNX, называемая QNX/Neutrino.
В QNX изначально были заложены несколько принципов, которые не меняются от поколения к поколению и от версии к версии: это операционная система реального времени на основе микроядра с межзадачным взаимодействием на основе обмена сообщениями, причем распределенная сетевая ОС, т. е. это верно и для работы в сети. А вот открытость для разработчика существенно изменялась от версии к версии. Если для QNX2 написать драйвер было крайне затруднительно, то в QNX4 модель драйвера была значительно упрощена. Тем не менее написать драйвер возможно далеко не для любого типа устройств — из-за закрытости ряда интерфейсов (например, сетевой драйвер в QNX4 самому написать было нельзя). В QNX6 все драйверы были приведены к единой модели, и все интерфейсы стали открытыми.
В отличие от предшествующих версий, работавших только в PC-совместимых архитектурах, QNX6 поддерживает процессоры x86, MIPS, PowerPC, ARM, XScale, SH-4 и легко адаптируется к процессорным платам практически любой конфигурации. Кроме того, особое внимание было уделено проработке архитектуры с тем, чтобы ее можно было эффективно масштабировать: как «вверх» (добавляя новые сервисы и расширяя функциональность), так и «вниз» (урезая функциональность, чтобы «втиснуться» в ограниченные ресурсы). Иными словами, QNX6 можно установить там, где QNX4 не уместилась бы.
Минимизируя временные задержки
Весь комплекс работ по реконструкции Троицкого моста был проведен за один межнавигационный период (с конца ноября по конец апреля). Сложность состояла в необходимости отлаживать систему на реальном оборудовании.
Однако главная проблема, с которой пришлось столкнуться разработчикам «Промтрансавтоматика», заключалась в том, что далеко не все периферийные устройства имеют драйверы под QNX. «Очень часто нельзя купить промышленные платы вместе с драйвером под QNX, — говорит Евгений Лейбович. — Мы испытывали трудности и неудобства в связи с ограниченным выбором периферийных плат. Нам приходилось и самим писать драйверы».
Когда программисты «Промтрансавтоматики» приступали к написанию драйверов под QNX, необходимого опыта у них не было, была только практика подобной работы для Windows. Но переход оказался достаточно простым. По мнению специалистов «Промтрансавтоматики», драйверы под Windows очень аппаратно зависимы, и документация к ним плохая. Система QNX менее сложна и более логична. В то же время Windows не раз показывала себя как непредсказуемая система в случаях распределения ресурсов.
Кроме того, при работе под управлением Windows не всегда удается выдерживать временные интервалы. Программа, написанная под Windows, формирует какую-то задержку: раньше она достигала сотен миллисекунд, сейчас — десятков миллисекунд. «Но если нужно точнее формировать временные интервалы, то Windows не годится, — говорит Евгений Лейбович. — С QNX я не боюсь запускать систему управления в автоматическом режиме, а с Windows я опасался такой ситуации, когда команда движения какого-то механизма прошла, а потом машина зависла команда «стоп» не проходит».
Тем не менее опыт специалистов «Трансавтоматики» говорит о том, что систему визуально-графического отображения все-таки целесообразно писать в расчете на Windows. Причин тому две: графическая оболочка под QNX дорога и, как следствие этой дороговизны, наработок под нее гораздо меньше, чем под Windows. «Мы не применяем SCADA-систем, — пояснил Евгений Лейбович. — Есть отзывы, что такие системы, особенно советской разработки, сбоят. А система закрыта, и непонятно, как с этим бороться».
Компромиссное решение было достигнуто путем применения средств разработки на С. Причем, по мнению программистов «Промтрансавтоматики», скорость написания и скорость отладки приблизилась к SCADA-системам, а гибкость выше, особенно если уже существуют определенные наработки.
Итоги и перспективы
Система автоматизированного контроля и управления разводкой Троицкого моста эксплуатируется с апреля 2002 года. Постоянно контролируется работа сигнальных устройств, и если интенсивность светового сигнала оказывается недостаточной для безопасной проводки судов, об этом немедленно извещаются механик моста и диспетчер. Все данные о работе механизмов моста во время разводок фиксируются в архиве и изучаются с целью прогнозирования неисправностей.
«Я очень доволен тем, что на промежуточной машине стоит QNX. Нет проблем с зависанием, пробросами, срабатыванием сторожевых таймеров, — рассказывает Евгений Лейбович. — Контроллеры принимают команду от машины из-под QNX включить что-то. Таким образом, Windows-машина дает QNX-машине команду по сети «развести», и даже если она потом «повисла», управление идет из-под QNX, и никаких неожиданностей в движении судов по фарватеру Невы не возникает». Под QNX машина работает без отключения несколько месяцев.
После реконструкции Троицкий мост за две навигации ни разу не выбился из графика разводки. Заметим, что в тот день, когда мы встречались с разработчиками, на Оптинском мосту случился сбой работы насоса. Пока с ним разобрались, задержка составила десятки минут.
Еще одна важная особенность системы: в момент разводки компьютер выдает механику изображения тех механизмов и датчиков, которые задействованы в процессе разводки моста, и данные всех датчиков пишутся в архив. По этим детальным временным графикам главный механик «Мостотреста» может отследить изменения в процессе работы, что позволяет предвидеть отказы оборудования. Например, если виден большой провал уровня масла в момент пикового давления, это значит, что система начала подсасывать воздух.
Предсказывать вероятность неисправности — одна из главных задач системы. «Мы не доверяем этот анализ машине, потому что он многогранен и бывает крайне сложен, — рассказывает Евгений Лейбович. — Это задача будущего». А в ближайших планах — внедрение аналогичной системы контроля и управления разводкой на тех мостах, которые ставятся на реконструкцию. Первым станет мост Лейтенанта Шмидта, реконструкция которого намечена на 2004 год.