Roadmap

Equipped with these considerations we will now start to explore the space of possible structures. For this we define some 'guidelines' which we will follow in search of possible solutions.

• DATA, Domains: One guideline will be the dimension of 'data'. We will look to (i) 'observable behavior' located in a specified 'environment'; we will correlate this with findings in the area of the 'brain' of animals and humans; (iii) we will correlate this with 'phenomenological knowledge' rooted in the human 'consciousness'. The priority has the observable behavior. We will define a list of experimental environments, which are documented in the literature and which we will use as our 'points of reference'.

• THEORY, Models:17.1 The other guideline will be a 'formal theory', which describes our theoretical assumptions with increasing 'complexity'. 'Complexity' is here understood as depending on the number of elements in a structure, the number and kind of relations between these elements as well as the internal structure of the elements. To simplify the talking about these structures we will give them 'names'/ 'labels' which characterize the main property of one structure compared to others (but one has to keep in mind that such labels are strong simplifications and should not be identified with all properties of a structure). A formal theory $TH$ as such is not a working system, it describes many possible instances called models $th$. Thus a model is here understood as one possible realization of the theory. To 'test' the 'validity' of the theory we have to test the possible models against those domains of possible behavior, which are explicitly given in the experimental environments. Even if a model $th$ is in 'agreement' with the selected set of an experimental environment, this does not tell us, whether this model $th$ will 'work' in any experimental environment.
• MEASUREMENT: To validate a model $th$ one has to 'expose' the model in the environment and then one has to observe the performance of the model there. This observation has to be specified by defined methods of measurement, which have to be realized as 'automatic protocols' (log-files). The outcome of the measurements should allow at least a comparison between different models in the same environment with regard to the differing properties of the models, giving 'hints' to the implicit properties of the model. This allows the definition of a relative taxonomy of models. A different kind of evaluation would use experiments which are related to those kinds of experiments, which are used to measure the IQ of children. This would allow an IQ-based taxonomy of models. Other kinds of taxonomy are conceivable.

Thus we will have in any concrete case at least a 3-tupel $\langle th, MEAS, EXP\rangle$ telling us, which experiment $EXP$ has been used to test which kind of a model $th$ (as instance of a theory $TH$) with which kinds of measurement. This leads us to a 3-dimensional matrix as the space of our investigations.

Example: The triple $\langle Random, Steps-Energy, Wood1\rangle$ could be a representation of the configuration: $Random$ is a completely random agent as instance of a theory of random input-output systems; $Steps-Energy$ are methods measuring the number of steps to reach a defined goal in this environment and/ or the amount of energy consumed.$Wood1$ is the 'wood1' environment as described in the paper of Wilson (1994) [422].

The following list is a 'dynamic' list which will grow through time. The list will not include the subject of genetic algorithms because these are following other guidelines^2.12. Furthermore is this table without any details. For all agents we assume a 'built-in' fitness function using at least one 'drive'. The overall fitness function is part of the environment and is not visible to the system.

Roadmap for IESS
MODEL	MEASUREMENT	EXP1	EXP2
Random	time [T], energy [E]	Wood1	Plus-Labyrinth
Reactive	[T],[E]	Wood1	Plus-Labyrinth
Learning Classifier	[T],[E]	Wood1	Plus-Labyrinth
Memory L1	[T],[E] ]	Wood1	Plus-Labyrinth
Memory L1-L2	[T],[E]	Wood1	Plus-Labyrinth
Memory L1-L3	[T],[E]	Wood1	Plus-Labyrinth
Memory L1-L3, signs	[T],[E]	Wood1	Plus-Labyrinth

SIMULATION FRAMEWORK:

For the final implementation of the preceding theoretical considerations we follow the outline of figure 2.7 and we will set up a simulation framework according to figure 2.10. All mentioned modules are communicating by sockets (or equivalent devices). On account of the hight mathematical maturity of the scilab software we will use scilab for the main modules. What will be described below represents a 'start configuration' with a 'machinery' as simple as possible.

Figure 2.10: Simulation Framework for the Engineering of Intelligent Evolutionary Semiotic Systems

• SIMULATION SERVER: A central role plays the environment server. This is a simple function simulating the tasks and laws of th environment. The details will be described in configuration documents; thus a manager can select a configuration document and thereby start a certain kind of environment which stays 'stable' as long no new configuration will be selected. For methodological reasons the environment is completely transparent with its data and functions.
• ENVIRONMENT VIEWER: Because the environment viewer is not part of the environment and will serve many different clients in the future we separate this function from the environment. There is a viewer interface from the environment providing all the data, the viewer needs to display 2D or 3D images from the events in the environment.
• MANAGER: There will be a manager interface which allows the start and stop of a simulation as well as the configuration.
• IO-SYSTEM-CLIENTS: All clients of the environment server are assumed to be input-output systems which can receive messages from the environment and vice versa can send messages to it. For this exists a defined environment interface.
• SECONDARY CLIENTS: It will be possible to use an ordinary IO-Client as an interface for another (secondary) client like a robot or a human persons. In the case that a human person is using an IO-Client as 'Interface' he will appear in the environment like an ordinary client.