Главная База знаний "Allbest" Транспорт Микропроцессорная система управления на железнодорожном транспорте

Микропроцессорная система управления на железнодорожном транспорте

Особенности организации микропроцессорных систем централизации и преимущества их реконструкции. Функционирование ядра системы. Требования к современным системам микропроцессорной централизации. Разработка модели станции. Модель поездного маршрута.

Рубрика	Транспорт
Вид	дипломная работа
Язык	русский
Дата добавления	23.05.2012
Размер файла	2,8 M

посмотреть текст работы

скачать работу можно здесь

полная информация о работе

весь список подобных работ

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

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

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

Безопасность движения обеспечивается, как уже отмечалось, использованием реле 1 класса надежности, а также специальных мер аппаратного и программного характера. К аппаратным мерам безопасности могут быть отнесены:

- динамический режим работы аппаратуры;

- повышенная разрядность адресных и информационных шин;

- К программным мерам безопасности относятся:

- применение безопасного программного обеспечения;

- применение циклического или сигнатурного кодирования приказов;

- реализация одного действия различными алгоритмами.

- Система МПЦ выполняет следующие основные функции:

- выполнение маршрутного набора;

- реализация режима автодействия светофоров;

- фиксация неисправностей;

- оповещение монтеров пути;

- обдувка стрелок.

- Кроме того, выполняются и другие функции благодаря использованию программируемой элементной базы:

- автоматическое протоколирование действий персонала, работы системы и устройств;

- оперативное предоставление нормативно-справочной информации и данных технико-распорядительного акта (ТРА) станции;

- реализация функции линейного пункта ДЦ для кодового управления станцией без дополнительных капитальных затрат;

- автоматизация управления путем формирования маршрутных заданий на предстоящий период (без ограничения емкости буфера);

- накопление маршрутов как по принципу очереди, так и по времени исполнения (без ограничения емкости буфера);

- хранение, просмотр и статистическая обработка отказов МПЦ;

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

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

- сопряжение с информационными системами вышестоящего уровня.

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

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

Во втором режиме (вспомогательном) можно управлять устройствами СЦБ при нарушениях их нормального функционирования. Это относится к использованию пригласительных сигналов, вспомогательному переводу стрелок, аварийной смене направления на однопутном перегоне, искусственному размыканию секций маршрута, вспомогательному режиму открытия переезда. С учетом того, что пользование перечисленными ответственными командами связано частично или полностью блокировочных зависимостей по обеспечению условий безопасности, в АРМ реализованы следующие принципы:

- построение пользовательского интерфейса, исключающее случайную передачу ответственных команд за счет меню вложенной системы;

- посылки двух команд (подготовительной и рабочей) в определенном временном интервале с квитированием прохождения подготовительной команды.

- Комплекс технических средств управления и контроля МПЦ представляет собой программно-аппаратные средства, обеспечивающие следующие функции:

- сбор, обработку и хранение информации о состоянии объектов ЭЦ (положение стрелок, сигналов и путевых объектов);

- передачу этой информации на автоматизированное рабочее место ДСП и другие АРМы по локальной вычислительной сети;

- прием от АРМ ДСП и последующую реализацию команд по установке, отмене и искусственной разделке маршрутов, переводу стрелок и др.;

- сопряжение с системами ДЦ.

Для обеспечения 100%-ного резервирования аппаратура КТС УК дублирована. Один комплект является основным, а другой - резервным. Дублирующий комплект (основной или резервный) работает в режиме «горячего резерва». Комплект, который в данный момент осуществляет обмен данными с АРМ ДСП и реализует команды управления, считается «активным». Второй комплект - «пассивный» - включен, собирает и обрабатывает информацию. Он готов в любой момент перейти в активное состояние.

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

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

2.1 Особенности реализации технологических алгоритмов МПЦ «iпуть»

Программное обеспечение спроектировано по принципу «снизу-вверх». Это позволяет, нормируя и собирая модули на нижнем уровне, создавать более сложную систему на базе уже созданных модулей, поведение которых уже доказано. Такой подход позволит упростить, и снизить расходы на доказательство правильности модулей ПО. Работа модулей основывается только на входных и выходных значениях, что позволяет создавать ПО с более высоким уровнем безопасности за счёт минимизации числа допускаемых ошибок.

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

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

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

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

