Below are some examples of how a worker node can actually work.
A ZEL Request refers to a "Zero Export Limit" request. This request is made by generators or dispatchable assets to set their output to zero, often indicating that they are not able to inject power into the grid for a specific reason.
ZEL Requests can be relevant in several scenarios, such as:
Maintenance: When maintenance is being conducted on a generator, it may need to curtail its output temporarily.
Technical Issues: If there are technical problems that prevent a generator from operating safely or effectively, a ZEL Request signals that they will not produce energy.
Market Conditions: During high levels of generation leading to potential oversupply in the grid, generators might reduce output to maintain stability.
Market operators use these requests to manage the overall balance of the electricity supply and demand, ensuring system security and reliability.
The process starts when a retailer sends their ZEL request which needs to be partitioned accordingly, and forwarded to their respective aggregators. The partitioning process needs to take place in a fully trust-less and secured environment where data are pseudo-anonymized to protect aggregators' business interests.
The ZEL Request Partitioning solution aims to test the above business case. Below are the steps which constitute its solution flow:
Fetch ZEL request from the request sender every 30 minutes
Parse the request into JSON Object
Fetch NMI to aggregator mapping from the NMI Registry. The NMI Registry is a backend API service which simply contains the mapping between NMI and aggregator.
Partition the ZEL request according to the aggregator using the NMI to aggregator mapping
Generate the Merkle Tree root hash of the partitioned data
Submit the root hash to EWX as a vote by initiating the EWX Marketplace App Integration node
The Operating Envelopes Partitioning is the most crucial step in the overall operating envelope passthrough process.
An "operating envelope passthrough" refers to a mechanism that allows for adjustments in the operational limits or envelopes of generating units or electrical systems. These envelopes define the safe operating conditions for various generation assets and network elements, helping ensure reliability and stability in the energy supply.
When unforeseen circumstances arise, such as significant changes in demand, generation availability, or system disturbances, the operating envelope can be exceeded. The passthrough mechanism enables market operators to make necessary adjustments to account for these situations, ensuring that the operation of the market remains secure and efficient. This process is vital for managing risks and maintaining grid reliability amidst changing conditions.
The process starts when the DNSP/DSO sends their operating envelope which needs to be partitioned accordingly, and forwarded to their respective aggregators. The partitioning process needs to take place in a fully trust-less and secured environment where data are pseudo-anonymized to protect aggregators' business interests.
The OEP solution aims to test the above business case. Below are the steps which constitute the OEP solution flow:
Fetch OEP request from the operating envelope sender every 30 minutes
Parse the operating envelope into JSON Object
Fetch NMI to aggregator mapping from the NMI Registry. The NMI Registry is a backend API service which simply contains the mapping between NMI and aggregator.
Partition the operating envelope according to the aggregator using the NMI to aggregator mapping
Generate the Merkle Tree root hash of the partitioned data
Submit the root hash to EWX as a vote by initiating the EWX Marketplace App Integration node
