Моделирование межсерверного перехода в CPN Tools
TL;DR: Я пытаюсь создать переход "тройной сервер" с экспоненциальным временем срабатывания на CPN Tools для стохастически синхронизированной сети Петри. Я пробовал два подхода, но оба столкнулись с некоторыми ошибками или ограничениями моделирования.
Задний план
Согласно статье, которую я анализирую, большая часть программного обеспечения для моделирования сети Петри не может создавать экземпляры "многосерверных" переходов в целом (из-за проблем с "множественной активностью"; см. Ниже), но в этой статье никогда не рассматривалась утилита CPN Tools с списки, надписи и сегменты кода. Но прежде чем я перейду к сути вопроса, я должен, конечно же, ответить на очевидный вопрос: "Что такое переходы между несколькими серверами?"
В общем, все переходы в сети можно считать "односерверными"; то есть переход представляет один ресурс или задачу, так что только одна операция может выполняться за раз. Да, дуги могут иметь веса, но даже тогда переходы представляют собой единичный экземпляр или выполнение некоторого действия. Однако "мультисерверы" могут одновременно выполнять некоторое количество операций.
Чтобы предложить наглядное (и, возможно, лучшее объяснение), вот сравнение односерверного и многосерверного:
Пример с одним сервером здесь имеет разумный смысл; t 1 запускается три раза, и один жетон перемещается при каждом запуске. Общее время увеличивается при каждом запуске.
t 1 вот теперь тройной сервер; он срабатывает только один раз, но потребляет все три токена от p 1 до p 2 одновременно и увеличивает общее время только один раз. Есть небольшая оговорка: обратите внимание, что нет веса дуги - она почти ведет себя как дуга с ограниченным доступом.
Проблема
Имея это в виду, я пытаюсь смоделировать небольшой пример столовой, который исследуется в статье, чтобы сравнить их результаты (которые обоснованно утверждают, что использование нескольких серверов более эффективно до определенного момента) с моим собственным анализом производительности, чтобы гарантировать правильность. Из-за взрывного роста / сложности маркировки / достижимости я не могу разумно делать индексы производительности вручную, поэтому я обратился к CPN Tools.
Не зацикливаясь на мелочах и нюансах реальной модели (и вычеркивая некоторые несоответствия и несоответствия или более мелкие детали цветовых наборов и почему я выбрал их), мне нужно смоделировать самозамкнутый трехсерверный переход, который экспоненциально распределен и (исходя из того, что я понимаю о модели) потребляет токены со скоростью, зависящей от двух условий: количества токенов в "серверном" лимит-/ анти-месте и количестве токенов в исходном месте.
Чтобы устранить проблему с зацикливанием, я сделал сеть чистой, добавив фиктивный переход (который срабатывает сразу после многосерверного перехода) и место (который моделирует "занятые" серверы после срабатывания многосерверного перехода). Однако я все еще застрял на главном вопросе: как смоделировать мультисервер.
Подход №1: несколько отдельных серверов
Сначала я попробовал очевидное: сделайте несколько переходов между одним сервером, чтобы имитировать переход между одним сервером. Я могу сделать это, предположительно, потому что согласно этой статье предлагается к -server перехода можно считать эквивалентным K одного сервера переходов, где каждый экземпляр срабатывает независимо от других еще следует тем же случайное распределение.
Естественно, это означало переход на три сервера, мне пришлось сделать три отдельных сервера, один из которых потребляет один токен, другой - два, а третий - три. Но для того, чтобы он работал правильно, мне нужно установить приоритет перехода "потреблять три" перед двумя другими, чтобы, если в исходном месте есть три или более токена (и по крайней мере три "сервера" доступны в месте ограничения), запускается переход "потреблять три", а НЕ два других. Точно так же, если в исходном месте есть не более двух токенов (и доступно не менее двух "серверов"), "поглотите два" огня.
Я пробовал повозиться с надписями приоритета перехода, но у меня так и не получилось; проблема заключалась в том, что, несмотря на приоритеты, каждый из трех одиночных серверов имел собственное время срабатывания, поэтому естественным образом первым срабатывал тот, у которого было наименьшее время (что часто было переходом "потреблять один"), а не с наивысшим приоритетом. Я попытался повозиться с глобальными ссылками, чтобы сохранить одинаковое время срабатывания для всех трех переходов (чтобы избежать вышеупомянутого состояния гонки), но это также было бесполезно.
Изменить: я также попытался реализовать три перехода, каждый из которых потребляет один токен, а не многоуровневую скорость потребления (потому что я думал, что неправильно понял условие "независимого срабатывания"), но поскольку каждый отдельный экземпляр перехода увеличивает глобальное время после срабатывания, я не могу убедитесь, что все включенные одиночные серверы запускаются синхронно хотя бы один раз в один и тот же момент времени.
Может быть, это мой недостаток опыта, но я не могу добиться желаемого поведения только с приоритетами и множественными переходами.
Подход № 2: списки
Спустя несколько часов я обнаружил мощь списков в CPN Tools. Используя списки, я понял, что мне не нужны три отдельных сервера - всего один переход! Конечно, чтобы все работало правильно, мне потребовались некоторые сегменты кода, чтобы обеспечить соблюдение ограничений, основанных на размере как "серверных", так и исходных мест. Мне потребовалось некоторое время, чтобы разобраться в синтаксисе кода ML, но в конце концов я получил кое-что, что работало именно так, как я хотел... ну, почти.
После нескольких пробных симуляций я заметил явную ошибку симуляции и, кажется, сузил ее до одной конкретной ошибки: схемы вставки списка. Как некоторые из вас могут знать, чтобы добавить токен в список, вам нужно использовать список; вы не можете просто добавить токен из источника в уже существующий список в каком-то месте назначения, потому что он может иметь или не иметь список в этом месте для начала!
Обратите внимание, однако, что вы должны использовать токен, чтобы добавить токен в эту схему, даже если вы просто добавляете элемент в список; это означает, что любой последующий переход, который был включен перед срабатыванием, теперь внезапно отключается и должен ждать своей очереди, даже если упомянутый переход был включен до вставки. Это означает, что каждый раз, когда я вставляю элемент в список, переход между несколькими серверами отключается, а затем снова включается, тем самым сбрасывая время срабатывания перехода, вызывая ошибку моделирования, которая не является оптимальной.
Теоретически я мог бы жить с небольшой ошибкой, но ошибка моделирования в этом случае может бросаться в глаза для небольших интервалов прибытия и сильно искажать мой анализ производительности.
Вывод
Итак, я застрял: я убежден, что CPN Tools может моделировать этот сценарий, но мне кажется, что я не могу выбраться из этой кроличьей норы. Есть ли что-то, о чем я пренебрегаю, или правильно ли в документе говорится, что никакое программное обеспечение сети Петри на рынке не может моделировать "мульти-серверы"?
Если для правильного ответа на этот вопрос необходимы дополнительные сведения, например "как выглядит вся топология сети" или "какие сегменты кода я использовал", не стесняйтесь спрашивать, и я постараюсь предоставить ответы на эти вопросы в лучшее из моих возможностей.