Power TAC Architecture
Contents
Top-level elements
A running PowerTAC configuration consists of
- a front-end web application that supports user and broker access and competition setup,
- a simulation server that runs the scenario,
- the competing broker agents,
- a visualizer to watch current (and possibly completed) simulations, and
- 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.
- 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, eventually.
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.
Information Architecture
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
Contracting
Execution