Описанные объекты входят в базовое ПО и по мере необходимости могут быть дополнены новыми. Каждый выход такого элемента представляет собой определённое состояние, которое может быть числовым, символьным, логическим и т.д., но в конечном итоге представленным множеством цифровых линий. Состояние определяется целиком самим объектом. Входы и выходы объектов подключаются непосредственно к массивам данных. Эти массивы могут относиться как к исполнительной части устройств сопряжения с объектами, так и к части АРМа. Эти два множества массивов существуют в различных физических областях, и доступ к ним осуществляется либо только сервером и АРМом, либо только сервером и устройствами сопряжения. Массивы данных работают на отдельных нитях, со своим оптимальным приоритетом, конфигурируемым под конкретную станцию.

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

2.2 Функционирование ядра системы

К данному понятию будем относить последовательность и правила выполнения всех действий, т.е. в каком порядке идёт обработка процессов и выполнение возложенных на них функций.

Для начала рассмотрим функционирование сервера МПЦ как автономно работающего, т.е. без взаимодействия с резервом. Взаимодействие с другими уровнями и структурная схема сервера МПЦ показана на рисунке 2.1:

Рисунок 2.1 - Схема взаимодействия сервера МПЦ с другими уровнями

Сервер представляет собой ЭВМ, организовывающую логику взаимодействия согласно логике ЭЦ. Общение с уровнем АРМа и с уровнем УСО физически осуществляется через локальную сеть нижнего уровня. Процесс обмена информацией происходит через массивы памяти М1 и М2. Эти массивы физически находятся в одном кристалле ОЗУ для более эффективного контроля его состояния, а логические связи организованы таким образом, что система АРМ имеет доступ только к массиву М2, а УСО - к массиву М1. Это позволяет исключить прямые воздействия, минуя ПО сервера МПЦ.

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

Рисунок 2.2 - Схема интерфейсов взаимодействия ядра МПЦ

Разрабатываемый сервер МПЦ предназначен для работы с небольшим количеством объектов управления, а также его время реакции достаточно большое в силу инерционности релейных систем. Это позволяет организовать обработку массивов не событийным образом, а полную, что в свою очередь гарантирует предельное время реакции для данного множества объектов и исключает потерю значений, различное время обработки функций и множественность вариантов последовательности их исполнения. Схема интерфейсов взаимодействия ядра МПЦ представлена на рисунке 1.2.

Работа ядра происходит циклическим образом. Это означает, что всё время разбито по тактам, и в каждый такт происходит полная обработка значений всех массивов памяти. Ячейки массивов М1 и М2 с точки зрения общения с внешней средой организованы таким образом, что каждая из них в основании базового класса знает, откуда ей брать исходное просчитываемое значение. Это может быть внешний адрес сети нижнего уровня или определённая функция агента.

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

2.3 Функциональные особенности МПЦ

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

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

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

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

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

Для реальных результатов необходимо опытная проверка, которая позволит оценить взаимодействие всех узлов как единое целое. Экспертная оценка, и тестирования на малых решениях, показали, что, для полноценной работы хватает процессора с частотой до 100 МГц.

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

Типичным примером транзакции является установка маршрута. Выполнение данного действия производится за счёт промежуточных состояний агентов, участвующих в его задании. Так для установки маршрута с точки зрения АРМ'а ему необходимо всего лишь установить информационно битовое значение в ячейку, отвечающую за установку. Далее активизируется агент установки маршрута, который проверяет все условия установки и если они в порядке, даёт команду на перевод стрелок. Сама же стрелка не знает о том, участвует она в маршруте или нет, но имеет своё значение положения и времени установки. Через это время агент маршрута проверяет значения стрелок и в случае их правильности открывает маршрут по светофорам, значения которых после установки также проверяются. Если на одном из этапов обнаружен сбой, то агент установки маршрута выдаёт сообщение о месте и типе сбоя. Таким образом, полностью за алгоритмизацию установки маршрута берёт на себя агент маршрута, а стрелки и светофоры являются исполнителями.

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

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

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

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

Система МПЦ построена с условием обязательного выполнения всех функции, предусмотренных ПТЭ бел. ж. д. для систем ЭЦ.

Все центральные зависимости логики централизации и алгоритмы её функционирования реализуются на четырех ядрах централизации, параллельно выполняющих одинаковые управляющие программы МПЦ на основе операционной системы реального времени с проверкой исполнения команд и оснащенных средствами внутренней самодиагностики, что позволяет выявить выход из строя элементов МПЦ или сбой в программе и привести дискретные выходы и напольные устройства в безопасное состояние. Управление объектами (пусковые реле стрелок, сигнальные реле) производится посредством блоков ТУ8Б и ТС16Б через параллельно подключенные к ним одноименные выходы двух ядер МПЦ. Структура связи этих контроллеров позволяет наращивать и модернизировать МПЦ при возникновении такой необходимости.

