Описание предметной области. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ДЛЯ ПРОВЕДЕНИЯ ЛАБОРАТОРНЫХ ЗАНЯТИЙ по учебной дисциплине Компьютерные технологии управления в технических

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

Обсуждено на заседании кафедры ПОУТС

Протокол № _1_ от « 31 » августа 2011 г.

Самара

Методические указания

К лабораторным работам 1-12

по курсу «Компьютерные технологии автоматизации и управления»

Моделирование работы ЛВС у СТС и алгоритмов управления сетью при наличии неисправностей.

Версия 6

Цель работы:

Изучить логику работы сети по ГОСТ Р 52070 – 2003 ( MIL STD 1553 B), получившей широкое распространение при управлении СТС. Разработать алгоритм защиты сети по MILSTD 1553B, размещаемый в ПО контроллера, обеспечивающий автоматическое без участия оператора обнаружение нештатных ситуаций и восстановление работоспособности сети при:

а) отсутствии ответного слова от ОУ,

б) «генерации» помехи – непрерывной передачи отказавшего ОУ, блокирующей работу сети с топологией «шина»,

в) занятости абонента,

г) ситуации «сбоя» ОУ.

Запрограммировать разработанные алгоритмы, проверить их работоспособность путем проведения имитационного моделирование ЛВС с имитацией рассмотренных неисправностей узлов ЛВС.

Общие требования

1.Данные отказы и сбои могут проявляться в любом из ОУ или абонентов сети.

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

3.Должен быть также составлен алгоритм “Тест”, проверяющий работоспособность сети перед началом или в процессе ее работы.

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

5.Модель должна позволять генерировать сообщения на любое заданное оконечное устройство и имитировать отказы и сбои любого из них или любого из абонентов сети. Эти отказы и сбои задаются в специальной «Таблице состояний узлов сети».

Модель должна также имитировать нормальный обмен контроллера и ОУ.

6.Модель должна имитировать текущее время .

7.Модель должна имитировать получение сообщений и ответных слов.

8.Модель и алгоритмы защиты должны пройти отладку.

9.Модель сети должна отображать процесс прохождения сообщений мультимедийно.

Алгоритмы управления передачей сообщений по сети

1.Алгоритмы управления работой сети в нештатных ситуациях (прикладного уровня - исполняются из ЦВМ контроллера сети):

а) «тест» (команда «дай ответное слово» трем или всем абонентам),

б) обнаружение «генерации»(нет ответных слов от всех опрошенных абонентов на данной ЛПИ),

в) обнаружение «генерящего ОУ» и его блокировки,

г) управления передачей при отсутствии ответного слова,

д) управления передачей при получении в ответном слове «абонент занят».

2. Алгоритм моделирования прохождения сообщений в сети. Число ОУ в сети задается любым из диапазона 1-31.Состояние ОУ задается любым из таблицы состояний для каждой из дублированных ЛПИ А или В.

3. Алгоритм моделирования текущего времени.

t:=t + длительность операции + пауза между сообщениями.

4. Алгоритм мультимедийного представления результатов с обозначением результатов работы каждого из ОУ сети и проверки соответствия полученных результатов таблице неисправностей

5. Алгоритм вывода пошаговой информации о работе сети – «лога». Выводится каждая команда контроллера и реакция на неё соответствующего ОУ в соответствии с алгоритмами 1 а),б), в), г),д).

Требования к интерфейсу с пользователем

1. Интерфейс должен позволять вводить исходные данные для моделирования в удобной форме. Задание состояния каждого ОУ сети должно отображаться в графическом виде по каналам А и В.

2. Интерфейс должен представлять результаты моделирования в двух видах:

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

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

3. Интерфейс должен позволять проводить сравнение заданных состояний ОУ и их состояний , обнаруженных в процессе моделирования.

4.Интерфейс должен позволять менять темп вывода на экран результатов моделирования.

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

Состав и сроки проведения лабораторных работ

1.Работа N1-2.

