[time-nuts] DHS Resilient PNT Conformance Framework

Tue Dec 22 01:57:56 UTC 2020

Hi Bob,

Sure, but I think some of these requirements will be met for fairly
cheap devices soon enough. Another aspect we also discussed is that
while a module on its own may not do all the things needed to meet a
level, if it has sufficient of capabilities to support additional checks
and then those is performed outside, the system they form may achieve
the higher level requiring the function. So, with sufficiently open
interface to key state to monitor things, as we know several receiver
has, then they can achieve that. Now, nothing have been detailed as to
what to monitor and when to judge go/no-go, for any system, the
framework is there to say that such mechanisms should be described,
eventually. That may end up being a fun discussion.

In the end, if this takes off, what it does is that it creates a market
for devices to meet these requirements. In doing so, the intention is to
make sure that there is a high level of commonality between the
requirements for the different sectors of the same level. So, not that
everyone invent their wheel, but rather they indicate their subset
needing extra attention and jot down critical performance numbers for it
to fit their environment.

Having common threats/scenarios to test for among sectors have been
discussed. Having common model for state-analysis of receivers have also
been mentioned. Nothing decided. All there is, is to convey the general
concepts and see if there is any takers to follow up. I think most
importantly that a lot is achieved by trying to build a common ground
like this. The framework as it stands is still vague, as little
specifics is there. I expect more to come in the future.

Cheers,
Magnus

On 2020-12-22 02:29, Bob kb8tq wrote:
> 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.
>
> _______________________________________________
> 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.