Re: [ocpp] NTP Time service configuration - standard configuration variables

[Anders Darander <anders@chargestorm.se>]

Hi Brendan,

* Brendan McMahon <Brendan.McMahon@esb.ie> [161114 15:53]:

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

Oh, that's getting complex... But, you're right, quite likely, you'd
like to be able to define fall-back mechanisms; so it's not only a
3-state decision.

> 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?)
>		NTP1.local
>		NTP2.local

In the case of multiple fixed addresses, they could just as well be used
all (likely as you say in a round robin fashion).

The alternative would be to say that the first one should always be
used, with the later ones as fallbacks, but that feels more unnuatural
to me. This is basically the standard ntp configuration with one primary
server. Problems with this server can't be detected....

The usual recommendations is to use either one or four NTP-servers.

> 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.TimeSources[1]=NTP
>	Clock.TimeSources[2]=GPS
>	Clock.TimeSources[3]=MobileData
>	Clock.TimeSources[4]=Heartbeat

This one sounds good.

>	Clock.NTPSources[1]=DHCP
>	Clock.NTPSources[2]=pool.ntp.org
>	Clock.NTPSources[3]=StaticList

These, two, seems slightly more redundant. I think we could use a single
variable, either holding a NTP server address (DNS-name or IP), or a few
keys, like DHPC... Unless, we wan't the StaticList to mean that we
should simultaneously use all of the listed servers?

>	Clock.NTPAddresses[1]= NTP1.local

This one should maybe be Clock.NTPStaticAddress?
And reserve Clock.NTPAddress to be a read-only parameter, reflecting the
currenly used NTP server?

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