Introduction to SIMIO / Введение в SIMIO: Страница 77-90
| Английский оригинал | Перевод на русский | |
|---|---|---|
Сожалеем, но текст оригинала доступен только зарегистрированным пользователям. |
Глава 6: Определения объектов VozAxaR 02.07.13 в 14:56 |
|
|
Обзор VozAxaR 02.07.13 в 14:57 |
||
|
Стандартная библиотека, которую мы использовали до этого, является лишь одной из множества доступных библиотек, которую вы можете использовать, чтобы строить свои модели. Используя Simio Design или Team Edition, вы можете создавать библиотеки объектов для ваших целей или создать библиотеку для совместного использования на вашем предприятии. Также вы можете строить и коммерческие библиотеки, которые вы можете представлять на рынок и продавать другим. В этой главе мы рассмотрим основные понятия и методы для построения ваших собственных определений объекта и его совместного использования с библиотеками. VozAxaR 02.07.13 в 15:04 |
||
|
Одним из основных принципов Simio является представление, что любая модель может являться объектом определения. Модели используются для определения основных свойств объекта. Очень легко взять модель, которую вы разработали, а затем "запаковать" её для ещё кого-нибудь, чтобы использовать в качестве строительных блоков для других моделей. Кроме того, также легко построить субмодели в рамках собственного проекта, а затем построить модели с помощью этих субмоделей в качестве строительных блоков. VozAxaR 02.07.13 в 15:14 |
||
|
Материал, который мы будем обсуждать здесь, является развитием идей, которые мы представили в главе 5 в процессе моделирования. В той главе мы узнали, как использовать процессы расширения базовой функциональности одного конкретного объекта, не изменяя при этом основное поведение определения объекта. В этой главе внимание будет сфокусировано на другом изменении или расширении поведения определения объекта, которое затрагивает поведение всех экземпляров этого объекта, или же на строительстве новых объектов с нуля. VozAxaR 02.07.13 в 15:19 |
||
|
Основные понятия VozAxaR 02.07.13 в 15:19 |
||
|
Определение объекта имеет пять основных компонентов: свойства, состояния, события, внешний вид и алгоритм. Свойства, состояния, события и внешний вид определены для модели в окне Definitions. Алгоритм модели определён в окне Facility и Processes. VozAxaR 02.07.13 в 15:22 |
||
|
Мы начали использовать свойства модели ещё в 1 главе для создания свойств, которые были указаны в нашей модели и могли быть использованы для экспериментов. Те же самые свойства были использованы для определения входов для модели, когда использовались как определения объекта. Свойства модели предоставляют точки входа в алгоритм модели и остаются неизменными в течение работы модели. Состояния используются для определения текущего состояния объекта. Всё, что может изменяться в течение выполнения симуляции, представлено в объекте в качестве состояний. VozAxaR 02.07.13 в 15:52 |
||
|
Внешний вид VozAxaR 02.07.13 в 15:52 |
||
|
Внешний вид представляет собой графическое представление для экземпляров фиксированных или динамических объектов. Внешний вид не используется для узлов или ссылок. Его можно определить нажав на панель External в окне Definitions, как показано ниже: VozAxaR 02.07.13 в 15:54 |
||
|
Внешний вид - это то, что пользователь видит, когда размещает экземпляр объекта в своей модели. Графика для внешнего вида может быть унаследована от вида объекта модели, специально создана при использовании элементов из библиотеки элементов или загружена с Google Warhouse. Также статическая графика может быть нарисована с использованием инструментов рисования на ленте Drawing. Кроме того, представление может содержать прикрепленные компоненты анимации, которые размещены в форма просмотра окна Animation. Эти компоненты включают в себя анимированные очереди, метки состояния, чертежи, круговые диаграммы, линейные/круговые размеры и кнопки. Отметим, что в случае динамических объектов (например, сущностей) объекты анимации сохраняются для каждого динамического объекта в системе. Например, сущность может содержать метку состояния, отображающую значение одного из состояний или кнопку, при нажатии которой пользователем вызовется некое действие. VozAxaR 04.07.13 в 04:55 |
||
|
При создании нового статического объекта обычно проводится соответствие входных/выходных узлов для объекта, так что динамические объекты могут входить и/или покидать ваш статический объект. Например, объект Server связан с объектами узла для ввода и вывода. Характеристики этих связанных объектов также определены внешним видом объекта путем размещения внешнего обозначения узла, используя ленту Drawing. Эти внешние обозначения узла также могут быть добавлены к внешнему представлению непосредственно от представления средства при помощи клика правой кнопкой мыши на соответствующих узлах в представлении средства. Заметим, что это не объекты узла, а обозначения, идентифицирующие местоположение, где ассоциированные узловые объекты будут созданы, когда этот объект будет размещен. VozAxaR 06.07.13 в 07:08 |
||
|
Когда вы помещаете обозначение узла во внешний вид, вы также должны определить его свойства. Node Class (Класс узла) определяет тип узла, который должен быть создан. Выпадающий список предоставит возможность выбора всех доступных определений узла, которые включают в себя Node (Узел - пустая модель), BasicNode (Базовый узел - простое пересечение) и VozAxaR 08.07.13 в 05:42 |
||
|
-- VozAxaR 04.07.13 в 05:48 |
||
|
TransferNode(Передаточный узел - пересечение с поддержкой настроек места назначения и выбора транспортёра для перехода), а также любые другие определения узла, которые вы загрузили из библиотеки или определили в вашем проекте. В случае использования Standart Library (стандартной библиотеки) класс BasicNode всегда используется для входных узлов, а TransferNode - для выходных узлов. Тип входного алгоритма определяет то, как прибывающие сущности должны быть обработаны этим объектом. Параметр None указывает на запрет на посещение данного узла для сущности. Параметр ProcessStation определяет, что прибывающая сущность может входить в определенную точку, которая вызывает событие входа в точку, которая может быть использована для запуска какого-либо алгоритма. Это используется при определении объекта алгоритма с использованием модели процесса. Параметр FacilityNode значит, что прибывающая сущность будет перенаправлена на узел, находящийся внутри модели объекта. Такой параметр используется для определения алгоритма поведения при использовании модели объекта. В секции General параметр Name для отображения узла является заранее заполненным. Это имя отображения узла используется для создания имени связанного узлового объекта, созданного в этом месте отображения, когда создается экземпляр этого объекта при использовании формата NodeSymbolName@ObjectName. Например, если имя отображения Input, а имя объекта Lathe, то связанный объект автоматически получит имя Input@Lathe. В Standart Library отображения входных узлов названы Input, а отображения выходных узлов - Output. VozAxaR 08.07.13 в 06:03 |
||
|
Алгоритм модели VozAxaR 08.07.13 в 06:18 |
||
|
Алгоритм для определения фиксированного объекта определяется с помощью объекта и/или процесса модели, указанного Input Logic Type в отображении узла. В случае сущностей, транспортёров, узлов и ссылок не существует отображений узлов, а следовательно такие модели обычно строятся с использованием алгоритмов развития процесса. VozAxaR 08.07.13 в 06:25 |
||
|
Каждый раз, когда вы построили модель системы, она представляет компонент алгоритма определения объекта. Обычно, вы можете превратить любую модель в готовое к применению определение объекта просто добавляя некоторые свойства поставляющим входам модели, а также внешний вид, чтобы создать графическое представление для объекта, а также для узлов, которые позволяют сущностям посетить и покинуть модель. VozAxaR 09.07.13 в 15:09 |
||
|
Существует три подхода к определению алгоритма модели для объекта. Первый подход заключается в создании модели, используя иерархический принцип, а именно используя средства модели. Этот подход также может быть совмещен с использованием дополнения процессов для определения поведения объекта согласно пользовательским предпочтениям. Этот подход обычно используется для создания компонента более высокого уровня иерархии, как например объект Рабочий центр, включающий в себя две машины, рабочего и оснастку. Второй, и наиболее гибкий подход, заключается в создании объекта определения поведения с нуля с использованием модели процесса. Этот подход был использован при создании библиотеки Standart. Третий подход заключается в разбиении на подклассы существующего определения объекта, а затем изменение или дополнение его поведения с использованием процессов. Этот подход, как правило, используется, когда есть уже существующий объект, которые имеет схожие с нужным объектом характеристики и может быть "достроеннным" с точки зрения собственного имени, описания и поведения, чтобы удовлетворить требованиям к новому объекту. VozAxaR 09.07.13 в 15:29 |
||
|
Пример: Основной токарный станок VozAxaR 09.07.13 в 16:17 |
||
|
Пример: Сервер с ремонтником. VozAxaR 09.07.13 в 16:16 |
