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