[time-nuts] DHS Resilient PNT Conformance Framework

[Magnus Danielson]

Hi Bob,

Yes, there is even receivers with no know way of upgrade in the field.
But this framework was not meant to make all receivers meet the
requirements, rather the opposite, the unofficial class of level 0 is
most of those receivers. If level 1 or higher is needed for critical
infrastructure of any kind, vendors aiming to sell to that market needs
to adapt. Getting a 9 USD module from some obscure vendor just won't cut
it. Also, if there is a way to clear the NV memory on the module, the
way the module is wrapped into another device must maintain the ability
to clear the NV. So would be true for the ability to upgrade for those
needing to meet that requirement.

I take some pride in the upgrade requirement. It ripples over from the
NASPI TSTF report where I contributed such formulations. I also
advocated for it in this work. It comes from bitter experience. Very
bitter. Luckily for me, I did not have to do the major part of
suffering, but I was there to see the troubles on multiple times.

For the reset thing, that came from another source, where jamming caused
some mobile phones to loose capability, which was a kind of bitter
experience considering they where meant to illustrate the problem, not
to brick peoples devices. So that was also bitter experience. Especially
the air-safety folks was very keen to have a way to make devices go back
to well behaved maner after the event, and by manual methods in the
field. I think it is a wise way of reasoning.

Also, this is a framework, and these are the common minimum requirement.
This is not ruling out that for some application the requirements may be
more detailed and stricter in some sense. For instance, the actual
performance may differ, or the time to recovery from factory default
restart or time to fix in normal setting. While Time To Fix had lots of
focus initially, we concluded that it was actually not the parameter of
greatest importance here, as that has already improved a lot, but other
properties may dominate.

Cheers,
Magnus

On 2020-12-21 20:08, Bob kb8tq wrote:
> 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.
>
> _______________________________________________
> 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.