<<

OASIS OCPP TC CR : CR Time

Version: v0.1

Date: 2016-11-15

Initiator: Robert de Leeuw (IHomer)

Supporters: n/a

Goal: Improve the use of , 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 accurate regarding times..)

Summary: All communication between Central System and Charge Point SHALL be in UTC. To display/ local times, /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, 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 component supports specifying a time offset between Central (UTC or otherwise) and local time the Charge Point.

1.1.1.

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 -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 " 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 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 OCPP 1.x Configuration Key: HeartbeatInterval

Active N RTC Real time clock active.

Time Y Now Current Date Time (UTC)

Time N DstStart 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