​

1. Re-validation process

​

Categories

• Validation - rejection on submission = your schedule will be rejected

• Correction after submission and before re-validation = your schedule will be corrected before the re-validation (e.g. typically when an unavailability starts to hit)
• Correction on re-validation = your schedule will be corrected, as part of the re-validation 7 minute before delivery (e.g. typically when your schedule would lead to out of bounds SoC levels but the scheduled power is in the acceptable range)
• Rejection if submitted after re-validation = even soft criteria, which would only lead to a correction as part of the re-validation, turn into hard criteria and therefore a rejected schedule, once the re-validation and correction has taken place

​

Validation process

​

1. Validation (strict)

• Every schedule is validated against a strict set of rules
• If these strict rules are not adhered to, the schedule is rejected

​

2. Correction after submission and before re-validation (soft)

• After successful submission, a sucessfully accepted schedule can still become invalid in a way, that it would not have surpassed the original validation
• That can happen as a consequence of external events such as unavailabilities
• In such cases, terralayr intervenes through a schedule correction before the re-validation

​

3. Re-validation and correction (at 7min before delivery start) (soft)

• The result of your re-validation will either be positive or negative
  • “positive” result
    • your schedule and trading can proceed as normally
  • “negative” result
    • If the dispatch leads to a negative re-validation response, it will be corrected slightly until it no longer violates the set respective rule(s) → it will be corrected in the most minimal way possible, which makes sure the rules are adhered to again

• If your schedule leads to a negative re-validation result, because it violated one of the reasons for invalid schedules , terralayr will slightly correct it
• terralayr will take minimal corrective measures on the following 15 minute period schedule value to ensure feasibility, avoiding over-correction.
• Summed up, terralayr is replacing an infeasible dispatch schedule value of the next 15min period with an adjusted dispatch schedule value that applies minimal corrections.
• The “corrected” dispatch schedule will become the new Active Schedule, readable via API
• Example:
  • we are in q1 and it is 7 minute prior to delivery of q2
  • Your projected State of Energy is at 19MWh at the start of q2
  • Your upper SoC boundary is 100% with a maximum State of Energy available of 20MWh
  • You scheduled a charge of 10MW for q2
  • That scheduled charge would bring the asset to 21.5MWh, which would correspond to an SoC of 107.5% → which is above the SoC limit of 100%
  • The re-validation process would recognise that the schedule would lead to an SoC above the upper SoC boundary and correct the scheduled power in the minimal possible way: from 10MW charge down to 4MW charge over in q2
  • 4MW would bring the asset exactly to 20MWh SoE and thereby to the upper SoC boundary of 100%

1. Option: no active position closing
   • terralayr corrects the schedule in the most minimal way possible
   • the customer can access information on the corrected schedule via API
   • terralayr nominates (and customer counter-nominates) that corrected schedule
   • the customer has two options
     1. close trading positions to make them align with the corrected, nominated schedule, and avoid imbalance
     2. leave the schedule as it is, but face an imbalance between terralayr’s nominations and the trading positions Example:
   • picking up the example from above, your schedule has been corrected from 10MW to 4MW
   • we are 7 minute before delivery and your algo just receives feedback from our API that a schedule correction has taken place and that terralayr will nominate 4MW charge for q2
   • now you could either correct your trading positions from 10MW to 4MW or you could accept the imbalance

​

4. Adjustments after schedule validation (Later than 7min before delivery start but before gate-closure) - (strict)

• After the 7 minute mark has surpassed, the once “soft” validation (> 7min) turn into a “hard” validation, based on the same criteria as within the 7min validation, to maintain flexibility to update dispatch schedules, without losing their correctness as validated at 7min, part. regarding hard A.S. boundaries. A schedule which does not adhere to the validation criteria later than 7minutes before delivery (i.e. after the re-validation and correction) will be rejected.

​

Exemplary timeline of re-validation, correction and adjustments after schedule validation

• This visual of the timeline set out above already includes most of the reasons for invalid schedules

​

2. Majority of reasons for invalid schedules

​

3. Error Response

​

Current error string

{
    "error: "<error text>"
}

​

Error Categories

• auth: the request failed authentication and/or authorisation - maps to 401 or 404 response
• not found: the request was valid, but the requested object doesn’t exist - maps to 404 response
• invalid operation: the request makes sense and the resources exist, but it fails some validation such as power limits - maps to 400 response
• forbidden operation: the request is otherwise illegal by our business logic - maps to 403 response
• error on the platform: a platform outage in some kind of shape occurred - maps to a 5XX response

• Not all of these error texts are shown in full to the user, usually for data-protection reasons such as not showing the details of an authorisation failure if customer A tried to do something with a customer B resource. For most of those, the customer will just get an empty response with a 404 or 500 code as appropriate.
• There are some ways to get an error that do not follow this pattern. Usually these are generic HTTP failures, such as:
  {
      "error": "could not parse request body"
  }
  
  if you have an invalid body.
• Other standard HTTP errors may apply, which should all be in the 4XX range when they amount to user error such as a malformed request, or the 5XX range when they amount to platform outages.

​

Terralayr specific validation errors

• ErrPowerPointStartTimeIsNotAQuarterOfAnHour, “instruction start time must be a quarter of an hour” → the user has sent a schedule update not aligned to the 15 minute grid.
• ErrCannotUpdatePowerPointPastGateClosure, “cannot update instruction after gate closure” → the user has tried to send a schedule after gate closure.
• ErrCannotUpdateNonWholesaleBlock, “cannot update schedule of non wholesale block: <block ID>” → the user has tried to schedule wholesale power on an ancillary block.
• ErrCannotUpdateBlockOutsideOfBlockTimespan, “cannot update block outside of its timespan: update timespan <update timespam> is not fully contained within block timespan <block timespan>”: → the user sends schedule points outside the lifetime of their virtual-asset

​

Outlook

​

4. Examples

1. Example: SoC out of bounds
2. Example: Power limits exceeded – initial submission
3. Example: Power limits exceeded – external event

​

5. Details and footnotes

​

SoC projections

• Defined round-trip efficiencies for charging and discharging
• The lastest SoC including FCR and aFRR activations
• For SoC-forwarding activated virtual batteries, any corrections from the latest SoC reading.

​

Calculation of SoC projection - part of re-validation

• At 7 minutes before delivery, the SoC projection of the next 15min period is validated against the given lower and upper SoC bounds.
• If the SoC at the end of the following 15min period is projected to be below the lower SoC bound, the following correction is applied, with t being the following 15min period:
  IF projected SoE (t) < max(lower SoE bound (t), lower SoE bound (t+1)):
  	delta_energy = max(lower SoE bound (t), lower SoE bound (t+1)) - projected SoE (t) (resulting in positive number)
  	power_correction = 4 * delta_energy (charging is a negative number)
  	adjusted dispatch schedule (t) = max(max_charge(t), dispatch_schedule(t) - power_correction)
  
• If the SoC at the end of the following 15min period is projected to be above the upper SoC bound, the following correction is applied, with t being the following 15min period:
  IF projected SoE (t) > min(upper SoE bound (t), upper SoE bound (t+1)):
      delta_energy = max(upper SoE bound (t), upper SoE bound (t+1)) - projected SoE (t) (resulting in negative number)
      power_correction = 4 * delta_energy (discharging is a positive number)
      adjusted dispatch schedule (t) = max(max_charge(t), dispatch_schedule(t) - power_correction)