Дипломная (вкр): Программный комплекс моделирования релейно-контактных схем

В Multisim предусмотрено множество режимов анализа данных эмуляции, от простых до самых сложных, в том числе и вложенных. Основные виды анализа:

1.      DC - анализ цепи на постоянном токе. Анализ цепей на постоянном токе осуществляется для резистивных схем. Это правило следует напрямую из теории электрических цепей; при анализе на постоянном токе конденсаторы заменяют разрывом, катушки индуктивности - коротким замыканием, нелинейные компоненты, такие как диоды и транзисторы, заменяют их сопротивлением постоянному току в рабочей точке. Анализ цепи на постоянном токе выявляет узловые потенциалы исследуемой схемы.

.        АС - анализ цепи на переменном токе. Анализ цепей на переменном токе заключается в построении частотных характеристик.

.        Transient - анализ переходных процессов. Анализ переходных процессов в цепях позволяет определить форму выходного сигнала, то есть построить график сигнала как функции времени.

Кроме встроенных функций анализа есть возможность определить свою функцию с помощью команд SPICE. При подготовке к анализу необходимо настроить его параметры, например, диапазон частот для анализатора переменного тока (AC analysis). Необходимо также выбрать выходные каналы (traces). Плоттер (Grapher) - основной инструмент просмотра результатов эмуляции. Он открывается из меню View/Grapher и автоматически при работе эмуляции. Множество настроек плоттера находятся в окне свойств. Например, можно изменять масштабы, диапазоны, заголовки, стили линий осей [5].

При моделировании схем необходимо соблюдать следующие общие правила:

.        Любая схема должна обязательно содержать хотя бы один символ заземления.

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

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

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

Это один из примеров, почему не стоит использовать данную среду в нашей работе. Другой пример состоит в том, что, как и в случае с Electronics Workbench, невозможно собрать такую схему, чтобы она имитировала действие всех защит из-за специфичного оборудования. Как упоминалось выше - есть случаи интеграции цифровых защит (которых, кстати, нет в базе данных Multisim) с релейными. Таков второй недостаток среды разработки и тестирования электронных схем Multisim. Третьим немаловажным недостатком ее является цена. За базовую версию, в которой не поддерживается большое количество функций, придется заплатить почти 2000 долларов, что является очень большой суммой. Pro-версия, со всеми функциями, стоит 5000 долларов. Она стоит своих денег, но не удовлетворяет потребности в моделировании схем релейных защит и автоматики железнодорожного транспорта. Также в Multisim есть функции, которые в принципе не требуются в РЗА (импульсные источники питания, мгновенное измерение параметров цепи, таких, как ток и напряжение и иные) и большое количество электронных элементов, которые также не используются в составлении наших схем (транзисторы, тиристоры и так далее). Учитывая все эти недостатки можно с уверенностью сказать, что среда разработки и тестирования электронных схем Multisim для нашей работы не подходит.

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

2. РАЗРАБОТКА ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ И ПОСТАНОВКА ЗАДАЧ ДИПЛОМНОГО ПРОЕКТИРОВАНИЯ

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

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

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

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

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

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

3. АРХИТЕКТУРА ПРОГРАММЫ

Информационная система (ИС) - система, предназначенная для хранения, поиска и обработки информациии соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015).

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

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

Более узкое понимание информационной системы ограничивает её состав данными, программами и аппаратным обеспечением. Интеграция этих компонентов позволяет автоматизировать процессы управления информацией и целенаправленной деятельности конечных пользователей, направленной на получение, модификацию и хранение информации. Так, российский стандарт ГОСТ РВ 51987 подразумевает под ИС «автоматизированную систему, результатом функционирования которой является представление выходной информации для последующего использования». ГОСТ Р 53622-2009 использует термин информационно-вычислительная система для обозначения совокупности данных (или баз данных, систем управления базами данных и прикладных программ, функционирующих на вычислительных средствах как единое целое для решения определенных задач.

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

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

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

Концепция MVC позволяет разделить данные (модель), представление и обработку действий (производимую контроллером) пользователя на три отдельных компонента:

.        Модель. Предоставляет знания: данные и методы работы с этими данными; реагирует на запросы, изменяя своё состояние; не содержит информации, как эти знания можно визуализировать.

.        Представление, вид - отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.

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

.        Важно отметить, что как представление, так и контроллер зависят от модели; однако модель (активная) не зависит ни от представления, ни от контроллера. Тем самым достигается назначение такого разделения: оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.

Для реализации схемы «Model-View-Controller» используется достаточно большое число шаблонов редактирования (в зависимости от сложности архитектурного решения), основные из которых - «наблюдатель», «стратегия», «компоновщик.

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

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

Для возможности однотипного обращения с подобъектами сложно-составного иерархического вида - может использоваться шаблон «компоновщик». Кроме того, могут использоваться и другие шаблоны проектирования - например, «фабричный метод <https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B1%D1%80%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4_%28%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%29>», который позволит задать по умолчанию тип контроллера для соответствующего вида. Схема концепции показана на рисунке 3.1.

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

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

Рисунок 3.2 - Примерная модель программного комплекса

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