Непосредственное управление стрелками осуществляется стандартными релейными схемами на основе реле I-класса надежности. При управлении выходными и маневровыми светофорами используются релейные схемы, построенные по принципам штатной системы ЭЦ МПЦ «iпуть».

Объектами контроля являются:

· огневые реле;

· реле контроля состояния переезда;

· реле контроля положения стрелок;

· реле контроля стрелочных и путевых участков.

Ввод информации осуществляется посредством полных контактных тройников вышеперечисленных реле через блоки ТС16Б.

МПЦ комплектуется резервируемой системой управления и визуализации на базе компьютеров с клавиатурами и мониторами. В помещении ДСП устанавливаются основной и резервной АРМ ДСП, при этом резервный АРМ ДСП находится в «холодном» резерве. Информация о поездной ситуации в пределах станции и с прилегающих перегонов поступает от существующих рельсовых цепей.

3. Алгоритмы работы ЯДРА МПЦ «Iпуть»

Алгоритмы работы МПЦ «iпуть» основаны на алгоритмах работы существующей системы МРЦ-13, т.к. безопасность и безотказность алгоритмов работы МРЦ находится на высоком уровне и в следствии длительного периода использования они полностью прошли опытную эксплуатацию.

Далее будут приведены алгоритмы работы МПЦ на которых основана работа и для сравнения приведен граф состояний системы МПЦ при установке поездного маршрута.

На рисунке 3.1 приведен алгоритм установки маршрута в системе МРЦ.

Рисунок 3.1 - Алгоритм установки маршрута в МПЦ

На рисунке 3.2 представлен граф состояний с указанием условий переходя из одного состояния в другое.

Рисунок 3.2 - Граф состояний системы МПЦ при установке поездного маршрута.

3.1 Алгоритмическая структура МПЦ

МПЦ состоит из двух независимо работающих, от питания до рабочих реле, системах управления и контроля (полный резерв).

На рисунке 3.3 представлена структурная схема комплекта системы МПЦ.

Рисунок 3.3 - Структурная схема комплекта системы МПЦ

В состав МПЦ входят:

· ядро системы на базе четырех блоков в промышленном исполнении (по два

на каждую из параллельных систем);

· технологический блок (АРМ ШН, архив, протокол, проектируемая внешняя связь) на базе четырех системных блоков в промышленном исполнении (по два на каждую из параллельных систем);

· АРМ ДСП на базе двух системных блоков в промышленном исполнении;

· технологическое оборудование (консольный коммутатор, сетевой концентратор, источники питания, 19” стойки, стативы МПЦ).

Управление МПЦ осуществляется с автоматизированного рабочего места дежурного по станции (АРМ ДСП).

Работа МПЦ контролируется по отображению состояния объектов на дисплее АРМ ДСП, управление осуществляется ДСП через узлы управления АРМ (клавиатура, манипулятор мышь). Команды ДСП, приказы ядра системы, состояния объектов регистрируются в журналах и архивах на технологических компьютерах МПЦ.

Диагностика МПЦ и контроль технических параметров осуществляется с автоматизированного рабочего места электромеханика (АРМ ШН). Этот же АРМ позволяет анализировать протокол действий дежурного по станции и в целом работы МПЦ.

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

Оба компьютера через петли связи по протоколу RS-485 стыкуются с рабочими контроллерами (блоки ТУ, ТС). Главная цель ядра МПЦ состоит в обработке данных таким образом, чтобы обеспечить выполнение всех взаимозависимостей безопасным способом.

3.2 Технические характеристики МПЦ

Централизованное управление технологическим процессом на станции обеспечивается возможностью совмещения в одном комплексе технологических функций ЭЦ, связи с объектом и связи с оперативно-техническим персоналом (автоматизированное рабочее место дежурного по станции - АРМ ДСП, автоматизированное рабочее место электромеханика СЦБ - АРМ ШН). Организация связи с объектами управления и контроля позволяет обеспечить до 16 контролируемых дискретных входов на один модуль ввода и до 8 управляемых дискретных выходов на один модуль вывода.

Контролируемые параметры могут являться дискретной информацией, принимающей значения «0» или «1».

Электропитание осуществляется от собственной системы бесперебойного гарантированного электропитания.

Основные технические характеристики приведены в таблице 3.1.

