[time-nuts] DHS Resilient PNT Conformance Framework

[Bob kb8tq]

Hi

Well, we’re not talking about $9 parts here. Typical prices in the $500 to $2,000 in 
quantity would be a better description. That said, the OEM’s normally saw the field
upgrade process as a bigger risk than not getting involved in it …..

Bob

> On Dec 21, 2020, at 7:51 PM, Magnus Danielson <magnus at rubidium.se> wrote:
> 
> 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.
> 
> _______________________________________________
> 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.