The documentation under the alarms module specify a methodology of ordering alarms based on the order in which events were active.
However some OEMs (GE, Vestas) publish a table that defines priority (GE’s priority table, Vestas EEG table). When available, this prioritization method takes precedence over any developed logic around alarm order to determine priority. This ensures that Processed Event order aligns with any counter based methods for availability when energy loss gets calculated using alarm orders to help filter which alarm codes are aggregated.
For example, if a higher priority alarm comes after a lower priority alarm (priority defined in the OEM priority table), the lower priority alarm will be split into two alarms and the overlapping portion classified as Secondary so that the higher priority alarm will be Primary.
Additionally these OEMs (GE & Vestas) do process some faults into a format with start/end time meaning that Renewable Suite can ingest these directly. However, some Faults are missing from these OEM fault prioritization tables (typically focused on alarms not logs/warnings/curtailment). These additional Processed Events that Renewable Suite processes from Raw Events need to also fall into the alarm order correctly.
For example, Vestas communicates curtailment through an internal derate state code. This code has states that Vestas defines as allocated into OEM, noise, environmental, or grid curtailment categories which the Renewable Suite represents as those accordingly in their curtailment categories. For codes not defined in a one of those categories, the Renewable Suite buckets those into Other Curtailment.
One thing to note is that the event codes listed here are processed slightly differently than the above logic in one main way - when Primary Delta type alarms are created, instead of modifying the start time it will split the alarm, letting the overlapping part be classified as Secondary and the non-overlapping part to be classified as Primary Delta.