Таблица 3.1 - Основные технические характеристики МПЦ

Наименование параметра	Значение параметра
Количество станций	1
Количество автоматизированных рабочих мест	2
Тип системы безопасности	2+2
Тип системы управления	централизованное
Время цикла выполнения программы	320 мс
Климатическое исполнение	УХЛ4
Устойчивость к климатическим воздействиям	К1
Воздействие электромагнитных помех	степень жесткости 3
Качество функционирования	А
Напряжение электропитания	220 В, 50 Гц
Количество стрелок	до 80

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

Предусматриваемый срок службы МПЦ - 20 лет (при условии проведения технического обслуживания и восстановительных работ).

3.3 Характеристика ПМО МПЦ

Как было сказано ранее МПЦ состоит из двух управляющих комплектов. Каждый управляющий комплект состоит из нескольких уровней программно аппаратных средств. Отказ или сбой любого компонента может повлечь переход всего комплекта в защитное состояние. Технические параметры ядра МПЦ приведены в таблице 3.2.

Таблица 3.2 - Технические параметры ядра МПЦ приведены в таблице.

Параметры	Описание
Конфигурация	Дублированная система с горячим резервом
Центральный процессор	VIA C3 Processor bis 800 MHz
Операционная система	Windows XP/Linux
Язык программирования	С++
Производительность	Цикл реализации команды 0.5 с.
Надежность	Наработка на отказ: -блока питания 250 000 ч. -комплектующих 100 000 ч.
Безопасность	Уровень 4 по IEC 61508, EN 50126
Протоколы связи	TCP/IP, RS-485
Скорость передачи	155 200 бит/с
Потребляемая мощность	250 тт

3.4 Структурная схема ПМО МПЦ

На рисунке 3.3 представлена укрупненная схема одного комплекта системы МПЦ.

Ядро системы МПЦ работает на серверах под управлением операционной системы Windows. Рассмотрим функционирование сервера МПЦ. Взаимодействие с другими уровнями и структурная схема сервера МПЦ показана на рисунке 3.3.

Рисунок 3.3 - Структурная схема ПМО МПЦ.

Сервер представляет собой ЭВМ, организовывающую логику взаимодействия согласно логике ЭЦ. Общение с уровнем АРМ'а и с уровнем УСО физически осуществляется через локальную сеть нижнего уровня. Процесс обмена информацией происходит через массивы памяти М1 и М2. Эти массивы физически находятся в одном кристалле ОЗУ для более эффективного контроля его состояния, а логические связи организованы таким образом, что система АРМ имеет доступ только к массиву М2, а УСО - у массиву М1. Это позволяет исключить прямые воздействия, минуя ПО сервера МПЦ.

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

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

4. Характеристика Станции СоЖ

4.1 Общая характеристика станции Сож

Станция Сож является промежуточным раздельным пунктом Гомельского узла, оборудованным устройствами диспетчерской централизации. Станция Сож работает в режиме автономного управления.

В централизацию станции Сож включены:

· стрелок - 15,

· сбрасывающих остряков - 1,

· светофоров - 24, из них: поездных - 15,маневровых - 9.

Устройствами АЛСН оборудованы IП, IIП, 4П, 6П пути.

Контроль наличия переменного тока, исправности ламп переездных светофоров и посылки извещения подается к ДСП ст. Сож.

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

Станция оборудована парковой связью громкоговорящего оповещения (ПСГО), а также всеми необходимыми видами радио и проводной связи.

4.2 Характеристика устройств СЦБ

К станции Сож примыкают:

· однопутный перегон Ипуть - Сож;

· однопутный перегон Сож - Костюковка;

· однопутный перегон Сож - Светоч.

В состав МПЦ входят:

Однопутный перегон Ипуть- Сож оборудован релейной полуавтоматической блокировкой. На перегоне расположены:

– переезды 16км + 627м, 15км+ 290м, оборудованные устройствами автоматической переездной сигнализации, не обслуживаемые дежурным работником дистанции пути, контроль работы которых выведен на выносное табло ДСП ст. Сож.

– переезды 6км + 613м, 8км+161м, оборудованные устройствами автоматической переездной сигнализации, не обслуживаемые дежурным работником дистанции пути, контроль работы которых выведен на выносное табло ДСП ст. Ипуть.

Однопутный перегон Сож - Светоч оборудован кодовой автоматической блокировкой без проходных светофоров. На перегоне расположены:

– переезд 0км+874м, оборудованный устройствами автоматической переездной сигнализации, не обслуживаемые дежурным работником дистанции пути, контроль работы которых выведен на выносное табло ДСП ст. Сож;