Провести анализ предметной области. Определить перечень алгоритмов управления сетью в нештатных ситуациях. Срок-2 неделя

2.Работа№3-4.

Определение алгоритмов обнаружения нештатных ситуаций ЛВС. Определения алгоритмов управления сетью в обнаруженных нештатных ситуациях. Разработать и представить укрупненные блок-схемы алгоритмов обнаружения нештатных ситуаций и управления в сети при наличии неисправностей ОУ. Срок-3 неделя

3.Работа N5-6

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

Срок -4 неделя

4. Работа N7-8

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

Срок - 7неделя

5. Работа N9-10

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

6. Работа № 11-12

Провести моделирование. Подготовить результаты и представить индивидуальные отчеты. Подготовить отчеты по подгруппам. Срок – 12 неделя

Итоговый отчет должен содержать:

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

б) Отчет – листинг о проведенных обменах с представлением «лога».

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

г) Листинг программы, с отображением разработанного фрагмента

Таблица команд контроллера.

ПРИЛОЖЕНИЕ 1

Описание предметной области.

В настоящее время управляющая локальная вычислительная сеть является системообразующим элементом СТС. Рассмотрим типовую схему системы управления с ЦВМ в качестве устройства управления.

ЛВС системообразующий элемент СТС

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

Современная реализация этой схемы содержит периферийные ЦВМ, встроенные в исполнительные органы и датчики.

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

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

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

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

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

ЛПИ ЛВС имеет шинную топологию. Доступ абонентов на ЛПИ– последовательный централизованный.

Рассматриваемая локальная сеть состоит из N приборов, оснащенных встроенными компьютерами, имеющих оконечные устройства (ОУ), связанные с контроллером (К) линией передачи информации (ЛПИ). Передача информации в сети идет последовательными кодовыми посылками. Длина одного слова сообщения – 20 бит. Максимальное количество слов в сообщении - 33 слова (1 командное и 32 информационных). Минимальная длина сообщения – 1 командное слово.

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

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

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

Передача сообщений от контроллера идет с информационной обратной связью (ИОС), т.е. получив команду или данные, ОУ посылает контроллеру «ответное слово», имеющее смысл «квитанции о получении» сообщения. Если за заданное время 4-12 мкс после завершения передачи сообщения ответное слово в К не пришло, то это означает, что сообщение не передано. В этом случае, уже на системном уровне необходимо принять решение, что делать дальше. В стандарте протокола эти действия не описаны.

Например, контроллер повторяет передачу. После того как контроллер два раза подряд повторил передачу и не получил ответного слова, он может переходить на передачу сообщения в данное ОУ по резервной линии. Если передача шла по А, то он переходит на В, если передача шла по В, то он переходит на А. Такую логику можно заложить в ПО ЦВМ контроллера. Возможна и другая логика действий при сбоях и отказах, приводящих к неполучению ответного слова в К, - вызов программы «аварийной защиты», либо игнорирования ситуации отсутствия обмена с одним из ОУ и продолжение работы с другими ОУ. Все зависит от особенностей системы, которая образует сеть. Логика защиты программируется в ЦВМ контроллера на прикладном уровне.

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

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

Если ОУ не получил от абонента информацию и не готов её передать в контроллер в ответ на команду «дай информацию», то он в ответ на команду К в ответном слове ОУ сообщит признак «абонент занят» и информацию не передает. Реакция К на эту ситуацию в стандарте не зафиксирована и ее надо организовывать на программном уровне К. Например, по этому признаку контроллером выполняется та же логика с повторением обменов по А и по В.

Но в случае однократного не прохождения обмена по биту «Абонент занят», аварийная защита К обычно не вызывается. Признак «Абонент занят» штатно снимается ОУ через 5 мс по мере подготовки информации абонентом.

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

Передача сообщений (команд и данных) может идти от «К» по ЛПИ А или по ЛПИ В, в том случае, когда соответствующие ЛПИ и полукомплекты ОУ исправны. Передача сообщений начинается всегда с попытки его выдачи по ЛПИ А (по умолчанию).

