Power TAC Architecture

Top-level elements
These are the top-level packages that are part of the Power TAC support infrastructure.
 * 1) Domain model : Data representation shared by all the other elements. The domain model must be maintained separately to avoid unnecessary duplication and possible incompatibilities among elements that are expected to work together correctly.
 * 2) Server, consisting of the Power TAC simulator and a web-based front-end.
 * 3) Sample Broker, consisting of an extensible client framework and a sample implementation of a working broker.
 * 4) Log-analysis tool(s), for examining simulation logs after a simulation is complete.

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.
 * Repast Modeling: Domain element models for both server and broker shall be compatible with Repast Simphony. In other words, users shall be able to use Repast Simphony to create new or replacement models for all domain elements in the simulation. In the broker, but not necessarily in the server, the Repast integration shall support the Repast plotting functions.
 * Easy installation: The system (server, broker, and log analysis tools) shall be installable without special (sysadmin) privileges in a Unix/Linux environment (is this even possible in Windows?).
 * 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.
 * The ability to support researchers who wish to use Repast for constructing models is essential,

Domain Model
Details on the domain, including Customers, the Distribution Utility, the Wholesale Market, the Market Intelligence Service, 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 will be asynchronous messaging, using Apache MQ carrying either binary or XML-encoded serialized objects. This is the method between broker and simulation server, between the simulation server and the web frontend, and between the web frontend and the visualizer.

A secondary interaction method is through a shared database, used to communicate configuration data from the web frontend to a newly-started simulation server.

Question: Do we need to use REST between a broker and a web frontend during the login/server discovery process? Ideally this will also be a MQ interaction.

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