– контрольно- габаритные устройства (КГУ-II)- контролирующий

габаритподвижного состава в поездах, пребывающих на ст. Cож . Контроль состояния КГУ выведен на выносное табло ст. Сож.

Однопутный перегон Сож - Костюковка оборудован кодовой автоматической блокировкой. На перегоне расположены:

– спаренная сигнальная точка 1/2, работа которой контролируется на выносном табло ст. Сож;

– переезд 19 км+949 м, оборудованный устройствами автоматической

переездной сигнализации, не обслуживаемый дежурным работником дистанции пути, контроль работы которого выведен на выносное табло ДСП ст. Сож;

– переезд 21 км, пересекающий кроме этого перегонного пути двухпутный

перегон Костюковка - Светоч на 206 км, оборудован автоматической переездной сигнализацией с автошлагбаумами, обслуживается дежурным работником дистанции пути. Контроль работы этого переезда выведен на пульт-табло ДСП ст. Костюковка;

– контрольно-габаритные устройства (КГУ-I)- контролирующие габарит подвижного состава в поездах, прибывающих на ст. Сож. Контроль состояния КГУ выведен на выносное табло ст. Сож.

5. Разработка модели Станции СоЖ

5.1 Структура моделей

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

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

Структурная схема формата данных приведена на рисунке 5.1.

Рисунок 5.1 - Формат данных модели объекта станции

Любые переменные могут принимать значения только 0 или 1.

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

В подсистеме модель объекта представляется в виде текстовых файлов, которые хранятся на каком либо носителе информации.

Файл модели объекта состоит из трех секций - [main], [входы], [выходы].

Секция [main] описывает имя файла-модели.

Секция [входы] описывает имена входных полей, правила по которым им будут присваиваться значения и значения для присвоения в описанные поля.

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

Формат записи строки из секции [входы] следующий:

<имя_переменной>

= <тип_присвоения_значений>

= [<([!]маска_свойства1, [!]маска_свойства2, [!]маска_свойстваN)>]

= [<значение_для_присвоения>]

[= <значение_для_присвоения_по_умолчанию>];

<имя_переменной> - имя входной переменной, может содержать буквенно-цифровые символы;

<маска_свойств> - перечисленные через запятую свойства объектов, которым будут присваиваться данные значения. Если перед наименованием свойства стоит «!», то это означает, что при поиске объекта с такими свойствами в блоке первичных данных описывающих объекты станции, он не должен содержать данное свойство; если «!» не указан перед наименованием свойства, то это означает, что при поиске объектов, он должен содержать данное свойство обязательно. Если объект содержит свойтсва не указанные в маске свойств, то при поиске они будут игнорироваться. Если не указать маску свойств, то это означает, что поиск вернет все объекты текущего файла описывающего определенный объект станции;

<тип_присвоения_значений> - один из трех типов присвоения. Типы присвоения значений бывают следующие:

&ONE& - в описываемое поле может быть присвоено только одно значение,

&AND& - в описываемое поле может быть присвоено несколько значений с выполнением логической операции «И»,

&OR& - в описываемое поле может быть присвоено несколько значений с выполнением логической операции «ИЛИ»;

<значение_для_присвоения> - указывается значение для присвоения. Формат записи следующий: [.]<значение>. Символ «» означает, что в переменную будут присваиваться значение определенного состояния объектов, соответствующим маске свойств с указанным типом присвоения. Также в качестве значения может быть «0» или «1», что означает прямое присвоение;

<значение_для_присвоения_по_умолчанию> - присваивается, если не указано значение для присвоения или не найдены объекты с определенными свойствами.

Формат записи строки из секции [выходы] следующий:

[<([!]маска_свойства1, [!]маска_свойства2, [!]маска_свойстваN)>]

= [<значение_для_присвоения>]

= [<тип_присвоения_значений>]

<имя_переменной>;

В строке секции [выходы] может быть только четыре знака «=», т.е. четыре параметра. Любой параметр, кроме имени переменной можно не указывать. Если не указывать параметры, то в переменную будут присваиваться состояния всех объектов. Описание параметров полностью совпадает с описанными выше для секции [входы].

5.2 Разработка файлов описания объектов

