Replies: 9 comments 8 replies
-
|
Agenda for 1/28/2022
|
Beta Was this translation helpful? Give feedback.
-
|
Great discussion, some future office hours it would be great if people could show different dashboards, like UI's for VOLTTRON both for an edge device and cloud instance. I'm also in an analyst meetup group where there is a topic every once and a while named BYOP (bring your own plot) where statistics people can show off some fancy chart created in "R" typically for odd ball research work, can we do like a BYOD (bring your own dashboard) on some future date? |
Beta Was this translation helpful? Give feedback.
-
|
Agenda for 2/11/2022
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Using the definition of a microservice as "A microservices architecture is a type of application architecture where the application is developed as a collection of services. It provides the framework to develop, deploy, and maintain microservices architecture diagrams and services independently." from https://cloud.google.com/learn/what-is-microservices-architecture#:~:text=Microservices%20architecture%20(often%20shortened%20to,its%20own%20realm%20of%20responsibility. I would say that volttron is a microservice architecture already.
Anyways, that's my 2 cents. I agree however that it would be very cool to have a version of volttron (and we are getting closer) that you can just spin up with kubernetes whether as a side car or as a normal pod. |
Beta Was this translation helpful? Give feedback.
-
|
Cyber security for dummies, like how can a non cyber security person explain how well VOLTTRON handles cyber security. One smart building platform we have researched mentioned they are SOC 2 Compliance, what the heck is SOC 2 and does VOLTTRON have any cyber security compliance testing? |
Beta Was this translation helpful? Give feedback.
-
|
Here are links to some of what we have done and even some office hours that we have done them in. Internal to PNNL we have access to the checkpoint software described at https://www.checkpoint.com/cyber-hub/cyber-security/what-is-soc-2-compliance/. SOC 2 is a voluntary compliance standard for service organizations, developed by the American Institute of CPAs (AICPA), which specifies how organizations should manage customer data. The standard is based on the following Trust Services Criteria: security, availability, processing integrity, confidentiality, privacy. A SOC 2 report is tailored to the unique needs of each organization. Depending on its specific business practices, each organization can design controls that follow one or more principles of trust. These internal reports provide organizations and their regulators, business partners, and suppliers, with important information about how the organization manages its data. There are two types of SOC 2 reports:
The links below have various levels of details in the threat models and use cases we have detailed. https://volttron.org/publications/secure-software-central-volttron%E2%84%A2-case https://volttron.org/videos/office-hours-%E2%80%93-january-29-2021 https://volttron.org/publications/volttron%E2%84%A2-community-security-report https://volttron.org/publications/volttron%E2%84%A2-threat-profile-volttron-version-80 https://volttron.org/videos/office-hours-%E2%80%93-october-9-2020 |
Beta Was this translation helpful? Give feedback.
-
|
Hi Craig,
Re microservice architecture for Volttron, yes, you are right the basics
are there but there are some differences. For example, it is not possible
to install and configure an agent without having the Volttron platform
running. Most microservices don't have this limitation. Also, microservices
typically are containerized for more modular delivery at the OS level.
Volttron is modularized (or on the way to being modularized) at the Python
level but not at the operating system level. The Volttron Docker repo
really only works if you put all the agents in one container.
I've been working with the Volttron Docker repo and trying to modify it so
that each agent or a collection of agents (like voltron-central and
historian) can be deployed in an independent container, but with the
platform running in the container rather than in a sidecar. A first step.
There are lots of inter-dependencies that need to be teased out. For
example, right now during agent configuration the platform is attempting to
bind the VIP IPC socket twice, once using
ipc://@/home/volttron/.volttron/run/vip.socket and once using the URL tcp://
172.18.0.2:22916 specified in the configuration file, which terminates the
platform execution.
Anyway, once the modularized version is ready, I can switch to that and see
whether I can get the platform up in a container by itself.
Thanx!
jak
…On Wed, Feb 9, 2022 at 10:12 AM Craig ***@***.***> wrote:
Using the definition of a microservice as "A microservices architecture is
a type of application architecture where the application is developed as a
collection of services. It provides the framework to develop, deploy, and
maintain microservices architecture diagrams and services independently."
from
https://cloud.google.com/learn/what-is-microservices-architecture#:~:text=Microservices%20architecture%20(often%20shortened%20to,its%20own%20realm%20of%20responsibility
.
I would say that volttron is a microservice architecture already.
- Each agent is independent of other agents
- Volttron provides a framework to develop, deploy and maintain these
agents independently
- Volttron provides the lifecycle of the agents and communication
channels between agents.
- Volttron uses an alternative mechanism than kubernetes does to
communicate between agents and its core, but its no less an example of a
microservice framework.
Anyways, that's my 2 cents. I agree however that it would be very cool to
have a version of volttron (and we are getting closer) that you can just
spin up with kubernetes whether as a side car or as a normal pod.
—
Reply to this email directly, view it on GitHub
<#2858 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADE62GTTT5AIPYEVISSVA6LU2KVCLANCNFSM5M6YQD6A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Too bad a reply in email doesn't go in the correct spot on the boards! |
Beta Was this translation helpful? Give feedback.
-
|
If someone had a hypothetical deployment like this with VOLTTRON central running on the cloud version 7x:
What would all go into updating the platform to VOLTTRON version 8? Is it just the VOLTTRON instances that need to be updated or would one have to touch a Grafana server and postgres server too? For the newb I am not sure what all would be required, best practices, and options. Like can an older VOLTTRON rev on an edge device communicate to a higher VOLTTRON rev central instance? (vice versa) Would control agents need to be written and/or platform driver config of an existing BACnet system? |
Beta Was this translation helpful? Give feedback.
-
|
The first thing I would do is look at the release notes for the version I would like to update to. https://github.com/VOLTTRON/volttron/releases Ideally those should tell you if there is a huge breaking change. The other thing I would look at is the requirements.py and requirement.txt of the different versions. There is most likely an update of both versions of requirements and/or new requirements. You should run a test on a non-dependent machine. Ideally you would have scripted the installation of your agents and/or volttron so that its repeatable. I found the section for upgrading exiting deployments https://volttron.readthedocs.io/en/main/volttron-topics/VOLTTRON-releases/upgrading-versions.html?highlight=upgrading |
Beta Was this translation helpful? Give feedback.
-
|
Consider the use case of a DER Aggregator where a Volttron Edge device has a "protocol client" agent that communicates with local DERs using IEEE 1547 protocols such as DNP3, Modbus TCP/IP or 2030.5 Unless mistaken, it is my understanding that Volttron protocol agents operate in server mode only. |
Beta Was this translation helpful? Give feedback.
-
|
Andrew,
Another use case is a GEB where Volttron platform is acting as a building
gateway running, say the BACnet agent, an actuator agent, Volttron Central
platform agent and forwarding historian communicating back to a cloud
service over the message bus where a Volttron platform is running the
Volttron Central agent and an SQL historian recording data into a database.
The pub/sub message bus makes such a distributed architecture possible.
jak
…On Fri, Feb 11, 2022 at 2:21 PM Andrew Wozniak ***@***.***> wrote:
Consider the use case of a DER Aggregator where a Volttron Edge device has
a "protocol client" agent that communicates with local DERs using IEEE 1547
protocols such as DNP3, Modbus TCP/IP or 2030.5
Unless mistaken, it is my understanding that Volttron protocol agents
operate in server mode only.
—
Reply to this email directly, view it on GitHub
<#2858 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADE62GUUFVOXLW7OONRTYZTU2WDVHANCNFSM5M6YQD6A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
If anyone was on the office hours call 2/12 where @rlutes presented on the ILC algorithm, I think it would be really cool to see advanced use case for ILC like what was discussed at the end of the presentation specially for Grid or GEB purposes. A quick walk through on setting up the ILC would be great geared towards some sort of use cases like this below:
|
Beta Was this translation helpful? Give feedback.
-
|
Can we ever do a Office Hours where @rlutes (Robert) to demo use case for the EnergyPlus agent? What's the difference between the 3 agents in the simulations folder? Are these all digital twin concepts used like model predictive control? What's the easiest to implement? What's the use cases? If the ILC agent is more a statistics/analytical approach to limiting a building electricity demand in real time control, do these simulation agents to the same thing but more of a Physics model? If the simulations agents can be setup with a comparable use case as ILC which performs better? Real curious.... Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
The simulation agents are used to do co-simulation with each respective tool. For example the EnergyPlus agent allow one to pull data from EnergyPlus into VOLTTRON and send control signals back to EnergyPlus. Then, one can test control or other building algorithms against these simulations (such as ILC). |
Beta Was this translation helpful? Give feedback.
-
|
Is there a lot that goes into setting up EnergyPlus to be interactive with a Python environment? |
Beta Was this translation helpful? Give feedback.
-
All, please post idea for topics you would like to cover such as:
We'll use this space to track upcoming agendas. Thank you
Beta Was this translation helpful? Give feedback.
All reactions