OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ocpp message

[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 Anders, (Folks),

My thinking would be that in regard to charge point time synchronization in the general case, there are a number of layers of decision and that these operate as a hierarchy at three different levels.

1. What external time source should be used for time synchronization of the charge point:
	a) NTP
	b) Heartbeat (possibly renamed/re-purposed)
	c) Heartbeat, falling back to (likely local, possibly not continuously upstream connected) NTP
	d) NTP, falling back to Heartbeat

2. Where does the charge point get its NTP server network address(es)
	a) DHCP
	b) Explicitly specified
	c) Explicitly specified, falling back to DHCP
	d) DHCP, falling back to specified

3. What is the DHCP server network address (if explicitly specified)

All three data items are plausibly subject to further extension:

	1: Additional time sources
		Mobile data network time 
		GPS time sources

	2: Additional NTP source selection mechanisms
		NTP "Pool" (pool.ntp.org)
		NTP country pools (<cc-tld>.pool.ntp.org)
	3. Specified (local/external) NTP network address(es) in priority order (or round-robin?)

Consequently, I think that  there should be three distinct variables to cover all plausible cases

Given the above, it would be unwise and impractical to try to create an exhaustive set of combined enumerations that cover all the prioritization possibilities (e.g. NTP, falling back to GPS, falling back to Heartbeat, ... (at least 23 other combinations)). 
Instead the  desired value(s), in clear priority order, can be set on each of three configuration Variables of the "Clock" Component, using the Variable instance keying mechanism, and the canonical representation rules for integer numeric keyed instance representation: 



	Clock.NTPAddresses[1]= NTP1.local
	Clock.NTPAddresses[2]= NTP2.local

Best Regards, 

Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie 

-----Original Message-----
From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] On Behalf Of Anders Darander
Sent: 14 November 2016 08:12
To: ocpp@lists.oasis-open.org
Subject: Re: [ocpp] NTP Time service configuration - standard configuration variables

Hi Brendan,

* Brendan McMahon <Brendan.McMahon@esb.ie> [161112 15:50]:

> 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.

Should we have a three-state variable: heartbeat sync, hardcoded NTP, or NTP from DHCP? All of these states makes sense.

That's most likely the most expressive solution, and thus I'm in favour of that one.


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:

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.

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.

* ** *** ** * ** *** ** * ** *** ** *

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]