[time-nuts] DHS Resilient PNT Conformance Framework

[Bob kb8tq]

Hi

I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them had
*major* concerns about field upgrades. Their take was that supporting them had 
always turned into a disaster.  No matter how clear the instructions, a significant
number of systems went down / stayed down  while sub assemblies were being 
upgraded …..

Pretty much the universal approach: Return the device to the factory and do any
needed upgrades there. Test it / verify it works and send it back. Having sat through
several of those exercises, I do not remember a single device that “bricked” when
done that way. 

Bob

> On Dec 21, 2020, at 9:56 AM, Magnus Danielson <magnus at rubidium.se> wrote:
> 
> Hi,
> 
> On 2020-12-21 09:02, Poul-Henning Kamp wrote:
>> --------
>> Bob kb8tq writes:
>> 
>>> I have seen cases of “goes away until power cycled”. I have not seen any cases of 
>>> “goes away forever” other than the obvious  ( = feed it an insane almanac that prevents
>>> if from ever locking up ). Even with that said, I have not seen an example ot that sort of
>>> thing living through a hard reset … ( which isn’t quite the same thing as a power cycle ).
>> I have: An corrupt alamanac in NV storage contained something which
>> made a particular GPS receiver divide by zero, shit its pants and
>> wedge during startup.
>> 
>> The post mortem report said that the alamanac passed the "technical
>> consistency checks", by which I suppose they mean the Hamming code,
>> but it still caused a divide by zero.
>> 
>> This incident is the reasons why GPS receivers in some critical
>> applications are not allowed to have NV storage for "operational
>> purposes" and get the almanac downloaded from the attached systems
>> at startup.
>> 
> With this new language, they would be required to be Level 1 compliant,
> at which it would always be a way for the user to reset corrupt data in
> the field. We never even discussed the possibility of prohibiting the
> NV, rather we focused on the ability to recover in the field. NV has
> it's upsides to boot quickly etc. but as any cache, it needs to be
> clearable.
> 
> In a similar sense, we also had a good discussion about being able to
> upgrade the receiver. Several of us was driving hard to ensure that
> receivers can be upgradeable in the field, so that bugs can be removed
> continuously throughout the operational lifetime. In fact, I pointed out
> that the operational lifetime should be limited by how long you can
> maintain the receiver updated. The whole life cycle aspect is important
> in that as you loose support on receivers, they should go out of service
> for critical things. You should also make sure there is contracts on how
> long they will be maintained.
> 
> Cheers,
> Magnus
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.