МАГ КТАУ ЛАБ.управл.лвс1553 в6

Федеральное государственное образовательное бюджетное учреждение высшего
профессионального образования
«Поволжский государственный университет телекоммуникаций и информатики»
Кафедра «Программное обеспечение и управление в технических системах»


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

по учебной дисциплине
Компьютерные технологии управления в технических системах

наименование учебной дисциплины (полное, сокращенное)




Для специальности 220400 – Управление в технических системах


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






Обсуждено на заседании кафедры ПОУТС
Протокол № _1_ от « 31 » августа 2011 г.





Самара
2012






Методические указания
к лабораторным работам 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.
г) Листинг программы, с отображением разработанного фрагмента

Таблица команд контроллера.
Тип сообщения
№ ОУ
Тип команды
Примечание

«Дай ОС»
. . .
Короткая

20+12+20=52мксек

«Дай данные»

Короткая или длинная

20+12+32x20=672 мксек длинная

Команда разблокировать

Короткая
20+12+20 = 52мксек

Команда заблокировать

Короткая
20+12+20 = 52 мксек

Команда «На данные»

Короткая или Длинная
672 мксек – длинная
52 мксек - короткая


ПРИЛОЖЕНИЕ 1
Описание предметной области.
В настоящее время управляющая локальная вычислительная сеть является системообразующим элементом СТС. Рассмотрим типовую схему системы управления с ЦВМ в качестве устройства управления.
ЛВС системообразующий элемент СТС

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










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

13 SHAPE \* MERGEFORMAT 1415

