create a set of simulation drivers and a simulation agent

[rcalvert-cpi]

Kisensum plans to develop a set of VOLTTRON drivers that simulate the behavior of batteries, PV arrays, meters, and generic electrical circuit load. The simulated PV and load telemetry will be based on historical data, and will allow for the substitution of alternative data sets. These drivers will all use a common simulation clock, managed by a separate agent, which can run faster (or slower) than the wall clock, and can be started and stopped at arbitrary times. A reference SimulationAgent will also be provided which runs simulations -- managing the clock, configuring the devices, and then making RPC calls to the devices in order to manage and report upon the behavior of the simulated circuit.

[rcalvert-cpi]

@jhaack, @craig8, @kmonson

I'm seeking your advice on where to put the agents and drivers for this new feature. I've created a SimulationAgent that starts and stops simulations, initializes the drivers, sends them setpoints, and reports on their data. I think that this SimulationAgent should go under examples. But I believe that the storage, PV, load and meter driver modules must live under services/core/MasterDriver/Agent -- is that right? If so, and if the drivers need to take simulation clock readings from a SimulationClockAgent, where should that agent go?

[kmonson]

Hey @rob-calvert,

Usually the way we've handled this before is to create an agent that simulates the master driver's interface (or if actuation is needed along with high performance the actuation agent interface is simulated). Agents that use the data must use the time stamps that are produced by the simulation device data publishes and not the wall clock.

This is how we've run VOLTTRON agents against Energy Plus simulations. The energy plus agent emulates the actuator interface and publishes device data like the master driver. Agents are designed to react to the published data.

If you want to see a relatively simple example you can look at the Datapublisher agent in the examples directory. It takes data from a CSV file and publishes it as though it was coming from a device.

The problem with using the master driver for this is that there is no way to speed up or slow down time in that agent.

[rcalvert-cpi]

Thanks, @craig8, that makes sense. I'll have a look at the Actuator interface. By the way, I've currently set this up such that these drivers request simulated timestamps from a SimulationClockAgent, they don't get them from their DriverAgent. But in any case I'll reconfigure the drivers to run under a separate driver agent (e.g. SimulationDriverAgent), not MasterDriverAgent, enabling me to keep this feature out of platform/core code.

That being the case, would you prefer to see this feature in /examples in the volttron repo, or should it go in voltton-apps? Of course you'd be able to reconsider the answer to that question after seeing the working feature, but I'm wondering where I should direct my pull request.

If you'd ever like to have a look at my work-in-progress, it's checked into the feature/simulations branch of the kisensum/volttron repo.

[rcalvert-cpi]

Apologies for sending that last comment/reply to Craig, I meant to send it to @kmonson.

[kmonson]

Hmm... If it's a series of complete Agents that have a specific purpose I would suggest the applications repository. We don't have anything to support simulation in services/ (and all service agents should be as general as possible) and examples/ is better for showing how to do something in code.

[rcalvert-cpi]

Thanks for that advice, @kmonson. I've created a kisensum/volttron-applications fork and ported my code to a branch there called feature/simulations. I'll send a volttron/volttron-applications pull request when it's ready for prime time.

[rcalvert-cpi]

Pull request has been submitted to the VOLTTRON / volttron-applications repository: https://github.com/VOLTTRON/volttron-applications/pull/33.

[rcalvert-cpi]

Pull request has been merged.