Power TAC Architecture

Top-level elements
A running PowerTAC configuration consists of
 * 1) a front-end web application that supports user and broker access and competition setup,
 * 2) a simulation server that runs the scenario,
 * 3) the competing broker agents,
 * 4) a visualizer to watch current (and possibly completed) simulations, and
 * 5) a database that holds user registrations, competition setups, and other persistent data needed by the web app and server.

Architectural requirements
Architectural decisions will be driven by a few basic principles:
 * Plugin oriented: As far as possible, all of the domain-oriented behavioral elements of the simulation server and the sample broker shall be "plug-in" conponents, easily replaceable by researchers and developers.
 * Easy installation: The system (server, broker, and log analysis tools) shall be installable without special (sysadmin) privileges in a Macintosh or Unix/Linux environment. Windows users may require some admin privileges.
 * Accessible: As far as possible, dependency structures for the server and broker shall produce a highly-stable "core" with well-documented APIs. The active elements of the server shall be plugins that have no direct dependencies on each other. The goal is to make the server accessible to relatively inexperienced student developers.
 * Flexible data source: Selected portions of the simulation model shall be configurable to use either external (historical) data streams, or internally generated data. For example, a household model might replay load data collected in the real world, or it might generate load data by simulating the behavior of occupants and their appliances.
 * Logging: When the simulation server runs, it shall create a log of its state and all incoming and outgoing messages, so that post-competition analysis will have access to all of the information visible to the brokers, as well as information that determines the server's responses to broker inputs. Ideally this will allow a researcher to reproduce the server's state sequence, thereby effectively re-running a simulation.
 * Repeatable simulations: The record of a simulation run shall contain the information necessary to reproduce the same simulation conditions, including the starting seeds of all random number generators and the types and versions of all model elements. In addition, the simulation server shall be configurable using this information to replay a simulation.
 * Scalability: The simulator shall exhibit acceptable performance when modeling population centers of up to a few million people, with associated households, businesses, industry, and public services.
 * Flexible competition format: Timing, numbers of competitors, and possibly other factors shall be configurable through a web-based competition scheduling interface.
 * Open source: Researchers who wish to install and run their own copies of the competition infrastructure shall not be required to acquire and install proprietary software components.

Priorities
When these requirements (appear to) be in conflict, priority decisions must be made, and recorded here.

Domain Model
Details on the domain, including Customers, the Distribution Utility, the Wholesale Market, the Tariff Market, and others.

Physical Environment Model
Information on the physical environment model, including, api, historical weather data, and forcast weather data.

Interaction Architecture
The primary interaction between the competing brokers and the simulation server and between the simulation server and the visualizer, will be asynchronous messaging, using Apache MQ carrying either binary or XML-encoded serialized objects. Interaction between the simulation server and the web application will be through a REST interface on the web application. In a tournament environment, brokers must also communicate with the web application using a REST interface to acquire the necessary credentials and location of its simulation session.

Technology choices

 * All simulation components will be constructed using JVM-compatible languages, primarily Java and Groovy.
 * The Web frontend will be constructed as a Grails application.
 * The simulation server will be constructed as a Spring application.
 * Build automation?
 * Test framework: JUnit (http://groovy.codehaus.org/Unit+Testing)
 * Logging (status logging, state logging)?

Software Architecture
This section is for architectural principles and choices that are common to the agent and the server.
 * Using REPAST for modeling layer.

Server Architecture
A description of the corresponding server architecture can be found in this section.

General
 * User management
 * Data management

Contracting
 * Basic Principles
 * Tariff functionality
 * Negotiation platform

Execution