С учетом того, что ПО ЦВМ сети в совокупности определяет алгоритм функционирования системы и эффективность решения ею целевых задач подобная управляющая вычислительная сеть является системообразующим элементом СТС.
Для системной управляющей ЦВМ также иногда применяют логическое разделение вычислительных ресурсов между несколькими ЦВМ, что связанно с нехваткой производительности одной ЦВМ и необходимостью её масштабирования.
ЛПИ ЛВС имеет шинную топологию. Доступ абонентов на ЛПИ– последовательный централизованный.
Рассматриваемая локальная сеть состоит из N приборов, оснащенных встроенными компьютерами, имеющих оконечные устройства (ОУ), связанные с контроллером (К) линией передачи информации (ЛПИ). Передача информации в сети идет последовательными кодовыми посылками. Длина одного слова сообщения – 20 бит. Максимальное количество слов в сообщении - 33 слова (1 командное и 32 информационных). Минимальная длина сообщения – 1 командное слово.
На ЛПИ активный только контроллер (он встроен в ведущую ЦВМ сети), так как только он может передавать на ОУ сообщения (данные и команды) или запрашивать данные с ОУ. ОУ без команды К в линию информацию не передает, запросов не посылает и в этом смысле являются пассивными (подчиненными).
Передача сообщений от «К» к «ОУ» идет по адресу ОУ. За каждым ОУ стоит встроенный в прибор компьютер, который будем называть «абонент». Однако ,при желании ОУ может попросить разрешения на передачу сообщения – «поднять руку». Если К это увидит, то в его воле разрешить эту передачу или нет. Просмотр контроллером наличия запросов на передачу от ОУ необходимо специально организовать
Контроллер, ОУ и ЛПИ для надежности исходно дублированы - состоят из двух полукомплектов – полукомплект А и полукомплект В. В этом отличие данной ЛВС от других ,где дублирование можно организовать ,но исходно его в протоколе сети нет. Благодаря этому, в данной ЛВС можно построить эффективную защиту от атаки на доступность за счет использования специальных команд К.
Передача сообщений от контроллера идет с информационной обратной связью (ИОС), т.е. получив команду или данные, ОУ посылает контроллеру «ответное слово», имеющее смысл «квитанции о получении» сообщения. Если за заданное время 4-12 мкс после завершения передачи сообщения ответное слово в К не пришло, то это означает, что сообщение не передано. В этом случае, уже на системном уровне необходимо принять решение, что делать дальше. В стандарте протокола эти действия не описаны.
Например, контроллер повторяет передачу. После того как контроллер два раза подряд повторил передачу и не получил ответного слова, он может переходить на передачу сообщения в данное ОУ по резервной линии. Если передача шла по А, то он переходит на В, если передача шла по В, то он переходит на А. Такую логику можно заложить в ПО ЦВМ контроллера. Возможна и другая логика действий при сбоях и отказах, приводящих к неполучению ответного слова в К, - вызов программы «аварийной защиты», либо игнорирования ситуации отсутствия обмена с одним из ОУ и продолжение работы с другими ОУ. Все зависит от особенностей системы, которая образует сеть. Логика защиты программируется в ЦВМ контроллера на прикладном уровне.
Упомянутый механизм выдачи ОУ сообщений в К по собственной инициативе заключается в том ,что ответное слово кодируется ОУ и содержит информацию о состоянии ОУ, абонента и т.п. Бит номер 11 ответного слова называется «запрос на сообщение» .Получив этот бит значением 1, контроллер понимает, что ОУ «хочет» передать сообщение и принимает решение когда получить эту информацию – выдать в ОУ команду «дай информацию».
Проблема состоит в том ,что «желание» ОУ видно контроллеру только при получении им ответного слова. Поэтому забота контроллера - получать с необходимым периодом ответные слова от ОУ. В протоколе сети существует специальная команда назовем ее «дай ответное слово», выдавая которую в соответствии с логикой ПО, контроллер может, получив ответное слово прочитать бит «запроса ОУ на сообщение».
Если ОУ не получил от абонента информацию и не готов её передать в контроллер в ответ на команду «дай информацию», то он в ответ на команду К в ответном слове ОУ сообщит признак «абонент занят» и информацию не передает. Реакция К на эту ситуацию в стандарте не зафиксирована и ее надо организовывать на программном уровне К. Например, по этому признаку контроллером выполняется та же логика с повторением обменов по А и по В.
Но в случае однократного не прохождения обмена по биту «Абонент занят», аварийная защита К обычно не вызывается. Признак «Абонент занят» штатно снимается ОУ через 5 мс по мере подготовки информации абонентом.
Кроме ИОС в сети имеются другие средства защиты, например, бит четности в каждом слове сообщения, аппаратный контроль формы импульса в ОУ и К и т.п. Однако, применительно к нашей задаче их моделирование нас не интересует и мы в дальнейшем их не рассматриваем.
Передача сообщений (команд и данных) может идти от «К» по ЛПИ А или по ЛПИ В, в том случае, когда соответствующие ЛПИ и полукомплекты ОУ исправны. Передача сообщений начинается всегда с попытки его выдачи по ЛПИ А (по умолчанию).
13 SHAPE \* MERGEFORMAT 1415
Самое неприятное в данной шинной организации сети, что «ОУi» могут «загенерить» (перейти в режим «Г») – передавать в канал ЛПИj***, по которому идет работа, непрерывный сигнал в течение времени
· 800* мксек. Эта ситуация аварийная для сети в целом, так как при этом полезные сообщения от «К» ни к одному из «ОУ» в канале А или В, в котором имеется генерация не будут проходить, так же как и «К» не будет получать ответных слов от ОУ.
Для борьбы с такой ситуацией предусмотрен механизм блокировки и разблокировки ОУi. Она возможна при передаче из К по линии свободной от генерации (А при генерации в В, либо в В при генерации в А) специальных команд на ОУi «разблокировать» или «заблокировать» передатчик в ОУi другого канала в нашем случае В или А, где есть генерация. Но для этого надо определить, где на ЛПИ А или ЛПИ В имеется генерация и найти генерящий ОУ.
В стандарте предусмотрена аппаратная защита от генерации «таймером непрерывной передачи» в каждом ОУ и К.Однако , как показывает практика, не все отечественные производители аппаратуры ОУ выполняют этот пункт. Поэтому программная защита здесь не лишня.
Примечания:
*) 700 мксек – максимально возможная длина штатного сообщения (с ответным словом).
**) Устройства интерфейса – контроллер или ОУ.
***)j = А, В; i
· 32
Анализ предметной области
Для каждого ОУ сети можно определить таблицу состояний, в котором оно может находиться. Исходные данные моделирования помещаются в эту таблицу по каждому ОУ. См. таблицу №4.
Для того, чтобы заблокировать передатчик генерящего ОУi и открыть, таким образом, канал ЛПИ для работы с другими ОУ, номера которых не равны i, необходимо определить какой же ОУ и на какой линии «генерит». Этот алгоритм должен исполняться из ЦВМ контроллера. Возможный пример такого алгоритма приведен ниже.
Если контроллер «К» пытается передать (поочередно) сообщение в несколько ОУm, ОУm+1, ОУm+l по одной из ЛПИ и у него это не получается ни с одним из них, то это следствие либо генерации на ЛПИ, либо обрыва ЛПИ сразу за «К», либо неисправности самого К на данной ЛПИ. Во всех этих случаях контроллер должен попробовать перейти на передачу текущего сообщения по другой ЛПИ. Однако, просто успешная передача сообщения по дублирующей ЛПИ в случае наличия «генерации» представляется недостаточной, так как выход из работы целиком ЛПИ А или В резко ухудшает надежность работы системы. Действительно, любой отказ полукомплекта ОУi (канала А или В ОУi) на действующей ЛПИ не позволяет использовать исправный второй полукомплект ОУi на другой ЛПИ, так как эта другая ЛПИ целиком неисправна – выведена из строя генерящим ОУ. Операцию последовательного обращения к ОУ с простой командой типа «дай ответное слово», позволяющую обнаружить неработоспособность целиком ЛПИ А и В, будем называть «тест» МКО. При проведении теста МКО прекращается передача штатных сообщений по линии.
После того как обнаружена «генерация» на ЛПИ – ни один из ОУ не отвечает, для поиска генерящего ОУ необходимо заблокировать все ОУ командой «Блокировка» на генерящей ЛПИ. Затем поочередно разблокировать каждое ОУ и попытаться провести с ним обмен. Если обмен на генерящей ЛПИ с текущим разблокированным ОУ не проходит – значит он «генератор». Можно реализовать другой алгоритм: блокировать ОУ поочередно и и проводить каждый раз «тест» . Тот ОУ после блокировки которого «тест» проходит и будет генерящим.
Таким образом, для обеспечения высокой надежности передачи в ПО ЦВМ «К» необходимо иметь три описанных алгоритма, реализуемых как системные в ПО ЦВМ «К»:
алгоритм перехода на дублирующую линию при наличии отказов ОУ;
алгоритм распознавания отказа или сбоя;
алгоритм теста МКО для обнаружения генерации на ЛПИ А или ЛПИ В;
алгоритм поиска генерящего ОУ на обнаруженной линии с генерацией и его блокировка.
Рекомендации по моделированию
Приведено достаточно полное вербальное описание сети. Не на все вопросы, связанные с работой сети можно дать сразу однозначный ответ. Например, как правильнее искать генерящего, сразу заблокировав все ОУ, разблокируя их затем по одному, или по одному их блокировать до тех пор пока ОУ не начнут давать ответные слова. Здесь критерий может быть связан со временем поиска генерящего. Надо для этого создать модель и моделированием получить ответы на поставленные вопросы. Не вся приведенная информация нужна в такой модели. Моделировать, как бегают импульсы по ЛПИ и передаются биты сообщений, например, не надо.
Для решения поставленной задачи целесообразно применить имитационное моделирование. При этом все структурные элементы сети : ОУ, К, сообщения должны быть явно выделены в программные модули (объекты), взаимодействие между которыми должно имитировать работу реальной системы. Таким образом, целесообразно применить объектно-ориентированный подход (но не обязательно объектно-ориентированный язык программирования). Объекты:
Контроллер .
ОУ, которые имеют состояние: исправен, отказ, сбой, отказ – «генерация», «Абонент занят», заблокирован, ошибка в сообщении в соответствии с таблицей.
Сообщения, которые имеют состояние: прошло или не прошло. Атрибуты: адрес ОУ, тип, длительность.
Должна быть также ведущая подпрограмма , которая сначала создает среду моделирования : по заданному в исходных данных количеству ОУ создает соответствующее количество подпрограмм(объектов) и затем загружает состояния ОУ из таблицы исходных данных в соответствующие ОУ.
Следует обратить внимание на подход имитационного моделирования : не обращаться к таблице исходных данных по состоянию ОУ в процессе моделирования, а передать состояние ОУ в его модель и в процессе моделирования каждый ОУ отвечает К в соответствии с загруженным в него состоянием, имитируя работу реальной системы.
Затем ведущая программа должна просканировать исходные данные и при наличии в них генерации в каком-либо из ОУ на ЛПИ А или В предписать каждому из ОУ на ЛПИ, в которой имеется генерация, временное состояние « не давать ответное слово». После обнаружения генерации , установления «генерящего» и его блокирования эти временные состояния должны быть сняты , но исходные состояния ОУ сохранены.
Затем ведущая программа запускает модуль «тест», затем «толкает обмены» и т.п.
Моделирование передачи сообщения в МКО может осуществляться путем сравнения адреса в сообщении и адресов ОУ( в качестве адреса используется его номер), определения наличия ответного слова на переданное сообщения в соответствии с состоянием адресуемого ОУ и определения действий ПО контроллера в соответствии с логикой, которую предстоит предложить или уточнить, поскольку стандартом она не определена и отдана на прикладной уровень – на откуп разработчику.
Адресация ОУ может быть произвольной в диапазоне от 1 до 31.но мы будем использовать последовательную адресацию.
Проверки состояния должны осуществляться на каждом сообщении, приходящем на ОУi, и только при положительном их завершении можно говорить, что ОУi сообщение приняло и дало ответное слово на данной ЛПИ.
Нельзя жестко программировать задачу под таблицу фиксированных состояний ОУ – она переменна. В любой полукомплект любого ОУ может быть задана неисправность.
Типы и длительность сообщений в сети
Будем рассматривать только:

