Introduction to LAMPS

While languages for the specification of simulation models abound, LAMPS (Language for agent-based modeling of processes and scenarios) is to our knowledge the only one that supports both the description of scenarios and the executable specification of agent behavior for compound agent groups down to individual agents. Existing simulation models are usually extensions of programming languages such as C/C++ (e.g. Maisie (Bagrodia and Liao 1994), the SPaDES environment (Teo, Tay and Kong 1998)) or Java (e.g. SILK (Healy and Kilgore 1997), the SSJ package (L'Ecuyer and Buist 2005)). In contrast, LAMPS is based on high-level Petri nets (Jensen 1992). Thus, LAMPS  inherently supports parallel simulation, and is not just an extension of sequential simulation languages like Maisie, Modsim II (Bryan 1989) or SIMSCRIPT III (Rice, Marjanski, Markowitz, and Bailey 2005). Like other modern simulation languages (L'Ecuyer and Buist 2005), LAMPS can be displayed both graphically and as a rule-set.

Basic concepts of LAMPS

According to its underlying formal model of high-level Petri nets, LAMPS consists of the following four basic concepts:

• Places hold states, i.e. they contain subsets of the agent attributes. The contents of a place is called token and can be of an arbitrarily complex structured type. Places can contain several tokens of different or identical types. Since the whole simulation (incl. troops, environment, and equipment) is modelled as agents, the state of the simulation is described by the contents of all places.
• Actions describe the effects that agents apply to themselves or to other agents.
• Relations denote the links between places, actions, and agents. Relations correspond to the arcs in the Petri net model.
• Agents correspond to the conditions of Petri nets. An agent in LAMPS observes the set of places that have relations to the agent’s actions. Based on these places the agent decides which actions are executed and which parameters should be used.

Generality and scalability

Due to these generic concepts, LAMPS can handle environmental effects like weather, human actions, and physical effects (such as the malfunction of equipment) in the same way. Every action and event is managed by an agent which decides whether and how to execute the action based on its own attributes and other observable attributes. For example, an agent can represent a bridge and decide based on its own status attributes and the locations of other agents whether the bridge should collapse. Note that an agent is usually associated with several actions.

The main difference to flowcharts is that LAMPS is parallel in nature. At any given time more than one place can be filled with tokens and in any place there can be several tokens. This way, actions can be executed concurrently.

LAMPS does not explicitly model time, as it assumes a cycle-based simulation-model. Actions have no duration but are a sequence of short actions that are executed each cycle. Furthermore, LAMPS does not need explicit synchronisation constructs, because ITSimBw uses a cycle-based simulation with global time and synchronisation is achieved via places and conditions. The next cycle is started after all agents have sent their actions.

Furthermore, LAMPS is inherently scalable to different abstraction levels since it is based on high-level Petri nets. Places can be aggregated to form more abstract places. The same holds true for actions. The figure below illustrates encapsulating actions.