Самое неприятное в данной шинной организации сети, что «ОУi» могут «загенерить» (перейти в режим «Г») – передавать в канал ЛПИj***, по которому идет работа, непрерывный сигнал в течение времени ≥ 800* мксек. Эта ситуация аварийная для сети в целом, так как при этом полезные сообщения от «К» ни к одному из «ОУ» в канале А или В, в котором имеется генерация не будут проходить, так же как и «К» не будет получать ответных слов от ОУ.

Для борьбы с такой ситуацией предусмотрен механизм блокировки и разблокировки ОУi. Она возможна при передаче из К по линии свободной от генерации (А при генерации в В, либо в В при генерации в А) специальных команд на ОУi «разблокировать» или «заблокировать» передатчик в ОУi другого канала в нашем случае В или А, где есть генерация. Но для этого надо определить, где на ЛПИ А или ЛПИ В имеется генерация и найти генерящий ОУ.

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

Примечания:

*) 700 мксек – максимально возможная длина штатного сообщения (с ответным словом).

**) Устройства интерфейса – контроллер или ОУ.

***)j = А, В; i ≤ 32

Анализ предметной области

Для каждого ОУ сети можно определить таблицу состояний, в котором оно может находиться. Исходные данные моделирования помещаются в эту таблицу по каждому ОУ. См. таблицу №4.

Для того, чтобы заблокировать передатчик генерящего ОУi и открыть, таким образом, канал ЛПИ для работы с другими ОУ, номера которых не равны i, необходимо определить какой же ОУ и на какой линии «генерит». Этот алгоритм должен исполняться из ЦВМ контроллера. Возможный пример такого алгоритма приведен ниже.

Если контроллер «К» пытается передать (поочередно) сообщение в несколько ОУm, ОУm+1, ОУm+l … по одной из ЛПИ и у него это не получается ни с одним из них, то это следствие либо генерации на ЛПИ, либо обрыва ЛПИ сразу за «К», либо неисправности самого К на данной ЛПИ. Во всех этих случаях контроллер должен попробовать перейти на передачу текущего сообщения по другой ЛПИ. Однако, просто успешная передача сообщения по дублирующей ЛПИ в случае наличия «генерации» представляется недостаточной, так как выход из работы целиком ЛПИ А или В резко ухудшает надежность работы системы. Действительно, любой отказ полукомплекта ОУi (канала А или В ОУi) на действующей ЛПИ не позволяет использовать исправный второй полукомплект ОУi на другой ЛПИ, так как эта другая ЛПИ целиком неисправна – выведена из строя генерящим ОУ. Операцию последовательного обращения к ОУ с простой командой типа «дай ответное слово», позволяющую обнаружить неработоспособность целиком ЛПИ А и В, будем называть «тест» МКО. При проведении теста МКО прекращается передача штатных сообщений по линии.

После того как обнаружена «генерация» на ЛПИ – ни один из ОУ не отвечает, для поиска генерящего ОУ необходимо заблокировать все ОУ командой «Блокировка» на генерящей ЛПИ. Затем поочередно разблокировать каждое ОУ и попытаться провести с ним обмен. Если обмен на генерящей ЛПИ с текущим разблокированным ОУ не проходит – значит он «генератор». Можно реализовать другой алгоритм: блокировать ОУ поочередно и и проводить каждый раз «тест» . Тот ОУ после блокировки которого «тест» проходит и будет генерящим.

Таким образом, для обеспечения высокой надежности передачи в ПО ЦВМ «К» необходимо иметь три описанных алгоритма, реализуемых как системные в ПО ЦВМ «К»:

1) алгоритм перехода на дублирующую линию при наличии отказов ОУ;

2) алгоритм распознавания отказа или сбоя;

3) алгоритм теста МКО для обнаружения генерации на ЛПИ А или ЛПИ В;

4) алгоритм поиска генерящего ОУ на обнаруженной линии с генерацией и его блокировка.

12
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• Далее ⇒