The Process Modeling library of AnyLogic supports the discrete-event or, more precisely, the process-oriented modeling paradigm. Using the blocks of the Process Modeling library, you can model real-world systems in terms of agents (transactions, customers, products, parts, vehicles, and so on), processes (sequences of operations typically involving queues, delays, resource utilization), and resources. Processes are specified in the form of flowcharts — a common graphical representation used in many fields: manufacturing, call centers, business processes, logistics, healthcare, and so on. AnyLogic flowcharts are hierarchical, scalable, extensible, and object-oriented, allowing users to model large, complex systems at any level of detail. Another important feature of the Process Modeling library is the ability to create highly sophisticated animations of process models.
As with everything in AnyLogic, the process models can be extended to any depth with custom functionality. First, you can create your own agent and resource unit types with any fields and functions added. By specifying these types in the generic parameters of the process blocks, you provide easy access to the custom fields. For example, in the airport model you may want to have special agent types for passengers, security officers, luggage, and so on.
Second, each block in the Process Modeling library has extension points — places where you can insert your own actions or expressions. These extension points are dynamic parameters that are evaluated during the simulation as the agents move through the process flowchart.
For example, in a Delay block that corresponds to printing a boarding pass at check-in, you can assign a gate to the passenger by writing the following in the On exit parameter:
agent.gate = Main.gateof(agent.flightno)
Here, gate and flightno are custom properties of the passenger, and gateof() is a function within the Main airport object.
The Process Modeling library works closely with the AnyLogic presentation and animation framework, allowing you to develop highly sophisticated process animations. The animations can be made hierarchical with multiple views, for example, the high-level view of the process may show only key aggregate indicators, but you can switch to the component view with detailed sub-process animation.
For most blocks in the Process Modeling library, you define the animation as follows: you add a space markup shape, path, or node and specify that element in the Agent location parameter of, say, a Delay block, indicating that you want the delayed agents to move along the path. Then, while the agents are inside the Delay block, the agent animation shapes are drawn at the appropriate positions on the path.
One of the greatest benefits of AnyLogic is the ability to combine different modeling styles to capture the complexity and heterogeneity of the real-world systems. The Process Modeling library is an open framework that allows you to combine your process models with, for example, system dynamics or agent based models, or simply to develop custom blocks using AnyLogic core primitives and include them in the process flow.
There is a wide range of techniques, here are some examples.
- A link from the stock and flow diagram in system dynamics to a process model may be implemented, for example, as the Source block agent generation rate controlled by a system dynamics variable.
- A reverse link might be a system dynamics stock that is incremented each time an agent arrives at the Sink block in the process flow.
- An agent may live in an agent population and be injected into a process at some point in its life via the Enter block.
If you need a block with specific functionality that is different from any block in Process Modeling library (and cannot be achieved by combining them), you can develop your own agent type and use Exit and Enter blocks on its interface — then you will be able to insert such reusable component into the process flow. Within such an agent you can use statecharts, events, variables, and so on. See Exit for more information.
If the system you are modeling is complex, it makes sense to identify the components and model the component’s processes separately in different agents. You can define ports (such as subprocess start and end points) and expose them as model component interfaces, hiding the subprocess implementation. At the top-level model, you instantiate and connect these high-level components together. Since each agent can be parameterized and instantiated many times, this also provides a good basis for component reuse within a model or across models.
For example, in an airport model you may want to have components like CheckIn, PassportControl, Boarding, and so on. Within the check-in you may have a CheckInDesk that is modeled once and set up as an agent population consisting of multiple individual blocks. The resources in the model can be shared by different agents, so you can have, for example, a separate InformationSystem component that provides the resources for these subprocesses.
-
How can we improve this article?
-