Scheduling functionality

[jadamcrain]

Handle schedules by using a common component that can break control schedules into multiple messages, dispatched at the desired time to DNP3 and Modbus.

[jadamcrain]

@larrylackey @emgre:

I've prototyped some splitting code and related tests for ESSControl profile here.

Given the following input profile:

controlMessageInfo {
  messageInfo {
    identifiedObject {
      mRID {
        value: "cef0f0e2-847a-439b-b638-333cbc15c0a4"
      }
    }
    messageTimeStamp {
      seconds: 42
    }
  }
}
ess {
  conductingEquipment {
    mRID: "accaa428-6c1d-49b5-825f-0c42886f1ea0"
  }
}
essControl {
  essControlFSCC {
    controlFSCC {
      controlScheduleFSCH {
        ValACSG {
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_A_net_mag
              value: 47.3
            }
            startTime {
              fraction: 1
              seconds: 23
            }
          }
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_PhV_net_mag
              value: 103
            }
            startTime {
              fraction: 2
              seconds: 24
            }
          }
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_W_net_mag
              value: 104
            }
            startTime {
              fraction: 2
              seconds: 24
            }
          }
        }
      }
    }
  }
}

The function splits this into the part to be executed now:

now:
controlMessageInfo {
  messageInfo {
    identifiedObject {
      mRID {
        value: "cef0f0e2-847a-439b-b638-333cbc15c0a4"
      }
    }
    messageTimeStamp {
      seconds: 42
    }
  }
}
ess {
  conductingEquipment {
    mRID: "accaa428-6c1d-49b5-825f-0c42886f1ea0"
  }
}
essControl {
  essControlFSCC {
    controlFSCC {
      controlScheduleFSCH {
        ValACSG {
        }
      }
    }
  }
}

And two profiles to be executed in the future:

controlMessageInfo {
  messageInfo {
    identifiedObject {
      mRID {
        value: "bc274bc7-7518-4930-a0cf-61e8c77e7077"
      }
    }
    messageTimeStamp {
      fraction: 1
      seconds: 23
    }
  }
}
ess {
  conductingEquipment {
    mRID: "accaa428-6c1d-49b5-825f-0c42886f1ea0"
  }
}
essControl {
  essControlFSCC {
    controlFSCC {
      controlScheduleFSCH {
        ValACSG {
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_A_net_mag
              value: 47.3
            }
            startTime {
              fraction: 1
              seconds: 23
            }
          }
        }
      }
    }
  }
}

controlMessageInfo {
  messageInfo {
    identifiedObject {
      mRID {
        value: "4552cb1c-59d9-4ddd-869d-e8e1d07f8dc8"
      }
    }
    messageTimeStamp {
      fraction: 2
      seconds: 24
    }
  }
}
ess {
  conductingEquipment {
    mRID: "accaa428-6c1d-49b5-825f-0c42886f1ea0"
  }
}
essControl {
  essControlFSCC {
    controlFSCC {
      controlScheduleFSCH {
        ValACSG {
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_PhV_net_mag
              value: 103
            }
            startTime {
              fraction: 2
              seconds: 24
            }
          }
          schPts {
            scheduleParameter {
              scheduleParameterType: ScheduleParameterKind_W_net_mag
              value: 104
            }
            startTime {
              fraction: 2
              seconds: 24
            }
          }
        }
      }
    }
  }
}

Note how the conductingequipment.mRID is preserved, the messageinfo.timestamp is set to the control time, and the messageinfo.mRID is freshly generated.

Thoughts? This is just for the commonmodule::SchedulePoint. We'd have to do similar splitting for the ESS specific schedules (regular and island).

I believe that some template programming would allow us to have a single "split" method template, and the only thing we'd have to write per-profile would be some metadata in templates for the other profile point types, but hard to say before its tried.

[larrylackey]

Any per-control profile code is concerning, taking us back to the days of coding for each new profile. Is it possible to treat the fields in ESSPoint for example as an opaque blob?

[jadamcrain]

To be clear, this is just a prototype. Before we can generate anything or leverage templating, we need to know what it looks like for single control profile.

There is still a tiny bit of code that has to be written when adding a profile, but we've minimized the burden of it by leveraging code generation and some template magic. I believe we can do the same here, but it's too difficult to start with this approach directly. You have to know what it is you're generating.

[larrylackey]

Fair enough. We didn’t stop there before and shouldn’t this time

On Sep 10, 2019, at 11:08 PM, Adam Crain notifications@github.com wrote:

To be clear, this is just a prototype. Before we can generate anything or leverage templating, we need to know what it looks like for single control profile.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.