1.Короткое сообщение типа: «команда», «дай ответное слово», «заблокировать ОУi», «разблокировать ОУi»

Длительность= 52 мкс


2.Длинное сообщение типа «выдача информации на ОУ»: команда + до 32 слов информации +ОС

Длительность
· 692мкс


3.Длинное сообщение типа «дай информацию в контроллер»: команда+ОС+до32 слов сообщения. Длительность 13 EMBED Equation.3 1415692мкс
4.Все сообщения (длинные и короткие) сопровождаются работой ПО и драйвера канала в ЦВМ контроллера, в том числе для анализа ответного слова или его отсутствия перед повторением сообщения.
Поэтому с учетом работы ПО ЦВМ контроллера после каждого сообщения до передачи следующего при моделировании имеет место – пауза длительностью не менее 1000мкс.
5.Все сообщения предаются контроллером первоначально по ЛПИ А.
6.Для паузы адрес ОУ указывается 0.
7.Предусмотривается возможность того, что вводимая в ИД неисправность ОУ является самоустраняющейся (т.е. сбоем), что бывает в реальных системах. Поэтому после не прохождения однократной передачи, может последовать прохождение передачи при её повторе.
Примерная таблица вариантов моделирования передачи сообщений в сети
Количество сообщений
Длительность и интервал между сообщениями
Адреса ОУА, к которым адресуется сообщение
Количество ОУ в сети

