A Simulated environment for learning agents - Specification
From Princípy tvorby software
Prepared by Ladislav Benc
Introduction
Purpose
The purpose of this product is to provide a comprehensive, easy-to-use server, simulating an interactive environment. It is to be used by learning agents, mainly for the purpose of research in the field of artificially intelligent agents, particularly those learning to reason about their current environment and adapting to it.
The simulation will run as a server on the .NET platform, communicating with agents through the TCP/IP protocol suite, thus allowing the greatest possible separation from the agent. Various data about the simulation will also be available as a web page.
An agent application allowing manual exploration of the simulation world will also be provided. It will enable its user to directly issue commands and see a visualization of the world. In this document, this application will be from now on referred to as the “Visual client.”
Intended Audience
This document is meant to provide an overall description of this product to the end users in the field of AI research. It is recomended to them to read the Overall description chapter and the Appendix A. Developers should pay closer attention to chapters providing a more precise description of the software - especially in chapters External interface requirements and System features.
References
Čertický, M. (2009). An Architecture for Universal Knowledge-based Agent. Retrieved from http://breakk.no-ip.org/index.php?action=publications
Overall Description
Product Perspective
This product is intended for use in research in artificial intelligence, at the Commenius University in Bratislava, Faculty of mathematics, physics and informatics. The main purpose is to provide a simulated environment for experiments with an universal, environment-independent agent design, as presented in (Čertický, 2009).
It may also be secondarily used for any other agent-related development purposes, as the environment is not bound to any specific agent behaviour, or for educational purposes.
Product Functions
Administrator must be able to:
- Change the server settings (offline)
- Remove (‘kick’) a connected client
- Start or shut down the server
- Monitor server statistics
- Change the list of available virtual hardware, available to clients
- View a visualization of the whole simulated world
- View logs of activity on the server
- View logs of activities in the simulation
Remote client must be able to:
- Connect to a server, if it running and not full
- Negotiate the details of connection/communication
- Select the desired pieces of simulated hardware, prior to entering the simulation
- Once the simulation is entered, the agent can:
- Send commands to execute actions
- Request and receive observations about the state of environment and actions performed
- Communicate with other agents, if applicable
- Receive information about its actions in the world so far
The Visual client must be able to:
- Enter a simulation
- Select the desired pieces of simulated hardware, prior to entering the simulation
- Send manually issued commands
- View visualization of a part of the simulated world, as perceived by the agent.
User Classes
There are three user classes: the system administrator, remote client and the visual client. Their possible actions are depicted in Appendix A.
Operating Environment
All the applications will run under the managed .NET environment. Implemented as pure CLR assemblies, they will run on any operating system providing enough support. Development and tests will run on Windows Vista and Windows 7.
All the necessary dependencies will be distributed with the applications, and no external services will be called. Therefore, they will be quite independent of the rest of the system.
User Documentation
Along with the software, these documents will be provided:
- Online help
- Offline user manual
- Some basic tutorials on using the agents, provided interfaces and communication with the server.
All of them will be realized as a wiki.
Assumptions and Dependencies
The project will use only a few third-party libraries; therefore will not have a lot of external dependencies.
So far, the only one expected to be necessary is a JSON data format handling library.
External Interface Requirements
User Interfaces
The user interfaces will mostly serve only as a visual settings manager, as the core of the application lies in the simulation.
The Visual client will also provide a list of available actions, with the ability to select one of them and execute it.
Communications Interfaces
The client-server communication will be facilitated by the TCP/IP protocol suite. Each agent will be able to specify, what format it wants to receive messages in (the available formats being predicate-per-line text, or JSON.)
The server will also provide a report of its current status as a web-page. This will only provide a read-only, non-interactive summary (will not allow any remote changes, etc).
System Features
This section contains descriptions of the system features outlined above.
Administration features
Change the server settings (offline)
Description and priority
The administrator can adjust all internal simulation features, including active concurrent client limit, enabling or disabling effects of weather, inter-agent communication, modify weather model behaviour, et cetera. This list is non-exhaustive, as the need for more properties may arise during the implementation and testing process.
The changes to settings will be done either via a GUI, or a direct edit of the JSON settings files.
Priority: normal.
Functional Requirements
In order for these modifications to apply, the simulation must not be currently running. While changing the settings by modifying a JSON file, the administrator has to ensure only valid data are entered. If an inconsistency is encountered, the application will show an error, and if possible, substitute suitable default values.
In some cases (e.g. weather transition probabilities), heuristics could be employed to ‘sanitize’ the invalid data; however, as this might result in confusion and possibly unwanted software behaviour, these will not be implemented and a critical error will be thrown instead.
Remove (‘kick’) a connected client
Description and priority
The administrator can view a list of all of the currently connected clients, and decide to forcefully remove any of them at any given time.
Also, a message saying why a client was removed can optionally be specified. If that is the case, the provided reason will be entered into the server log and sent to the client being disconnected.
Priority: low. This feature will not be needed too often.
Monitor server statistics and logs
Description and priority
Various data about the server and simulation behaviour will be logged. Also, actions of agents in the world will be monitored and logged. This will be useful while debugging, in cases of unexpected errors, or while gaining insight into an average agent’s behaviour and action usage (i.e., how many times an action is performed, etc.)
These will also be available through the aforementioned web status report.
Priority: normal.
Change the list of available virtual hardware, available to clients
Description and priority
Upon connecting, every remote client will be able to select a set of sensors and actuators from a list specified by the system administrator. Admin can enable or disable any of those, before the simulation starts and the agents connect.
Priority: normal.
Functional Requirements
The available items are specified in external scripts defining their behaviour and loaded at server start-up. They are taken from a folder specified by server settings.
View a visualization of the whole simulated world
Description and priority
For better overview of the happenings in the simulated environment, simple visualization can be turned on. It will not provide any interactivity.
Functional Requirements
As visualizing larger worlds with more objects can be a computationally heavy load on the system, performance of the simulation itself could be hampered on older (slower) machines.
Remote client features
Communicate with other agents, if applicable
Description and priority
The server may (or may not) allow communication between agents. If enabled, each agent will be able to send a message to every other agent. This is particularly useful in multiagent scenarios.
Priority: normal.
Receive information about its actions in the world so far
Description and priority
Each client can receive information about usage statistics of its own actions performed in the world during the current run of the simulation.
Priority: normal.
Visual client specific features
Send manually issued commands
Description and priority
The visual interface shows a list of available actions the user’s agent can perform. Once the user selects an action, it is sent to the server for execution.
Priority: high. This feature is important, as it will allow developers of agents to interactively learn about the simulated environment.
Functional Requirements
To execute an action, it first has to be chosen from a list of action names. Next, all the required parameters have to be entered (their arity is expected to be up to 2), and then the command is sent.
If it happens to be invalid (e.g. because the user specified invalid arguments), the server sends back an error message, which causes the Visual client’s UI to notify the user about this failure.
View visualization of a part of the simulated world, as perceived by the agent.
Description and priority
As the agent’s sensory data are received by Visual client, the visual view of the world is updated.
Priority: normal.
Functional Requirements
As the agent does not usually see the whole world at the same time, the visualization may differ from the actual world state. This is not erroneous behaviour, but a feature of the imperfect sensors.
Performance Requirements
The server should be able to respond to any client request in fewer than 100 milliseconds, if the number of active clients does not exceed the expected 10 clients in total. The only performance bottleneck can be encountered when too many objects are updated at once; however, this case will be rare, and the underlying platform does provide the possibilities to optimize execution speed, should a need arise.
Safety Requirements
In case of a network error, when a remote agent is disconnected, all its data will be discarded and it will be removed from the simulation.
Similarly, should the server running a simulation encounter an unexpected error, no warranties of data persistence are given.
Security Requirements
As this is an open research project, security is not of great importance. No encryption whatsoever will be used. Any agent will be allowed to connect (if the server is not already full), without having to provide any authentication details.
Software Quality Attributes
On the source code level, all files are required to be easily readable and maintainable, and also documented when necessary.
Special emphasis is placed on the configurability of the product – all environment- and simulation-defining constants are to be manually changeable, while the server is not running.
Correctness is also important. All output sent to clients is required to be consistent with the previous world state and current actions. This is vital for the client agents to be able to reason about the world effectively.