При помощи данной блока первичной информации описываются объекты станции. Объектами могут быть маршрут, светофор, перегон, путь, секция и т.д. Сам файл также состоит из описания объектов, взаимодействующих с описываемым объектом. Т.е. если описывается объект типа «маршрут», то в блоке будут описываться стрелки, светофоры, секции, команды управления станцией. При помощи данного блока данных описывается макет станции. Все свойства объектов описываются согласно таблицы взаимозависимости стрелок, сигналов и маршрутов [3].

Структура схема файла описания объекта приведена на рисунке 5.2.

Рисунок 5.2 - Структура файла описания объекта

В файле обязательным является блок, в котором указывается файл-модель описываемого объекта; имя описываемого объекта; название, которое будет передаваться как параметр определенному вспомогательному алгоритму работы; имя вспомогательного алгоритма работы . Формат записи данных следующий:

<имя_файла_модели>:файл

<наименование_объекта>:имя

<название>:название

<имя_файла_вспомогательный_алгоритм>:скрипт

В одной строке файла не может быть описано более одного объекта.

Далее идет блок описания объектов. Формат строки описания объектов следующий:

[<наименование_объекта>]:<свойство1>[,<свойство2>,свойствоN]

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

Формат описания команды управления выглядит следующим образом:

[станция].<наименование_комманды>:<свойство1>[,<свойство2>,свойствоN]

Ключевое слово [станция] говорит подсистеме, что далее, после символа «.» следует наименование команды. Наименование команды совпадает по написанию с командами вводимыми с АРМ ДСП. В свойствах описываются действия, выполняемые данной командой.

Для парка станции Сож, уже созданы алгоритмы объектов в cxx файлах, они универсальные и могут быть использованы для любых станций по принципу БМРЦ. Для сборки модели станции необходимо создать только .prclink файлы, для всех объектов станции, таких как стрелки, секции, светофоры, маршруты.

5.3 Модель поездного маршрута

На рисунке 5.3 представлена схема маневрового маршрута М11-Ч4 , на примере которого и произведено описание задания маршрутов.

Рисунок 5.3 - Маневровый маршрут М11-Ч4

В секции «main» описано имя модели, на данное имя ссылаются описания объектов этой модели.

[main]

маршрут_m.cfg:файл

В секции «входы» описываем входные переменные и логику присвоения им значений:

[входы]

Маршрут[М11.Ч2]: // имя файла описания объекта

<<Маршрут[М11.Ч2]>>: // название объекта

lgo/cxx/route_m_fay.cxx: // имя вспомогательного алгоритма работы для данного объекта

Все выше приведенные параметры извлекаются из файлов описаний объектов.

Определяем тип маршрута:

:нечётный

:маневровый

//:отправления

Описываем все стрелки входящие в маршрут:

Стрелка[9]:стрелка,минус

Стрелка[17]:стрелка,минус

Стрелка[21]:стрелка,минус

Описываем все секции входящие в маршрут:

Секция[7СП]:секция,секция_отправления

Секция[9-13СП]:секция,первая

Секция[17-21СП]:секция,последняя

Секция[4П]:секция,секция_приёма,путь_приёма

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

Маршрут[М3.М11]:враждебный

Маршрут[М5.М11]:враждебный

Маршрут[М19.М9]:враждебный

Маршрут[М19.М13]:враждебный

Маршрут[М13.М3]:враждебный

Маршрут[М13.М5]:враждебный

Маршрут[Ч1.М13]:враждебный

Маршрут[Ч2.М13]:враждебный

Маршрут[Ч3.М13]:враждебный

Маршрут[Ч4.М13]:враждебный

Маршрут[Ч5.М13]:враждебный

Маршрут[Ч6.М13]:враждебный

Маршрут[Ч1.Н]:враждебный

Маршрут[Ч2.Н]:враждебный

Маршрут[Ч3.Н]:враждебный

Маршрут[Ч4.Н]:враждебный

Маршрут[Ч5.Н]:враждебный

Маршрут[Ч6.Н]:враждебный

Маршрут[Н.Ч1]:враждебный

Маршрут[Н.Ч2]:враждебный

Маршрут[Н.Ч3]:враждебный

Маршрут[Н.Ч4]:враждебный

Маршрут[Н.Ч5]:враждебный

Маршрут[Н.Ч6]:враждебный

Маршрут_пригласительный[Н.Ч1]:враждебный

Маршрут_пригласительный[Н.Ч2]:враждебный

Маршрут_пригласительный[Н.Ч3]:враждебный

Маршрут_пригласительный[Н.Ч4]:враждебный

Маршрут_пригласительный[Н.Ч5]:враждебный

Маршрут_пригласительный[Н.Ч6]:враждебный

