|
Poses++ Documentation - Terminology |
A
- Animator
- Poses++ client component to observe an experiments by means of a graphical layout specifically for the model. - Chapter: Animator. The animation player is a 2D vector grafic display engine.
- Arc
- Syntactic element of Poses++ to define the rule of a transition. - Chapter: Arcs
B
- Breakpoint
- A breakpoint stops the simulation on a defined event.
- Build
- building a model invokes the Poses++ compiler at first and a C++ compiler thereafter. The result is a binary model library which can be loaded to a simulation server.
C
- Client/Server interface
- Poses++ components are separated in client and server components. They talk to each other via ASCII commands, answers and events sent over TCP/IP connections. The concrete description of the commands and answers will allow to develop your own Poses++ client components as project specific parts of your work or as common usable components besides the Poses++ distribution. We did not yet publish this documentation because of changes we plan for the next future. But if you do not want to wait please ask us directly we will send you this documentation via e-mail on demand.
- Code file
- Code files *.cod are adequate C++ files of their Poses++ source files *.pos. The creation of *.cod files is a task of the Poses++ compiler. Such files include those functions into a model which the simulation server needs for evaluation the fire rules. Code files are necessary to build the model as shared loadable binary code.
- Compiler
- The Poses++ compiler is a program (posppc/posppc.exe) to check the syntax of Poses++ files and to create Code files from Poses++ source files.
- Configurator
- Poses++ client component to define various descriptions and evaluations (menus, filters, sheets, charts and so on) and consequently to observe and to interpret an experiment in an user specific way. In the actual version of Poses++ this component isn't completely implemented. - Chapter: Configurator
- C++ Compiler
- A C++ compiler is necessary to generate from Code files generated by the Poses++ compiler and additionally from C/C++ user moduls in the first step object files and in the second step the binary model code. Poses++ supports various C++ compiler and releases (see also: Hardware and Software Environment).
D
- Daemon
- Poses++ server component (posppd/posppd.exe) to start, to manage and to close all simulation server tasks on the target host. On machines running MS-Windows® the IDE is able to start the daemon on the local machine automatically. For machines running a UNIX operating system we published the simulation server binaries seperately. Thats why you have to start the daemon directly before this machine can be detected as possible simulation host in your network.
E
- Event
- Smallest unit of data changes during the execution of simulation models. Events are the fire start of a transition or the corresponding stop. Events are also the destruction of tokens or the generation of new ones.
- Experiment
- An experiment is a simulation server task with a loaded model library. Every experiment can be assigned a name creating the experiment. Different simulation experiments can run on the same machine simultaneously.
- Experiment-Tool
- The Poses++ IDE is an experiment tool to observe and to analyze a experiment in details.
F
- Fire rule
- Every transition has a fire rule depending from it's arcs and theire expressions. First if all conditions of these arcs are true, the transition fires. In Poses++ the transitions can fire parallel to each other and they can also fire parallel with themselves unless the parallelism of the transition is limited.
- Fire step
- Technique to continue the simulation by a transition fire and so a simulation runs only for the successful fire of one transition.
- Future event
- A transition can be timed and input and output arcs of a transition can also have a timed behaviour. All such timed operations are calculated as positive time values. Thats why the corresponding Event will happen in the future. All events for the future are stored in the event list of the simulation experiment.
G
H
- History
- A history is a set of {time, value}-tupels in order to look at past simulation data. At present the history can be switched separatly on or off (default) for token count information by a predicate and for parallelism information by a transition. Poses++ supports the display of histories by charts. - Chapter: Histories
I
- IDE - Integrated Development Environment
- The Poses++ IDE (poside.exe) is an integrated development environment for modelling and experiment control for simulation models. Models are managed within projects.
- Instance
- The modelling philosophy of Poses++ is type based. Types for modules are similar to C++ classes. Instances of such types can be defined inside other types. One module type have to be selected to create the simulation model as such module instance.
J
K
L
- Layout-Editor
- Poses++ client component (poslay.exe) to design a graphical animation layout. - Chapter: Layout Editor
M
- Match variable
- Poses++ syntactical element to describe non-constant rules. - Chapter: Match variable. Please accept a match variable differs from a variable in a C, PASCAL or Java program. A match variable has no address in the computers memory and a match variable can have the state to be not assigned!
- Model
- Regarding the simulation technique a model is a suitable reproduction of real or planned systems for simulative investigations. The descriptive means of Poses++ is a form of the predicate-transition-nets to describe such a reproduction.
- Model builder
- The Model builder is a functionality of the Poses++-IDE able to create with the help of Poses++ compiler from all Poses++ files within a Poses++ project a model library. - Chapter: Create a Model
- Model library
- A model library contains the binary simulation model code. This one is a dynamic link library (*.dll) or a shared library (mostly: *.so) - dependent on the operating system of the target host. A model library is not the model you can simulate! It contains binary exectuable code for each module you specified at source level. A model library can contain many of such module code sections. Later when a simulation server was started the client ask the simulation server to load such a model library dynamically using the server command "LinkCode filename". After this step the simulation server is able to offer all module types from the model library to be instanciated as a model.
- Module
- Poses++ syntactical element to describe module types. - Chapter: Module
N
O
P
- Poses++
- Software tool to support the development and fast simulation of very large models. The name Poses++ stands for the German description Prädikat-Transitions-Netz orientiertes Simulations- und Entwurfs-System (which means in english: predicate-transition-net oriented simulation and development system).
- Predicate
- Syntactic element of Poses++ to describe a model state. - Chapter: Predicates. A predicate can store black tokens or tokens with data types. Predicates with data types can be parametrized by an access algorithm additionally.
- Project
- A Poses++ project is a specific directory containing all necessary information to develop a simulation model. Moreover Poses++ identifies itself whether a directory is a Poses++ project or is not. An existing and valid file called project.ppp stored in a directory identifies this directory as a Poses++ project. To copy a Poses++ project you can easily copy the directory to another place and you can also change the the name of the directory if you want.
Q
R
S
- Simulation server
- The simulation server is a program (pospp / pospp.exe) able to load one ore more model libraries and able to execute the simulation model. This program is started and managed by the Poses++ daemon on a host machine. On one machine can run as many simulation server tasks you want or your machine are able to run :-) respectively. The simulation server on an alpha hardware under Digital® UNIX is a 64-bit implementation. For all other platforms we build the simulation server as 32-bit implementations.
T
- Target host - server machine
- Computer on which runs a Poses++ daemon and simulation server tasks. - Chapter: Server Configurations
- Text-Editor
- Poses++ client component to edit simulation models on source level in text format.
- Time step
- Technique to continue the simulation at regular intervals refering to the current time unit of the simulation server. The simulation server stops at the begin of the next period of time. But all events of that period don't executed yet.
- Time unit
- Poses++ supports the following units of time: tic, year, day, hour, min, sec, millisec (ms), microsec and nanosec (ns). The unit tic stands for "no unit". In Poses++ is valid: 1year=365days, 1day=24hours, 1hour=60min, 1min=60sec, 1sec=1000millisec, 1millisec=1000microsec, 1mikrosec=1000nanosec. Chapter: Timed Transitions. The time is a very important property of a simulation system. To avoid inaccuracies Poses++ implements a pure integer time algorithm. But to handle nanoseconds besides years in different models Poses++ is able to detect the smallest time unit used in the modules necessary for a model - this smallest unit will be assumed to be equal to tic. If not time unit was specified tic is also the smallest one. But if one module uses the unit sec and another one in a model needs the unit millisec the simulation server will set millisec to be equal to tic. So the simulation server is able to find the best way to represent all times in a model as an integer. In the implementation the Poses++ server will use 53-bit of the double data type on 32-bit machines and 64-bit on native 64-bit processors (Alpha) to implement this integer behaviour.
- Trace - event information
- A trace tells about a defined event without stoping the simulation.
- Transition
- Syntactic element of Poses++ to describe the model behaviour by changes of the model situation. - Chapter: Transitions.
- Type
- All model descriptions in Poses++ are based on a type concept. The most important type is the module type. All dynamic data in Poses++ models are token based on token types.
U
V
W
- Watch - value information
- A watch always shows an actual value of an attribute for a certain instance.
X
Y
Z
|
 |
