Power TAC Architecture

From powerwiki
Jump to: navigation, search

This page is mostly obsolete. Detailed information on the Power TAC software architecture is maintained on the github wiki.

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.

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 assigned simulation session.

Technology choices

  • Language: All simulation components will be constructed using JVM-compatible languages, primarily Java.
  • Platform: The simulation server will be constructed as a Spring application.
  • Agent-simulation communication: Asynchronous messaging using Apache Active MQ, without transactions or delivery guarantees. Messages will be xml-serialized objects.
  • Build automation: Maven
  • Test framework: JUnit
  • Logging: A state log will record all state change events in the simulation, so that the full simulation can be re-created from the log. A trace log will selectively expose message traffic and internal operations of the server to support explanation and debugging.

Many more details are written up in the developer's wiki on github.

Software Architecture

This section is for architectural principles and choices that are common to the agent and the server.

Server Architecture

A description of the corresponding server architecture can be found in the developer's wiki

Agent Architecture