OASIS OCPP TC CR Time Title: CR Time Version: v0.1 Date: 2016-11-15 Initiator: Robert de Leeuw (IHomer) Supporters: n/a Goal: Improve the use of times, timestamps and timezones in OCPP. In OCPP 1.x this was not defined precise enough. Implementation Impact: Actor Impact Charge Point Low Central System Low Security Impact: n/a Compliance Impact: n/a (charge points should be more accurate regarding times..) Summary: All communication between Central System and Charge Point SHALL be in UTC. To display/print local times, time zone/time offset can be configured. For "daylight savings time" configuration, Device Model Component/Variables have been defined. For more advanced Charge Point that want to use more accurate or alternative time sources, a lot of Device Model Component/Variables are defined. All text bellow can be seen as a new or improved functional block for the OCPP specification. If this is an improvement, copy the old functional block here and update it. Mark all the changes made. 1. Generic _(Add to following as a paragraph to the Generic part of the spec) 1 1.1. Time Zones This section is normative. To improve interoperability between Central Systems and Charge Points all time values SHALL be exchanged as UTC, with the time zone designator ‘Z’, as specified by ISO 8601 [ISO8601]. For the purpose of displaying local time on for example: a Charge Point’s display, the device model’s Clock component supports specifying a time offset between Central System time (UTC or otherwise) and local time at the Charge Point. 1.1.1. Daylight Saving Time To support punctual automated bi-annual changeover between “standard time” and “daylight saving time” periods, the device model supports configuration values of the Clock component that allow transitions between “standard” and “daylight saving” time periods to be automated by specifying a “next” transition date-time and a corresponding “next” time offset. For details of time zones and DST transitions, please see the standardized Clock component (TODO make this a link in the spec) 2. Scope n/a 2.1. Conventions n/a 2.2. References [ISO8601] "Date and time format" http://www.iso.org/iso/home/standards/iso8601.htm 3. Use Cases n/a (No Use Cases for this, only generic description on how to handle times, timestamps and timezones) 4. Messages n/a 5. DataType n/a 2 6. Device Model Component/Variables New component/variables 6.1. Component: Clock Variables VariableNam Req Key Description e OptionsSet Y TimeSource Possible Values: HeartBeat, NTP, GPS, RealTimeClock, MobileNetwork OptionsSet N NTPSource Possible Values: DHCP, pool.ntp.org, manual OptionsSet N NTPConfigura Possible Values: DHCP, manual tion NetworkAddr N NTPAddress1 Address of the NTP server, either retrieved via DHCP or ess manually configured. NetworkAddr N NTPAddress2 Address of the first backup NTP server. ess NetworkAddr N NTPAddress3 Address of the second backup NTP server. ess NetworkAddr N NTPAddress4 Address of the third backup NTP server. ess Interval N HeartBeat Required for SOAP. Interval of inactivity (no OCPP exchanges) with central system after which the Charge Point should send a Heartbeat.req PDU Replace OCPP 1.x Configuration Key: HeartbeatInterval Active N RTC Real time clock active. Time Y Now Current Date Time (UTC) Time N DstStart Start of daylight savings time Time N DstEnd End of daylight savings time TimeOffset N Now Configured current local time zone offset TimeOffset N DST local time zone offset during daylight savings time (including the timezone offset) (Req = Required) TODO: Do we need possibilities for Charge Point that have tzData in the firmware and only need to know the correct time zone to calculate: Timezone offset and daylight saving time? 3 7. Test Cases n/a 8. WSDL Schema n/a 9. JSON Schema n/a Appendix 1. Sequence Diagram Source n/a OASIS OCPP TC CR Template: v1.0 4.