Eclipse VOLTTRON™ History and New Features JEREME HAACK Pacific Northwest National Laboratory volttron@pnnl.gov #connectedcampus | PNNL-XXXX January 17, 2019

VOLTTRON™ Timeline VOLTTRONTM Releases PNNL EV Demo BEMOSS RTU Network 6.0 - Message Bus Independence - Resource 5.0 - Improved Performance and usability 4.0 - Security - User Interface 3.0 - Unified VOLTTRON 2.0 - VOLTTRON (w/ patent) - VOLTTRON Lite 1.0 - Released by FPGI FY13 FY14 FY15 FY16 FY17 FY18 PNNL EV Demo BEMOSS RTU Network First User Forum NREL ESIF 2nd User Forum Quality Logic Implements Transactive Node NREL ESIF 3nd User Forum Transactive Campus BIRD-IP GMLC Usage Buildings Challenge TWT Deployment Intellimation deploying 100 instances NW Tech Meeting 4th User Forum VOLTTRON™ Foundation January 17, 2019

Pillars of VOLTTRON™ Flexibility - The platform should be flexible to meet requirements for a varied set of solution spaces Deployment – Can be installed on a variety of hardware with differing capabilities Topology – Can be arranged in differing topologies to meet the needs of specific implementations Services – Components of the platform can be easily added to/replaced Usability – The platform should be both easy to use and straightforward to develop Development – It should be clear how to develop agents and services for the platform. Developers should have the insight and feedback to ease development End User – The platform should provide services that enable the development of high quality user interfaces to simplify deployment, installation, and management of the end solution. Scalability – The platform should enable deployments at scale through proper deployment and division of resources Number of platforms Number of agents Number of devices Security – The platform must be secure to protect the devices being controlled and not provide a “backdoor” Platform integrity – The platform must protect itself from subversion Infrastructure integrity – Recommendations for securing the underlying resources used by the platform Interoperability – The platform must work across vendors and protocols and provide capabilities to simplify these interactions Data standard – A standard data format and naming convention would allow applications written by different organizations to easily talk with each other and the devices being controlled. Interface library – A library of interfaces allowing the platform to communicate with a variety of devices through standard (Modbus, BACnet, etc.) or custom protocols. Flexibility - The platform should be flexible to meet requirements for a varied set of solution spaces Deployment – Can be installed on a variety of hardware with differing capabilities Topology – Can be arranged in differing topologies to meet the needs of specific implementations Services – Components of the platform can be easily added to/replaced Usability – The platform should be both easy to use and straightforward to develop Development – It should be clear how to develop agents and services for the platform. Developers should have the insight and feedback to ease development End User – The platform should provide services that enable the development of high quality user interfaces to simplify deployment, installation, and management of the end solution. Scalability – The platform should enable deployments at scale through proper deployment and division of resources Number of platforms Number of agents Number of devices Security – The platform must be secure to protect the devices being controlled and not provide a “backdoor” Platform integrity – The platform must protect itself from subversion Infrastructure integrity – Recommendations for securing the underlying resources used by the platform Interoperability – The platform must work across vendors and protocols and provide capabilities to simplify these interactions Data standard – A standard data format and naming convention would allow applications written by different organizations to easily talk with each other and the devices being controlled. Interface library – A library of interfaces allowing the platform to communicate with a variety of devices through standard (Modbus, BACnet, etc.) or custom protocols. January 17, 2019

How VOLTTRON platform works Home Assistant January 17, 2019

Historian Framework Message Bus Framework handles collecting data from the message bus for storage Simplifies creating specific instance Setup How to store data How to retrieve data Maintains a cache until data stored Numerous supported databases with more being contributed Data can also be sent to cloud services or another VOLTTRON instance Historian VOLTTRON January 17, 2019

Driver Framework Framework simplifies process. Fill out methods for: Setup Reading values Sending commands Growing list of existing interfaces Flexible options for collection rate and organization of sensor points Deployer edits configuration files, no need to code for different devices Message Bus Driver SEP2.0 January 17, 2019

Since Last We Met… January 17, 2019

Drivers Incorporated ModbusTK driver SEP 2.0 incorporate DNP3 accepted Incorporated OpenADR VTN and VEN agent Ability to group devices to allow load balancing of scraping to avoid overloading devices and networks (developed to alleviate issues collecting from MS-TP trunk) January 17, 2019

Message Bus Message Bus Message Bus performance improvements A major refactor of the message bus improves the speed of publishes by 4 - 10 times Requires no changes to existing agents and services to use Simplified Multi-Platform Platforms can be configured as peers allowing their topics to be shared across participating platforms Agents can publish/subscribe to remote topics without knowing which platform the topic is on January 17, 2019

Historian Historian Template Historians utilize configuration store Crate historian solidified and ready for deployment ForwardHistorian improvements including option to pause forwarding DataMover historian provides an alternative to FowardHistorian for remotely storing data without needing to republish it January 17, 2019

Agents and Services Agent Template Market service agent and base agent with examples A contributed Kafka agent Tagging Service Topics can be assigned metadata tags Agents can lookup topics by these tags to dynamically configure their subscriptions Documentation Jupyter training notebooks for quickstart of learning VOLTTRON Message bus debugging tool to provide visibility during application development FNCS Integration now a subsystem January 17, 2019

Notable Fixes Fixed an agent lifecycle bug which could cause agents to not shut down cleanly. This could affect historians and lead to data loss VOLTTRON Central BACnet device discovery code refactored Significant ForwardHistorian and DataMover memory and file handler leak fixed. Affected spotty connection and cases where the target platform may be disconnected for long periods of time. January 17, 2019

Upcoming September - 6.0 Release Candidate December/January – 6.1 FY19 Change of Value BACnet driver Security Assessment and Code Review Message Bus Independence… next presentation! December/January – 6.1 New Weather agent that allows use of any weather service Securing Configuration Store Updating formerly “restricted” features Secure agent packaging Resource contracts Visibility Platform status information Agent configuration UI FY19 Upgrade to Python 3 January 17, 2019

For More Information: http://volttron.pnnl.gov US Government should focus on Core, Foundational Areas of connected devices and buildings…allowing for scalable, market-based solutions to develop in the form of applications – VOLTTRON is DOE’s open source, cyber secure controls platform. For More Information: http://volttron.pnnl.gov http://bgintegration.pnnl.gov/volttron.asp and volttron@pnnl.gov https://github.com/VOLTTRON/volttron/wiki January 17, 2019