[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ocpp] NTP Time service configuration - standard configuration variables
Hi Robert, Anders, (all),
I would think that the type of scenario that Anders describes will become quite common in the future, and therefore appropriate configuration variables should be standardized as part of OCPP 2.0, along the lines of Anders suggestions.
When OCPP was first being designed, as a SOAP based protocol requiring bi-directional IP routability, it was the normal case for it to be carried over a private (mobile) network, so access to common (public) NTP services could not be presumed.
Now, with the capability of OCPP to operate (tunnelling bi-directionally) over a client (charge point) initiated WebSocket (and possibly other transports), it is much more likely that charge points will be connected to the public internet, and consequently have access to reliable, high quality NTP services.
For small/simple “low-end” charge point devices, the cost of implementing a full local real-time clock hardware is not insignificant, and it is likely in future that there will be charge point designs (for at least certain applications) that are effectively un-usable without a live internet connection (e.g. via local Wi-Fi).
In such cases, it make more sense for the device to treat date/time synchronization information from NTP as preferable to the “traditional” OCPP mechanism of time synchronization via Central System timestamps returned in “Heartbeat” messages.
In that case, the “currentTime” value in the Heartbeat.conf message should be made optional, so that if configured to get “correct” time from elsewhere, there is no possibility of the charge point being confused by receiving alternating conflicting “real” time updates.
On a separate but related point, it is arguable that Heartbeat messages themselves (which can often be a large percentage of total data traffic for occasionally used charge points) are potentially redundant when OCPP is “tunnelled” over an underlying transport mechanism that has its own keep-alive and connection loss detection mechanisms.
Best Regards,
Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie
From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.
org ] On Behalf Of Robert de Leeuw
Sent: 11 November 2016 13:55
To: ocpp@lists.oasis-open.org
Subject: Re: [ocpp] Groups - OCPP Device Management Profile proposal uploaded
Hi Andres,
You are free to define your own Variables. So if you want, you could create your own Variable: UseDhcpForNetworkAddress? or something like that? Of more people think this is a good idea we could even add this to OCPP as Default Variable in the appendix.
When this flag is set to true, I would make Clock.NetworkAddress read-only, and show to address provided by DHCP. Might be usefull for the Central System to be able to see which NTP server is being used.
Kind regards,
Robert de Leeuw
IHomerHoge Ham 85
5104 JC Dongen
John F. Kennedylaan 3
5555 XC Valkenswaard
T: +31 6 2857 2123
E: robert.de.leeuw@ihomer.nl
2016-11-11 12:22 GMT+01:00 Anders Darander <anders@chargestorm.se>:
Hi,
* Robert de Leeuw <robert.de.leeuw@ihomer.nl> [161111 11:13]:
> I have just uploaded a new revision of the Device Management Profile proposal.
> Most of it is done, some minor open items (marked TODO)
As we've been discussing time a little bit recently, I've one remark on
the DM profile.
Clock.NetworkAddress can list an NTP-server for time synchronization.
1) If no NTP-server exists Clock.NetworkAddress, how is that one
represented? NonExisting är some other values? (It might very well
happen that I need to go back and read the full OCPP spec for this).
2) There could be occasions when you want the CP to use NTP, but you
want a DHCP-server to supply the NTP-server address. We need a value to
indicate that situation, e.g. Clock.NetworkAddress=dhcp or auto?
Cheers,
Anders
--
Anders Darander Senior System Architect
ChargeStorm AB Tel: +46 702 44 84 36
Hospitalsgatan 3 E-mail: anders@chargestorm.se
602 27 Norrköping Web: www.chargestorm.se
------------------------------------------------------------ ---------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_ workgroups.php
An timpeallacht? - Smaoinigh air sula bpriontáileann tú an r-phost seo.
Please consider the Environment before printing this email.* ** *** ** * ** *** ** * ** *** ** *
Tá an t-eolas sa ríomhphost seo agus in aon chomhad a ghabhann leis rúnda agus ceaptha le haghaidh úsáide an té nó an aonáin ar seoladh chuige iad agus na húsáide sin amháin.
Is tuairimí nó dearcthaí an údair amháin aon tuairimí nó dearcthaí ann, agus ní gá gurb ionann iad agus tuairimí nó dearcthaí ESB.
Má bhfuair tú an ríomhphost seo trí earráid, ar mhiste leat é sin a chur in iúl don seoltóir.
Scanann ESB ríomhphoist agus ceangaltáin le haghaidh víreas, ach ní ráthaíonn sé go bhfuil ceachtar díobh saor ó víreas agus ní glacann dliteanas ar bith as aon damáiste de dhroim víreas.
https://www.esb.ie/contact
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
Any views or opinions presented are solely those of the author, and do not necessarily represent those of ESB.
If you have received this email in error please notify the sender.
Although ESB scans e-mail and attachments for viruses, it does not guarantee that either is virus-free and accepts no liability for any damage sustained as a result of viruses.
https://www.esb.ie/contact* ** *** ** * ** *** ** * ** *** ** *
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]