Development Roadmap

The material on this page is from 2010. All development content has been moved to the github wiki.

Architecture

Decisions about overall structure of the system. Some of these decisions are already made, and many are yet to be decided.

1. Information architecture - purpose, content, and format of data shared by server, broker, and offline analysis tools.
2. Interaction architecture - how the server interacts with brokers, visualizers, and potential other tools.
3. Server platform
4. Server structure - major modules, plugin architecture, integration of Repast.
5. Broker platform
6. Broker framework - major modules, plugin architecture, integration of Repast. Kang has written up a high-level modular and behavioral description of a broker framework.
7. Game visualizer - dynamic display of broker and environment status during a run.
8. Game analyzer - visualize a game that's already been played, access data details in various useful ways.

Server

This is an approximate sequence, based on discussion 2010-09-22, updated 11-6.

1. Separate existing server into backend Spring-based simulation server and frontend Grails-based web app, connected with ActiveMQ.
   1. Priority 1 is getting Spring-based simulation server up and running, which might initially read local config file for initialization. Carstenblock 12:47, November 9, 2010 (UTC)
   2. Web front end is of lower priority as teams wanting to participate don't need it initially. Carstenblock 12:47, November 9, 2010 (UTC)
   3. Server Database might not be necessary if competition data is completely logged into textfiles. Carstenblock 12:47, November 9, 2010 (UTC)
2. Work out basic Spring config that loads Repast agents and allows them to see each other in a network projection using local config file. Only Repast agents need to be accomodated; we do not need Repast charts and graphs. What about Repast logging?
   1. Repast logging is basically log4j logging and thus should be integrated with the standard spring logging. The difficulty stems from RePast's static inclusion of log4j library in repast jar. Carstenblock 12:47, November 9, 2010 (UTC)
   2. Spring OSGI bundles might provide the add-on / plugin functionality we are looking for. The question is if the repast listeners (basically the network projection) could be mapped to the OSGI service registry, which is normally used to expose certain service methods across different osgi bundles (aka repast modules). Carstenblock 12:47, November 9, 2010 (UTC)
3. Implement broker login, Repast-compatible simulation start.
4. Establish preliminary APIs for Wholesale Market, Distribution Utility, Broker Profile.
5. Implement simple PDA market for the Wholesale Market. Can we use the existing Liquidity Provider? Does that need to be a separate component?
6. Implement dummy Portfolio with fixed power consumption profile and prediction (using the KIT data server).
7. Get the Repast-based agent prototype working with the new server setup.
8. Implement Bank, Broker accounts. Update accounts based on Wholesale Market transactions.
9. Implement Distribution Utility to perform balancing accounting functions, interacting with Broker accounts in the Bank.
10. Define API for Customer models and Market Intelligence Service.
11. Implement Customer model that is sensitive to price changes.
12. Implement tariff that allows Broker to adjust prices, use this as at least part of fixed Broker endowment.
13. Update Broker prototype to adjust prices.
14. Add multiple Customer Population models and Market Intelligence Service.
15. Update history and prediction elements of Portfolio to use data from subscribed Customer models.
16. Update Broker prototype to offer multiple tariffs.
17. Update MIS to match Customers to tariffs, adjust Broker Portfolios, charge appropriate fees.
18. Implement Contract market and contract customers.
19. Make Customer models environment-sensitive, add Environment model.
20. Allow Brokers to get weather forecasts.

For current development blueprints, see Server Blueprints.