CoMPAS is a part of LF Energy’s Digital Substation Automation Systems (DSAS) initiative. The primary goal of the CoMPAS project is to develop open source software components related to IEC 61850 model implementation, specifically for profile management and configuration of a power industry Protection Automation and Control System (PACS).
On January 24-25, the CoMPAS community gathered in Frankfurt, Germany for an in-person meetup. Topics discussed included the goals and objectives of CoMPAS and the related OpenSCD project, the project roadmap, technical architecture, and plan to grow the community.
The attendees agreed this was a productive meeting which provided all community members good insight into progress towards achieving the project’s goals. The group took time to analyze current strengths, weaknesses, opportunities, and threats to the project community, and to define a clear vision moving forward. As is often the case, by gathering in person, individuals who have worked together remotely on this project for months or even years were able to get to know one another better, which will improve collaboration and innovation in the days ahead.
We encourage more developers and utilities to investigate CoMPAS and get involved in the community! The code is hosted on GitHub, there is an active and open mailing list for community discussions, and detailed documentation is available.
If you like to try CoMPAS; Just to go https://demo.compas.energy. Please be aware that the database behind CoMPAS is shared with all users. Like to talk to us? Join one of the CoMPAS community calls. The next one is on 6th February.
OperatorFabric is a modular, extensible, industrial-strength, and field-tested platform for systems operators. OperatorFabric includes several features essential for electricity, water, and other utility operations. The project has just been updated to release version 3.12.0 with a number of bug fixes and new features.
LF Energy Embedded Summit is a new event taking place alongside the all new Embedded Open Source Summit in Prague this June. Speaking proposals are being accepted through February 10 on topics including:
Linux Foundation Energy aka LF Energy is an open-source initiative that supports multi-vendor cooperation in the energy and electricity sectors. The goal is to speed up the process of energy digitalization. In this episode of 2023 Predictions, Antonello Monti who serves at the Technical Advisory Council (TAC) Chair for LF Energy, shares his thoughts on what will happen in the industry this new year.
In 2023, Monti predicts: More real-life application of LF Energy solutions, i.e., the projects have matured enough to deliver concrete results The possibility of opening a data economy in the energy sector Stable growth for LF Energy. This year, LF Energy will focus on building a coherent full picture, ensuring that the different projects harmonize with each other. Companies will need to: Understand and find a different way to approach the energy crisis, which has impacted Europe the most. Adopt digital solutions if they want to utilize renewables, which is experiencing massive growth.
Climate change is a real emergency that needs immediate action. The energy sector is at the center of this change because energy makes everything else run. Utilities produce and distribute energy, so they can be mobilized to immediately reduce the impact on the environment. In this episode of TFiR: State of Energy, Swapnil Bhartiya sits down with Jean-Michel Glachant, Director of the Florence School of Regulation, to talk about the recent LF Energy Report as well as his insights into where the energy sector is headed.
LF Energy Summit is coming to Paris June 1-2, and we are seeking speaking proposals. This event is the place to drive open source technology innovation in pursuit of deep decarbonization. The summit will gather members of the LF Energy community including foundation members, developers, vendors, utility end users and other energy industry stakeholders to learn about LF Energy and its projects as well as to collaborate and share best practices for developing and implementing open source technologies and standards in the power sector. This is your opportunity to share your knowledge with the community and help advance open source technologies to drive decarbonization.
Proposals, which are due by February 17, are being accepted for session types including:
Session Presentation (typically 30-40 minutes in length)
Panel Discussion (typically 30-40 minutes in length)
Birds of a Feather (typically 45-60 minutes in length)
Lightning Talk (typically 5-10 minutes in length)
Tutorial (typically 1.5-2 hours in length)
Topics can include anything related to LF Energy projects as well as open source in the energy sector generally. Sample topics include:
A new report from Dell and Intel entitled “Remarkable energy starts at the edge” explores how “edge computing and 5G can help decarbonize power networks”. At LF Energy, we have always believed that these technologies would be essential to the energy transition and accelerating decarbonization, as demonstrated by our FledgePOWER project, a multi-protocol translation gateway for power systems based on the industrial IoT project Fledge from our sister organization, LF Edge.
The new report emphasizes “how 5G networks and data-driven power grids can combine IT agility and Operational Technology (OT) to deliver sustainable power to an energy-hungry world.” Energy stakeholders are coming to understand that the energy transition represents a wholesale shift in the way power is generated, transmitted, distributed, and used. The future will no longer be centralized power plants sending energy to the grid to be consumed, but instead a two-way system with power being generated and consumed in a distributed fashion. Generation will be distributed, and load balancing will become increasingly difficult as generation and consumption will not always be in sync. Managing this new paradigm requires changes to both IT and OT, including “sophisticated data-driven autonomous systems at the edge of our networks to minimize the carbon intensity of consumed energy.”
LF Energy is already working on many of the technologies required, from improved smart metering standards to reference frameworks for EV charging infrastructure to demand forecasting and more. The Dell/Intel report corroborates these efforts, and further examines how 5G and edge technologies will support them.
Learn more about how to get involved in the work LF Energy is doing in this space.
It is with great sadness that we must inform you that our Executive Director, Dr. Shuli Goodman, has passed away following a long battle with cancer. Shuli founded LF Energy with the goal of prolonging the life of our planet, and gave her all in making that goal come to fruition. Shuli was our captain, our inspiration, and our friend. Her vision and leadership not only built LF Energy to be what it is today, but laid the foundation for what it will be in the future. All the successes we will achieve in the years ahead are thanks to her relentless efforts and unmatched passion. She will not only be remembered, but sorely missed by all in our community, especially by her wife Karen, her son Dakota, her soul-sister Lucy, and the many young people whom she helped nurture and grow. Our hearts go out to them.
We do feel it is important to emphasize that the Linux Foundation remains fully committed to the success of LF Energy as a community, recognizing its critical role for the future of our planet. With the enthusiastic backing of Linux Foundation Executive Director Jim Zemlin, General Manager of Projects Mike Dolan, and our dedicated LF Energy team, the Foundation will continue to support the community’s efforts to ensure a healthy and prosperous future.
When Shuli was unwell several months ago, she drafted a statement to prepare the community for what has now come to pass. This was never issued as she experienced a remarkable rebound and we were confident that she was on the road to recovery. However as every one of us knows, cancer can take unexpected turns. In Shuli’s own words at that time, “If you are wondering what you can do to help me now, the answer is simple – redouble your efforts to grow our community by recruiting more developers and member companies, contributing new projects, improving existing ones, and spreading the word that technology is a major part of the solution to global climate change. I look forward to the day when we can all be together to celebrate our victories, and I appreciate your continued support in making those victories come to fruition.”
The best way we can honor her memory is to make this come to pass.
This post was originally published at https://flexmeasures.io/012-replay-custom-scheduling/.
Version v0.12 of FlexMeasures adds a cool re-play feature and support for adding custom scheduling algorithms!
Actually, this release is a big one with many small improvements, e.g. the CLI for data ingestions have taken a big leap.
See changelog or read on below to read what we added.
REPLAY
FlexMeasures shines in keeping track what was known at what time. In both simulations and real time operation, we found that our partners want to see how the data situation progressed over time.
That’s why we decided to add a replay-button to asset dashboards. It travels through time for you:
Data from Seita’s V2G living lab, played back in FlexMeasures
Where is this useful? We’ve seen this work very well in demos, and to explain why certain schedules were executed half-way, but then the rest got re-written. This happens because when new data arrives (e.g. prices change, an EV re-connects to the charger, etc.), FlexMeasures needs to re-compute the schedule.
This has been in the works for a long time, and now finally released. This work was done in Pull Request 463.
CUSTOM SCHEDULING
To schedule flexible assets is the main premise of FlexMeasures. More concretely, the mission of FlexMeasures is to drastically cut down the development time on any flexibility solution, no matter if an in-built scheduler already is applicable.
Together with the plugin support released in v0.7, this release comes with support for people writing their own schedulers.
This is relevant to researchers and startups who are innovating in the realm of algorithms, but still would like to save development time (and use FlexMeasures as a framework and web application in which to embed their logic).
We will use this internally as well, as it makes any new project easier. Usually, we don’t work on new schedulers in the open ― we prefer to iterate in a plugin first. If the result is great, then it’ll enter FlexMeasures core.
Up until now, schedulers were an internal feature, accessible by an API, but focused on storage flexibility for the main part (we worked on shiftable flexibility in other projects). Opening a core feature up for other use cases is really helpful to arrive at a better design. We’ve completely refactored how schedulers are implemented and how to give them the necessary information (the flex-model and the flex-context), and we’re very excited how this will empower our own work and that of FlexMeasures users.
Almost every project involves getting some historical data read in (e.g. from CSV or Excel files), be it because one uses FlexMeasures to run simulations, or to have a base data set for machine learning purposes (e.g. a forecasting algorithm). This is tough and iterative engineering work.
FlexMeasures has CLI support for this (flexmeasures add beliefs). We tackled several issues to make this work even more developer-friendly:
drop duplicate records with warning
allow configuring which column contains explicit recording times for each data point (use case: import forecasts)
localize timezone naive data
support reading in datetime and timedelta values
remove rows with NaN values
filter by values in specific columns
We also improved its counterpart, flexmeasures show beliefs. We now support:
showing beliefs data in a custom resolution and/or timezone
saving the shown beliefs data to a CSV file
handle showing (and saving) instantaneous sensor data and non-instantaneous sensor data together
This work was done in Pull Requests 501, 521, 519 and 542.