Маршрут[Чк.Н4]:враждебный

Маршрут[Чс.Н4]:враждебный

Маршрут_пригласительный[Чк.Н4]:враждебный

Маршрут_пригласительный[Чс.Н4]:враждебный

В следующей секции «выходы» происходит формирование посылки команды «установка маршрута» или «отмена маршрута» а также их подтверждение:

[выходы]

[станция].УММ.М11.Ч2:команда

[станция].ОТ.М11:команда,отмена

[станция].УММ.М11.Ч2_ПОДТВ:арм_подтв

[станция].ОТ.М11_ПОДТВ:отмена_арм_подтв

Файлы стрелок для сборки модели станции в количестве 15 штук приведены в приложении А.

Файлы секций для сборки модели станции в количестве 18 штук приведены в приложении Б.

Файлы светофоров для сборки модели станции в количестве 27 штук приведены в приложении В.

Файлы маршрутов для сборки модели станции в количестве 93 штук приведены в приложении Г.

6. Расчет экономического эффекта

6.1 Основные положения расчёта стоимости программного обеспечения

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

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

Программное обеспечение как товарная продукция могут быть двух видов:

– научно-техническая продукция;

– продукция производственно-технического назначения.

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

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

Расчет экономического эффекта ПО основан на принципах “Комплексной оценки эффективности мероприятий, направленных на ускорение научно-технического прогресса”. Экономический эффект может определяться как у разработчика, так и у пользователя.

У разработчика экономический эффект выступает в виде чистой прибыли, остающейся в распоряжении предприятия от реализации ПО, а у пользователя - в виде экономии трудовых, материальных и финансовых ресурсов, получаемой от:

– снижения трудоемкости расчетов, алгоритмизации программирования и отладки программ (задач) за счет использования ПО в процессе разработки автоматизированных систем и систем обработки данных;

– сокращения расходов на оплату машинного времени и других ресурсов на отладку задач;

– снижения расходов на материалы (магнитные, лазерные диски и прочие материалы);

– ускорения ввода в эксплуатацию новых систем;

– улучшения показателей основной деятельности предприятий в результате использования ПО.

Стоимостная оценка ПО у разработчиков предполагает составление сметы затрат, которая включает следующие статьи:

– затраты на материалы;

– спецоборудование;

– заработная плата исполнителей основная и дополнительная;

– отчисления в фонд социальной защиты населения;

– налоги, входящие в себестоимость ПО;

– машинное время;

– расходы на научные командировки;

– прочие расходы;

– накладные расходы.

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

6.2 Исходные данные

Разработка программных средств (ПС) предусматривает проведение всех стадий проектирования (техническое задание, эскизный проект, технический проект, рабочий проект, внедрение) и относится к 3-й группе сложности. По степени новизны ПС относится к группе «А» с коэффициентом 1,0.

Расчет производится на основе исходных данных, представленных в таблице 6.1.

Таблица 6.1 - Исходные данные

Наименование показателей	Буквенные обозначения	Единицы измерения	Количество
Коэффициент новизны	kн	единиц	1,0
Группа сложности		единиц	3
Дополнительный коэффициент сложности	kсл	единиц	0,18
Поправочный коэффициент, учитывающий использование типовых программ	kт	единиц	0,9
Установленная плановая продолжительность разработки	Tр	лет	0,1
Годовой эффективный фонд времени	Фэф	дней	255
Продолжительность рабочего дня	Tч	ч	8
Тарифная ставка 1-го разряда	Tм1	руб.	75000
Коэффициент премирования	kп	единиц	1,4
Норматив дополнительной заработной платы	Hзд	%	10
Ставка отчислений в фонд социальной защиты населения	Hзсз	%	34
Норматив прочих затрат	Hпз	%	3
Норматив на сопровождение и адаптацию ПО	Hрса	%	10
Ставка налога на добавленную стоимость	Hдс	%	18
Первоначальная стоимость используемых основных фондов	ПО	Руб.	500 000
Норматив амортизации ВТ	На	%	12,5

В выполнении работ задействованы:

– руководитель дипломного проекта;

– студент-дипломник;

Приравняем руководителя дипломного проекта к должности начальник отдела. Присвоим ему 13 разряд, установим продолжительность участия в разработке - 20 дней. Тарифный коэффициент - 3,98;

Приравняем студента-дипломника к должности инженера-программиста без категории. Присвоим ему 9 разряд, установим продолжительность участия в разработке 20 дней. Тарифный коэффициент - 2,48.

