Рекомендации по моделированию

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

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

1) Контроллер.

2) ОУ, которые имеют состояние: исправен, отказ, сбой, отказ – «генерация», «Абонент занят», заблокирован, ошибка в сообщении в соответствии с таблицей.

3) Сообщения, которые имеют состояние: прошло или не прошло. Атрибуты: адрес ОУ, тип, длительность.

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

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

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

Затем ведущая программа запускает модуль «тест», затем «толкает обмены» и т.п.

Моделирование передачи сообщения в МКО может осуществляться путем сравнения адреса в сообщении и адресов ОУ(в качестве адреса используется его номер), определения наличия ответного слова на переданное сообщения в соответствии с состоянием адресуемого ОУ и определения действий ПО контроллера в соответствии с логикой, которую предстоит предложить или уточнить, поскольку стандартом она не определена и отдана на прикладной уровень – на откуп разработчику.

Адресация ОУ может быть произвольной в диапазоне от 1 до 31.но мы будем использовать последовательную адресацию.

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

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