Техническая структура интеграции ПИ в ЛВС Ethernet

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

Здесь цифрами обозначены: 1, 2, 3 – АРМы агентов соответственно ПП, ПФ и ПО; 4 – интерфейсные модули сбора и обработки информации; 5, 6, 7, 8, 9 – ПК соответственно ПИ ПП, ПИ ПФ, ПИ ПО АРМов ДСЦ
и ДСЦС; 10 – сервер АСУ СС; 11 – сервер БД и БЗ; 12 – ПК и АРМы системы автоматизации СГ; 13, 14 – АРМы АСУ СС и СТЦ; 15 – сетевой коммутатор.

В основу предложенной структуры положено достижение возможности непрерывного ведения моделей в ПП, СГ, ПФ и ПО, которые в совокупности составляют единую модель СС (ЕМСС) [3].

Под такой ЕМСС понимается пространственно-временная модель слежения за подходом поездов, их перемещением в ПП, надвигом на СГ, роспуском отцепов и накоплением составов по путям ПФ, вытяжкой и занятием путей ПО, отправлением вновь сформированных поездов, а также регистрации временных параметров всех технологических операций перемещения подвижных единиц и выполнения регламентных работ эксплуатационным персоналом.

Как следует из рис. 3.15, архитектура интегрированной системы информатизации СС является открытой для дальнейшего развития и расширения зон информатизации (промышленные зоны, маневровые работы, подъездные пути, грузовые дворы и др.).

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

Рис. 3.15. Структурная схема интеграции ПИ СС

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

Принимая во внимание реальный режим ведения ЕМСС и временные ограничения на принятие решений, ключевым вопросом является выбор встраиваемой платформенной операционной системы реального времени ОСРВ.

Анализ различных известных ОС позволил установить, что для решения поставленных задач наиболее приемлемой является QNX Realtime Platform (QRTP) компании QNX Software Systems Ltd.

В основе QNX Realtime Platform лежит ОС жесткого реального времени QNX/Neutrino c встраиваемой графической оболочкой Photon micro GUI.

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

Каждый процесс в ОС QNX/Neutrino выполняется в своем собственном защищенном адресном пространстве. Это обеспечивает QNX/Neutrino «встроенную» надежность. Объем кода ядра настолько мал, что ошибки
в нем практически исключены. Если же случится программный сбой, пусть даже в драйвере оборудования или каком-нибудь другом критичном процессе, система сможет корректно самовосстановиться, не требуя перезагрузки.

Поскольку Photon microGUI основан на той же самой распределенной архитектуре, что и сама QNX/Neutrino, становится неважно, где находится целевое приложение. Используя в качестве транспортного протокола стек TCP/IP, разработчик может при помощи технологии удаленного пользовательского интерфейса (RUT) легко наблюдать за своим приложением
и контролировать его фактически из любой точки пространства.

Сетевая технология Qnet дополняет встроенный механизм обмена сообщениями между процессами в QNX/Neutrino возможностью передачи сообщений по сети, позволяя таким образом объединить ресурсы локальной сети QNXв единый логический суперкомпьютер. С использованием Qnet становится неважно, где физически расположен ресурс – любой процесс может получить доступ к любому ресурсу в сети, будь то файловая система, менеджер процессов или аппаратура, не заботясь о его поиске
и адресации!

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

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

Разработчики приложений Photon могут значительно упростить труд рутинного программирования с помощью визуального средства разработки графических приложений Photon Application Biulder (PhAB). B PhAB графический интерфейс создается визуально, после чего автоматически генерируется соответствующий Си-код. PhAB помогает упростить не только стадию разработки интерфейса, но и стадии отладки и тестирования.

Если приложению будет необходимо просматривать веб-страницы или, наоборот, служить веб-сервером, Интернет-средства QNX/Neutrino предоставят разработчику все необходимые возможности. Если разработчику необходим веб-браузер, но нет времени или средств на разработку своего собственного, можно использовать штатный для QNX/Neutrino веб-браузер Voyager, поддерживающий такие современные технологии, как SSL-128.

Модульность мультикомпьютерной структуры на базе современныхПК, создание открытых локальных сетей передачи данных между подсистемами и АРМами должны обеспечивать по мере необходимости рас­ширение функциональных и интеллектуальных возможностей ПИ.

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