6.3 Определение объема программного обеспечения

Объем ПО определяется путем подбора аналогов на основании классификации типов ПО, каталога функций ПО и каталога аналогов ПО в разрезе функций, которые постоянно обновляются и утверждаются в установленном порядке. На основании информации о функциях разрабатываемой САО, по каталогу функций определяется объем функций. Затем по каталогу аналогов в разрезе функций уточняется объем функций. На основании этих данных составлена таблица 5.2.

Таблица 6.2 - Объём программного обеспечения

Номер Функции	Содержание функций	Объем (условных машинных команд)
109	Организация ввода / вывода информации в интерактивном режиме	109
203	Формирование базы данных	626
204	Обработка наборов и записей базы данных	790
305	Обработка файлов	367
309	Формирование файла	740
403	Формирование служебных таблиц	369
503	Управление внешними устройствами и объектами	1456
506	Обработка ошибочных и сбойных ситуаций	520
507	Обеспечение интерфейса между компонентами	686
604	Справка и обучение	445
703	Расчет показателей	263
707	Графический вывод результатов	203
Итого:	6574

Общий объем ПО рассчитывается по формуле:

, (6.1)

где - общий объем ПО, условных машинных команд;

- объем функций ПО, условных машинных команд;

- общее число функций.

6.4 Расчёт трудоёмкости ПО

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

С учетом дополнительного коэффициента сложности kсл (см. таблицу 5.1) рассчитывается общая трудоемкость ПО.

, (6.2)

где То - общая трудоемкость ПО, человеко-дней;

Тн - нормативная трудоемкость ПО, человеко-дней;

kсл - дополнительный коэффициент сложности ПО.

Объему в 6574 условных машинных команд (3-я группа сложности ПО) соответствует нормативная трудоемкость 60 человеко-дней. По формуле (6.2) определим общую трудоемкость ПО:

человеко-дня.

При решении сложных задач с длительным периодом разработки ПО трудоемкость определяется по стадиям разработки (техническое задание - ТЗ, эскизный проект - ЭП, технический проект - ТП, рабочий проект - РП и внедрение - ВН) с учетом новизны, степени использования типовых программ и удельного веса трудоемкости стадий разработки ПО в общей трудоемкости разработки ПО. При этом на основании общей трудоемкости рассчитывается уточненная трудоемкость с учетом распределения по стадиям

, (6.3)

где Ту - уточненная трудоемкость ПО, человеко-дней;

Тi - трудоемкость разработки ПО на i-й стадии, человеко-дней;

m - количество стадий разработки.

Трудоемкость ПО по стадиям определяется с учетом новизны и степени использования в разработке типовых программ и ПО

Тстi = dстi•kн•kт•То, (6.4)

где Tстi - трудоемкость разработки ПО на i-й стадии (технического задания, эскизного проекта, технического проекта, рабочего проекта и внедрения), человеко-дней;

kн - поправочный коэффициент, учитывающий степень новизны ПО;

kт- поправочный коэффициент, учитывающий степень использования в разработке типовых программ и ПО;

dстi - удельный вес трудоемкости i-й стадии разработки ПО в общей

трудоемкости ПО.

На основании уточненной трудоемкости разработки ПО и установленного периода разработки рассчитывается общая плановая численность разработчиков ПО:

(6.5)

где Чр - плановая численность разработчиков, чел.;

Фэф - годовой эффективный фонд времени работы одного работника в течение года, дней в год;

Tр - плановая продолжительность разработки ПО, лет.

По формуле определим уточненную трудоемкость на стадии рабочего проекта

человеко-дней.

Например, по формуле (6.5) определим общую плановую численность разработчиков на стадии рабочего проекта

чел.

Результаты расчетов уточненной трудоемкости и общей плановой численности разработчиков на разных стадиях разработки по формулам (6.5) и представлены в таблице 6.3.

Таблица 6.3 - Результаты расчетов трудоемкости

	Стадии разработки	Итого
	ТЗ	ЭП	ТП	РП	ВН
Коэффициенты удельных весов трудоемкости стадий, dстi	0,11	0,09	0,11	0,55	0,14	1,0
Коэффициенты, учитывающие использование типовых программ, kт	-	-	-	0,9	-	-
Коэффициенты новизны, kн	1,0	1,0	1,0	1,0	1,0	-
Уточняющая трудоемкость Tу стадий, человеко-дней	7,79	6,37	7,79	35,05	9,91	66,91
Численность Чр исполнителей, чел.	2,35	2,5	2,35	2,81