Project

General

Profile

CIM Issues #6757

BasicIntervalSchedule and RegularIntervalSchedule

Added by Chavdar Ivanov 7 months ago. Updated 7 months ago.

Status:
New
Priority:
High
Solution Version:
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
WG13, WG14, WG16, WG21
Requestor:
Standard(s):
Version:
Clause:
Sub-Clause:
Paragraph:
Table:
Origination Date:
Origination ID:
Originally Assigned To:

Description

BasicIntervalSchedule.startTime has datatype DateTime and description: The time for the first time point. The value can be a time of day, not a specific date.

RegularIntervalSchedule.endTime has datatype DateTime and description: The time for the last time point. The value can be a time of day, not a specific date.

452 has section 4.9 Definition of schedules - text provided below

XML that includes this does not pass SHACL validation due to datatype issue

<cim:BasicIntervalSchedule.startTime>00:00:00</cim:BasicIntervalSchedule.startTime>
<cim:RegularIntervalSchedule.endTime>23:59:59</cim:RegularIntervalSchedule.endTime>

4.9 Definition of schedules
The use of the RegularIntervalSchedule and RegularTimePoint attributes will differ for the different types of schedules derived from RegularIntervalSchedule. To specify a relative time for a schedule, the date portion of the dateTime format can be eliminated, which leaves the ISO 8601 time of day format “hh:mm:ss”. In this format, hh is the number of complete hours that have passed since midnight, mm is the number of complete minutes since the start of the hour, and ss is the number of complete seconds since the start of the minute.
The earliest allowed time used in a schedule (BasicIntervalSchedule.startTime) is “00:00:00”. The latest allowed time used in a schedule (RegularIntervalSchedule.endTime) is “24:00:00”. The point in time specified by the endTime is not included in the period of the schedule.
A schedule defining a day shall be defined with multiple RegularTimePoints associated with the same RegularIntervalSchedule. It shall not be defined with multiple schedules.
For schedules that are associated with Season and DayType, the associations to Season and DayType are not required. If a schedule does not have an associated Season, the schedule will be considered valid for all Seasons. Similarly, if a schedule does not have an association to a DayType, the schedule will be considered to apply to all days of the week.
When SeasonDayTypeSchedules are defined for a given entity, such as ConformLoadSchedules for a given ConformLoadGroup, only one schedule can be defined for a given combination of Season and DayType.


Files


Related issues

Related to WG13 Issues - CIM Issues #6680: Support time series/schedule for SSHIn ProgressActions
#1

Updated by Todd Viegut 7 months ago

17-Apr-2024 Reviewed in our weekly call:

Review this with both UCA TF14 & TF16 to determine if they have need of the Date component. If/how are they using it? What profiles today use it, etc.

Svein's current work on the primitive types document is related to the issue. Where he lands should end up including a proposal to address what we see here. This then should be presented at next months UML modeling proposals joint meeting.

Action Item [Todd]: Will email Henry and Becky today to begin the process of a joint review of the issue to obtain the information described above.

#3

Updated by Todd Viegut 7 months ago

  • Proposed Solution updated (diff)

09-May-2024 Reviewed in our monthly Joint TF modeling proposal call. In the description of this issue we identified the following actions:

- Review this with both UCA TF14 & TF16 to determine if they have need of the Date component. If/how are they using it? What profiles today use it, etc.
- TF16 confirmed that startTime/endTime attributes are used and that date is included in the profiles.
- TF14 - No confirmation yet from today's discussion. TimeSchedule is used in Part9 profiles but that inherits from Document and does not overlap the classes discussed in today's call.
- TF16 - Jim H. stated that Part6 profiles do not utilize these classes.
- Part6 has worked on introducing the use of the iCal standard for representing pattern/repeating schedules. This may intersect the use cases and be useful for what we discussed today. Must be explored further.
- Svein's current work on the primitive types document is related to the issue.
- We reviewed Svein's primitive types draft in today's meeting.

Action Items:
- Need to confirm with a broader audience the usage of the classes.
- We discussed needing to reconfirm/formalize our "deprecation approach". In other words the "rules" for deprecation is that the alternative should be modelled at the time the "legacy" class is deprecated. Additionally, the class being deprecated should refer to what classes are intended to replace, etc.
- Action Item [Todd/Chavdar]: Becky confirmed that TF16 requires/uses both date and time for the startTime/endTime attributes. She pointed out that we therefore should not change the names of the attributes nor the currently defined types. Therefore the ACTION ITEM is to update the descriptions as below:

BasicIntervalSchedule.startTime has datatype DateTime and description changes to approximately: The time and date for the first time point.
RegularIntervalSchedule.endTime has datatype DateTime and description changes to approximately: The time and date for the last time point.
- Action Item [Todd/Chavdar]: Introduce a new attribute that has a type of Time. The reason for this is that our changes to the above descriptions will constrain the usage of the existing attributes to both date and time.
- Action Item [?]: RegulationSchedule to be deprecated and replaced with whatever our final proposal is (see above action item to update the notes for the RegulationSchedule class). This is also dependent on the below final action item for a new proposal to replace it.
- Action Item [?]: Create a new set of classes for a formal solution to address this moving forward.
#4

Updated by Todd Viegut 7 months ago

#5

Updated by Todd Viegut 7 months ago

  • Project changed from WG13 Issues to CIM Joint Issues
  • Author/Contact Info deleted (Chavdar Ivanov)
  • Base Release deleted (CIM18v10)
  • Proposed Solution updated (diff)
  • CIM Keywords deleted (61970-Core)
  • CIM Impacted Groups WG14, WG16, WG21 added

Also available in: Atom PDF