5
Короткие с интервалом 2мс
3,12,1,15,1
15

6
Длинные с интервалом 2мс
2,4,13,15,22,4
25

4
Перемежаются с интервалом 2мс
6,5,11,14
13

7
Короткие с интервалом 1мс
6,5,11,14,15,17,30
17

10
Длинные с интервалом 1мс
3,5,6,8,9,10,7,1,4,2
10



Перемежаются с интервалом 1мс
6,5,11,14,11,10
14


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

Исправен
да
-«-
Во все нижеперечисленные


Заблокирован (А или В)
нет на заблокир. ОУ(А или В)
-«-
Разблокируется по специальной команде К по другой ЛПИ
Если ОУ на А, то по В
Если ОУ на В, то по А

Неисправен (А или В)
нет на неиспр. ОУ(А или В)
-«-
Остается все время в этом состоянии


Сбой (А или В)
нет на сбойном ОУ(А или В)
-«-
При следующем обращении исправен


«Абонент занят»
Да с признаком абонент занят

Переходит в исправное состояние при обращении к нему через 5мс
При получении в ответном слове «Абонент занят», следующее к нему отправляется через 5мс

«Генерация» (А или В)
нет (А или В)
-«-
Блокируется по специальной команде по другой ЛПИ
Нет ответных слов от любого ОУ на данной ЛПИ

Ошибка в сообщении
Нет и по А, и по В
Адрес, установленный в сообщен, отсутствует в сети

Проверка адреса



