Анализ предметной области
Для каждого ОУ сети можно определить таблицу состояний, в котором оно может находиться. Исходные данные моделирования помещаются в эту таблицу по каждому ОУ. См. таблицу №4.
Для того, чтобы заблокировать передатчик генерящего ОУi и открыть, таким образом, канал ЛПИ для работы с другими ОУ, номера которых не равны i, необходимо определить какой же ОУ и на какой линии «генерит». Этот алгоритм должен исполняться из ЦВМ контроллера. Возможный пример такого алгоритма приведен ниже.
Если контроллер «К» пытается передать (поочередно) сообщение в несколько ОУm, ОУm+1, ОУm+l … по одной из ЛПИ и у него это не получается ни с одним из них, то это следствие либо генерации на ЛПИ, либо обрыва ЛПИ сразу за «К», либо неисправности самого К на данной ЛПИ. Во всех этих случаях контроллер должен попробовать перейти на передачу текущего сообщения по другой ЛПИ. Однако, просто успешная передача сообщения по дублирующей ЛПИ в случае наличия «генерации» представляется недостаточной, так как выход из работы целиком ЛПИ А или В резко ухудшает надежность работы системы. Действительно, любой отказ полукомплекта ОУi (канала А или В ОУi) на действующей ЛПИ не позволяет использовать исправный второй полукомплект ОУi на другой ЛПИ, так как эта другая ЛПИ целиком неисправна – выведена из строя генерящим ОУ. Операцию последовательного обращения к ОУ с простой командой типа «дай ответное слово», позволяющую обнаружить неработоспособность целиком ЛПИ А и В, будем называть «тест» МКО. При проведении теста МКО прекращается передача штатных сообщений по линии.
После того как обнаружена «генерация» на ЛПИ – ни один из ОУ не отвечает, для поиска генерящего ОУ необходимо заблокировать все ОУ командой «Блокировка» на генерящей ЛПИ. Затем поочередно разблокировать каждое ОУ и попытаться провести с ним обмен. Если обмен на генерящей ЛПИ с текущим разблокированным ОУ не проходит – значит он «генератор». Можно реализовать другой алгоритм: блокировать ОУ поочередно и и проводить каждый раз «тест» . Тот ОУ после блокировки которого «тест» проходит и будет генерящим.
Таким образом, для обеспечения высокой надежности передачи в ПО ЦВМ «К» необходимо иметь три описанных алгоритма, реализуемых как системные в ПО ЦВМ «К»:
алгоритм перехода на дублирующую линию при наличии отказов ОУ;
алгоритм распознавания отказа или сбоя;
алгоритм теста МКО для обнаружения генерации на ЛПИ А или ЛПИ В;
алгоритм поиска генерящего ОУ на обнаруженной линии с генерацией и его блокировка.
Рекомендации по моделированию
Приведено достаточно полное вербальное описание сети. Не на все вопросы, связанные с работой сети можно дать сразу однозначный ответ. Например, как правильнее искать генерящего, сразу заблокировав все ОУ, разблокируя их затем по одному, или по одному их блокировать до тех пор пока ОУ не начнут давать ответные слова. Здесь критерий может быть связан со временем поиска генерящего. Надо для этого создать модель и моделированием получить ответы на поставленные вопросы. Не вся приведенная информация нужна в такой модели. Моделировать, как бегают импульсы по ЛПИ и передаются биты сообщений, например, не надо.
Для решения поставленной задачи целесообразно применить имитационное моделирование. При этом все структурные элементы сети : ОУ, К, сообщения должны быть явно выделены в программные модули (объекты), взаимодействие между которыми должно имитировать работу реальной системы. Таким образом, целесообразно применить объектно-ориентированный подход (но не обязательно объектно-ориентированный язык программирования). Объекты:
Контроллер .
ОУ, которые имеют состояние: исправен, отказ, сбой, отказ – «генерация», «Абонент занят», заблокирован, ошибка в сообщении в соответствии с таблицей.
Сообщения, которые имеют состояние: прошло или не прошло. Атрибуты: адрес ОУ, тип, длительность.
Должна быть также ведущая подпрограмма , которая сначала создает среду моделирования : по заданному в исходных данных количеству ОУ создает соответствующее количество подпрограмм(объектов) и затем загружает состояния ОУ из таблицы исходных данных в соответствующие ОУ.
Следует обратить внимание на подход имитационного моделирования : не обращаться к таблице исходных данных по состоянию ОУ в процессе моделирования, а передать состояние ОУ в его модель и в процессе моделирования каждый ОУ отвечает К в соответствии с загруженным в него состоянием, имитируя работу реальной системы.
Затем ведущая программа должна просканировать исходные данные и при наличии в них генерации в каком-либо из ОУ на ЛПИ А или В предписать каждому из ОУ на ЛПИ, в которой имеется генерация, временное состояние « не давать ответное слово». После обнаружения генерации , установления «генерящего» и его блокирования эти временные состояния должны быть сняты , но исходные состояния ОУ сохранены.
Затем ведущая программа запускает модуль «тест», затем «толкает обмены» и т.п.
Моделирование передачи сообщения в МКО может осуществляться путем сравнения адреса в сообщении и адресов ОУ( в качестве адреса используется его номер), определения наличия ответного слова на переданное сообщения в соответствии с состоянием адресуемого ОУ и определения действий ПО контроллера в соответствии с логикой, которую предстоит предложить или уточнить, поскольку стандартом она не определена и отдана на прикладной уровень – на откуп разработчику.
Адресация ОУ может быть произвольной в диапазоне от 1 до 31.но мы будем использовать последовательную адресацию.
Проверки состояния должны осуществляться на каждом сообщении, приходящем на ОУi, и только при положительном их завершении можно говорить, что ОУi сообщение приняло и дало ответное слово на данной ЛПИ.
Нельзя жестко программировать задачу под таблицу фиксированных состояний ОУ – она переменна. В любой полукомплект любого ОУ может быть задана неисправность.