Приложение 2
Типы и форматы сообщений
Все сообщения, передаваемые в сети, имеют длину 20 бит и разделяются на три типа: командное слово, данные, ответное слово. В каждом двадцатом битном слове сообщений первые три бита – синхросигнал для вхождения в связь, а последний двадцатый бит – бит четности для контроля целостности информации.
Разрядная сетка
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20







Командное слово
синхросигнал
Адрес ОУ
Подадрес или режим управления
Число слов данных или код команды
1








Слово данных
синхросигнал
данные
1















Ответное слово
синхросигнал
Адрес ОУ
2
3
4
резерв
5
6
7
8
9
1


Командные слова передаются только контроллером .Здесь для ответного слова ОУ:
1 – бит четности,
2 – бит «ошибка в сообщении»
3 – бит «признак ответного слова»
4 – бит «запрос на обслуживание»
5 – бит «групповая команда»
6 – бит «абонент занят и не может ответить»
7 – бит «абонент неисправен»
8 – бит «принято управление»
9 – бит «неисправное ОУ»

Кратко рассмотрим формат трех типов сообщений. Всего их шесть.


Формат 1 – передача данных от контроллера к ОУ
Командное слово
Слово данных
.
Слово данных

Ответное слово от ОУ

Следующее командное слово






t1

t2




Формат 2 – запрос данных от ОУ в контроллер
Командное слово

Ответное слово
Слово данных

Слово данных

Следующее командное слово



t1




t2




Формат 3 – передача от контроллера в ОУ команды управления.
Командное слово

Ответное слово

Следующее командное слово


t1

t2



Кроме этих форматов существует формат группового сообщения, формат передачи данных от ОУ к ОУ, но только по команде контроллера и т.п.
Пауза t1 формируется ОУ после полученного сообщения и должна быть 4-12 мксек. Отсутствие ответного слова через t1>12мксек воспринимается контроллером как неполучение ОУ направленного ему сообщения. Пауза t2 формируется контроллером и связана с работой его ПО для определения следующей команды на ОУ. Мы примем её равной 1000 мксек.
Максимальное число слов данных в сообщении равно 32.
Приложение 3

Номер оконечного устройства
А
В
А
В
А
В
А
В
А
В
А
В
А
В

1
НИ
НИ
НИ
НИ
НИ
сб
сб

сб

ни
сб
Ни
аз

2

Сб
сб

Ни

аз

аз

ни
аз
ни
аз

3
ген


ген
Ни
аз
сб

сб
ген


ни
аз

4

Ни
Ни

Ни

аз

аз

ген
аз
ни
аз

5

аз
аз

Ни
сб
сб

сб


сб
ни
аз

6




Ни

ни
сб
ни
сб


ни
аз

7






ни
сб
ни
сб
сб

ни
аз

8










ни




32
















Номер оконечного устройства
А
В
А
В
А
В
А
В
А
В
А
В
А
В

1
НИ
НИ
сб
сб

ни
сб
аз
НИ
сб
сб
Ни
аз


2
Сб
Ни

аз

ни
аз
аз

аз
аз
ни
аз


3

Ни
аз
сб



аз
ген
сб
сб
ни
аз
аз

4
Ни
Ни

аз

ген
аз
аз

аз
аз
ни
аз
сб

5
аз
Ни
сб
сб
сб

сб
аз

сб
сб
ни

ни

6

Ни

ни
сб


аз

ни
ни
ни

ни

7



ни

сб

аз

ни
ни
ни



8





ни









32


















НИ –неисправен
СБ – сбой
АЗ – абонент занят
ГЕН - генерация









13PAGE 15


13PAGE 141815



Исполнительные органы
(ИО)

Объект
Управления (ОУ)

Чувствительные элементы
(ЧЭ)

Управляющая
ЦВМ

ИО1

ЦВм

ИОк

ЦВм

Объект управления

ЧЭ1

ЦВМ

ЧЭп
ЦВМ



Системная ЦВМ

K
B


A

Системное ЦВМ

ОУ1
B


A

ЦВМ абонента

ОУi
B


A

ЦВМ абонента

ОУn
B


A

ЦВМ абонента

ЛПИ А

ЛПИ В





20мкс

20мкс

4 – 12мксек
пауза

отв.слово

20мкс + 32х20мкс

20мкс

4 – 12мксек
пауза



Root Entry

Приложенные файлы

  • doc 12743705
    Размер файла: 187 kB Загрузок: 0

Добавить комментарий