If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor

Criticality of GNSS Applications: Difference between revisions

From Navipedia
Jump to navigation Jump to search
No edit summary
m (Included editor logo.)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Article Infobox2
{{Article Infobox2
|Category=Applications
|Category=Applications
|Editors=GMV
|Level=Intermediate
|YearOfPublication=2011
|Logo=GMV
|Title={{PAGENAME}}
|Title={{PAGENAME}}
|Authors=GMV
|Level=Medium
|YearOfPublication=2011
}}
}}
 
GNSS systems can serve to many different purposes or applications, with different tolerances to system failures or errors. Attending to the criticality that an unwarned error or failure of the GNSS system has for a particular application, these will be classified in different categories.
 
Positioning systems can serve to many different purposes or applications, with different tolerances to system failures or errors. Attending to the criticality that an unwarned error or failure of the positioning system has for a particular application, these will be classified in different categories.
 


== Categorization of the Criticality of GNSS Applications ==
== Categorization of the Criticality of GNSS Applications ==
In terms of criticality the GNSS Applications can be classified in three different groups:
In terms of criticality the GNSS Applications can be classified in three different groups:
*Safety Critical applications (SCA)
# Safety Critical applications (SCA)
*Liability Critical applications (LCA)
# Liability Critical applications (LCA)
*Non-Critical applications (NCA)
# Non-Critical applications (NCA)
 
 
'''Safety Critical applications'''
:Safety Critical applications are those where human lives are at risk. All applications considered as safety critical, or having any safety implication, although indirect, are considered under this group.
:Safety Critical applications are not only those closely linked to deaths and accidents (like ADAS), but also some other application that are prone to produce a reduction in the number or people injured or killed in the road (as it is the case of emergency services, traffic information in real time, and so on). Both types have been considered under Safety Critical application group.
 
:Examples of safety-critical applications include air and maritime navigation or advanced driving assistance systems (ADAS).
 
 
'''Liability Critical applications'''


:Liability Critical applications are those where the consequences on navigation of undetected GNSS mis-performances can generate significant legal or economic consequences.
===Safety Critical Applications===
Safety Critical Applications are those that possess the potential of directly or indirectly causing harm to humans, destruction of the system, damage to property external to the system, or damage to the environment.<ref> [http://www.system-safety.org/Documents/NASA-STD-8719.13B.pdf NASA Software Safety Standard NASA-STD-8719.13B w/Change 1], July 8, 2004</ref>. All applications considered as safety critical, or having any safety implication, although indirect, are considered under this group.


:Examples of liability-critical applications are road tolling or traffic law enforcement.
Safety Critical Applications are not only those that a misbehavior can cause deaths and accidents, but also some other application that are prone to produce a reduction in the number or people injured or killed (as it is the case of emergency services, traffic information in real time, and so on). Both types have been considered under Safety Critical Application group.


====Examples====
Examples of Safety Critical Applications include:
* air and maritime navigation or
* advanced driving assistance systems (ADAS).


'''Non-Critical applications'''
===Liability Critical Applications===
Liability Critical Applications are those where the consequences on navigation of undetected GNSS miss-performances can generate significant legal or economic consequences<ref>[http://www.oosa.unvienna.org/pdf/icg/2010/workgroupb1/03.pdf Interoperability for Liability Critical Applications], M. Azaola (GMV), International GNSS Committee, Working Group B, Special Meeting on GNSS User Positioning Integrity,  Munich, 2010</ref><ref>Integrity in urban and road environments and its use in liability critical applications, J Cosmen-Schortmann, M A Martinez-Olagüe, M Azaola-Saenz, M Toledo-Lopez, Position Location and Navigation Symposium 2008 IEEEION (2008) </ref>.


:Non-Critical applications are all applications not presenting any commercial, legal or safety implications. Due to these reasons, the technological requirements are, in general, more relaxed than the ones needed in previous application groups.
====Examples====
Examples of Liability Critical Applications are  
* road tolling,  
* traffic law enforcement,  
* Pay-As-You-Drive (PAYD) insurance,  
* On-street parking pricing,  
* Surveillance of Parolees and
* Fleet management (special vehicle classes).


:Most common uses of GNSS navigation devices, such as searching for nearby facilities (gas stations, restaurants, etc.) do not involve legal, economic or health risks, and hence are non-critical applications.
===Non-Critical Applications===
Non-Critical Applications are all applications not presenting any commercial, legal or safety implications. Due to these reasons, the technological requirements are, in general, more relaxed than the ones needed in previous application groups.


Most common uses of GNSS navigation devices, such as searching for nearby facilities (gas stations, restaurants, etc.) do not involve legal, economic or health risks, and hence are Non-Critical Applications.


== Main Features of LCA and Comparison with SCA ==
== Main Features of LCA and Comparison with SCA ==
Going through a bottom-up revision of LCA and their common points and differences with SCA, the four main performance parameters are going to be analyzed in terms of their impact in LCA and SCA.




Going through a bottom-up revision of LCA and their common points and differences with SCA, let us start with the low level aspects.
'''[[Accuracy]]'''
 
 
'''Accuracy'''


:Civil aviation performance specifications for GNSS navigation systems impose restrictions to the shape of the distribution of errors (in addition to those imposed by integrity requirements) by setting limits to some of its percentiles. According to the GNSS Evolutionary Architecture Study.<ref name="GEAS"> [http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/navservices/gnss/library/documents/media/GEAS_PhaseI_report_FINAL_15Feb08.pdf GNSS Evolutionary Architecture Study. Phase I - Panel Report], February 2008.</ref>, accuracy performance in LPV-200 (a particular aircraft approach category that is still in process of definition) is specified by means of a standard 95% error percentile (with no associated detection requirement) and also by a so-called Effective Monitor Threshold (EMT), which defines a limit for the 99.999% error percentile, and errors beyond which must be detected with a probability of at least 50%. This implies that still one time out of 200,000 an error larger than the EMT could pass undetected without violating the requirements. From the point of view of civil aviation safety, one out of 200,000 would be simply unacceptable, hence it is the opinion of the authors that these requirements have very little to do with safety, but rather with a global system performance characterisation (disregarding possible fat tails of the error distribution). Therefore, although accuracy can play a key role in some safety-critical applications, that role is not as directly linked to safety as that of integrity. In a similar way, accuracy is not directly linked with liability aspects of liability-critical applications; unlike integrity, it does not help solving user liability aspects.  
:SCA and LCA have accuracy requirements ensuring that the performance is adequate for the application. But from the point of view of most SCAs (such as civil aviation) it is not only required that accuracy is below a certain level, but also to be aware whenever the error falls outside the requirements. From the point of view of civil aviation safety, to have undetected errors outside the requirements with probabilities such as 1 in 200,000 would be unacceptable, hence accuracy by itself has very little to do with safety. Therefore, although accuracy can play a key role in some safety-critical applications, that role is not as directly linked to safety as that of integrity. In a similar way, accuracy is not directly linked with liability aspects of liability-critical applications; unlike integrity, it does not help solving user liability aspects.  




'''Integrity'''
'''[[Integrity]]'''


:This is the key enabler for LCA and SCA. However, integrity requirements for LCA will tend, in principle, to be less stringent than for SCA, as the consequences of an integrity failure are much less dramatic. This is so when integrity requirements are established based on individual user’s point of view. From stakeholders’ perspective, integrity requirements might have to be established taking into account other elements necessary to make the business feasible and profitable. For instance, when a LCA involves a large number of users, integrity requirements might also aim to minimise the rate of user claims, in order for the application to be worthy. Also in SCA like civil aviation, this type of considerations (ultimately economic) have been made, e.g. deriving integrity requirements that account for an expected increase of air traffic operations and aim to keep the accident rate constant, thus preserving people’s perception of safety, but even such considerations have pushed in the direction of increasing (rather than relaxing) user safety.
:This is the key enabler for LCA and SCA. However, integrity requirements for LCA will tend, in principle, to be less stringent than for SCA, as the consequences of an integrity failure are much less dramatic. This is so when integrity requirements are established based on individual user’s point of view. From stakeholders’ perspective, integrity requirements might have to be established taking into account other elements necessary to make the business feasible and profitable. For instance, when a LCA involves a large number of users, integrity requirements might also aim to minimize the rate of user claims, in order for the application to be worthy. Also in SCA like civil aviation, this type of considerations (ultimately economic) have been made, e.g. deriving integrity requirements that account for an expected increase of air traffic operations and aim to keep the accident rate constant, thus preserving people’s perception of safety, but even such considerations have pushed in the direction of increasing (rather than relaxing) user safety.




'''Continuity'''
'''[[Continuity]]'''


:Can be essential in SCA (e.g. air navigation). A failure to provide the required continuity in aviation can have a negative impact on safety. However, in most LCAs, continuity is not even a requirement, For instance, a road tolling system would require a sufficiently small protection level to be computed once in a while (depending on the topology of the road infrastructure and on the charging scheme) for road usage identification purposes. However, an aircraft needs valid positions and sufficiently small protection levels to be computed continuously for a period of time long enough to cover an entire approach and landing operation. In general we can say that in LCA the concept of continuity as different to availability makes no specific sense.
:Can be essential in SCA (e.g. air navigation). A failure to provide the required continuity in aviation can have a negative impact on safety. However, in most LCA, continuity is not even a requirement, for instance, a road tolling system would require a sufficiently small protection level to be computed once in a while (depending on the topology of the road infrastructure and on the charging scheme) for road usage identification purposes. However, an aircraft needs valid positions and sufficiently small protection levels to be computed continuously for a period of time long enough to cover an entire approach and landing operation. In general we can say that the concept of continuity as different to availability usually is not a requirement for LCA although depending on the mission and on the operational concept of the application itself this could be different.




'''Availability'''
'''[[Availability]]'''


:Has no safety implications in SCA and no liability implications in LCA. However, both for SCA and LCA, a poor availability performance would have a deep impact on system credibility and worthiness. For instance, in the cases of road user charging or pay-as-you-drive insurance, low availability implies that users cannot be charged (or are being undercharged) for a service that would otherwise be chargeable, and hence the ultimate recipients of the chargeable fees (governments, service providers, road infrastructure operators, insurance companies, etc.) would not get the economic profit necessary to make the system sustainable. Something similar happens for SCA; if GNSS systems do not provide enough availability for air navigation, alternative systems will have to be used, but safety is not affected. This is the only impact on SCA as long as there exists a backup navigation means, as it is the case in GNSS air navigation; there is no GNSS system certified as sole means for air navigation, whatever the navigation mode or phase of flight. Beware, however, that this could be different with other (future) safety-critical applications, provided that an adequate standardisation and certification entity does not exist yet, which would establish the necessary requirements at this respect to force the existence of backup systems. This could be the case of a GNSS-based autopilot system (a currently evolving idea of ADAS systems designers).
:Has no safety implications in SCA and no liability implications in LCA. However, both for SCA and LCA, a poor availability performance would have a deep impact on system credibility and worthiness. For instance, in the cases of road user charging or pay-as-you-drive insurance, low availability implies that users cannot be charged (or are being undercharged) for a service that would otherwise be chargeable, and hence the ultimate recipients of the chargeable fees (governments, service providers, road infrastructure operators, insurance companies, etc.) would not get the economic profit necessary to make the system sustainable. Something similar happens for SCA; if GNSS systems do not provide enough availability for air navigation, alternative systems will have to be used, but safety is not affected. This is the only impact on SCA as long as there exists a backup navigation means, as it is the case in GNSS air navigation; there is no GNSS system certified as sole means for air navigation, whatever the navigation mode or phase of flight. Beware, however, that this could be different with other (future) safety-critical applications, provided that an adequate standardization and certification entity does not exist yet, which would establish the necessary requirements at this respect to force the existence of backup systems. This could be the case of a GNSS-based autopilot system (a currently evolving idea of ADAS systems designers).


So, if integrity, continuity, availability and accuracy are the critical aspects of a SCA, only integrity and availability are the critical aspects of a LCA.
So, if integrity, continuity, availability and accuracy are the critical aspects of a SCA, only integrity and availability are generally the critical aspects of a LCA.




== Role of Integrity for CSA and LCA ==
== Role of Integrity for SCA and LCA ==


Therefore one of the key concepts involved in the preceding classification is integrity, as it refers precisely to the ability of the system to provide a measure of the trust that can be placed on the positioning information it provides, and to provide timely warnings when the desired level of trust is not achieved.


In what concerns integrity, there are two main aspects to consider:
In what concerns integrity, there are two main aspects to consider:
Line 81: Line 80:




'''Time-to-alert'''
'''Time-To-Alert (TTA)'''


:This is definitely a differentiator between SCA and LCA. For SCA, time-to-alert requirements are as stringent as a few seconds {{#tag:ref| According to the Annex 10 of the Convention On International Civil Aviation<ref name="ICAO AN10-1"> Annex 10 (Aeronautical Telecommunications) To The Convention On International Civil Aviation, Volume I – Radio Navigation Aids, International Standards And Recommended Practices (SARPs), ICAO Doc. AN10-1, 6th Edition, July 2006.</ref>, “the time-to-alert shall be 5.2 seconds for an SBAS that supports precision approach or APV-II operations, and 8 seconds for an SBAS that supports APV-I operations”|group="nb"}}, but for a LCA, the TTA can be in the order of minutes to days. Consider, for instance, the case of road user charging or that of on-street parking pricing; any reasonable implementation of such systems would issue a daily, weekly or even monthly invoice for the chargeable fees, so there would be no need for an alarm being raised within a few seconds after the events as the undue charges could be subtracted later on, as long as they are subtracted before the invoice is issued. Probably, one of the most demanding LCAs in matters of TTA is surveillance of parolees, but even that would require a TTA in the order of minutes (note that this application is not regarded here as a means for rapid intervention before a crime is committed -in that case it would be better classified as a SCA- but rather as a way to check that parolees are not violating the movement restrictions imposed on them). Despite all of the above, the TTA in a LCA can become quite restrictive depending on system architecture: a relaxed TTA would generally require to be able to store and recover old-aged data, and this implies large amounts of data to be either stored at the on-board equipment or sent to the ground control centre. If none of these two can be achieved, TTA requirements could become far more demanding.
:This is definitely a differentiator between SCA and LCA. For SCA, time-to-alert requirements are as stringent as a few seconds {{#tag:ref| According to the Annex 10 of the Convention On International Civil Aviation<ref name="ICAO AN10-1"> Annex 10 (Aeronautical Telecommunications) To The Convention On International Civil Aviation, Volume I – Radio Navigation Aids, International Standards And Recommended Practices (SARPs), ICAO Doc. AN10-1, 6th Edition, July 2006.</ref>, “the time-to-alert shall be 5.2 seconds for an SBAS that supports precision approach or APV-II operations, and 8 seconds for an SBAS that supports APV-I operations”|group="nb"}}, but for a LCA, the TTA can be in the order of minutes to days. Consider, for instance, the case of road user charging or that of on-street parking pricing; any reasonable implementation of such systems would issue a daily, weekly or even monthly invoice for the chargeable fees, so there would be no need for an alarm being raised within a few seconds after the events as the undue charges could be subtracted later on, as long as they are subtracted before the invoice is issued. Probably, one of the most demanding LCAs in matters of TTA is surveillance of parolees, but even that would require a TTA in the order of minutes (note that this application is not regarded here as a means for rapid intervention before a crime is committed -in that case it would be better classified as a SCA- but rather as a way to check that parolees are not violating the movement restrictions imposed on them). Despite all of the above, the TTA in a LCA can become quite restrictive depending on system architecture: a relaxed TTA would generally require to be able to store and recover old-aged data, and this implies large amounts of data to be either stored at the on-board equipment or sent to the ground control centre. If none of these two can be achieved, TTA requirements could become far more demanding.




== Application Level Differences ==
== Other Differencing Characteristics between SCA and LCA ==




From a high-level structural and organisational perspective, there are other aspects that make a difference between these two worlds (SCA and LCA):
From a high-level structural and organizational perspective, there are other aspects that make a difference between these two worlds (SCA and LCA):


:'''Safety-critical applications''' tend to ignore commercial or economic aspects when establishing their standards, procedures or requirements, in order to avoid any interference of economic or commercial interests that could, otherwise, have a negative impact on safety.
:'''Safety-critical applications''' tend to ignore commercial or economic aspects when establishing their standards, procedures or requirements, in order to avoid any interference of economic or commercial interests that could, otherwise, have a negative impact on safety.
Line 95: Line 94:
:'''Liability-critical applications''', along with the legal aspects, are more directly affected than safety-critical ones by commercial aspects, being even possible to establish an almost perfect mapping that links, on one hand, integrity requirements to the legal aspects (user liability) of the application and, on the other hand, availability requirements to the commercial aspects of the application (in the sense that less availability implies smaller income, as user liabilities cannot be applied when positioning/integrity service is unavailable).
:'''Liability-critical applications''', along with the legal aspects, are more directly affected than safety-critical ones by commercial aspects, being even possible to establish an almost perfect mapping that links, on one hand, integrity requirements to the legal aspects (user liability) of the application and, on the other hand, availability requirements to the commercial aspects of the application (in the sense that less availability implies smaller income, as user liabilities cannot be applied when positioning/integrity service is unavailable).


Another important structural feature of liability-critical applications not necessarily present in safety-critical ones is the need for an after-user data collection and processing centre, responsible for collecting and processing all relevant data from users in order to establish any possible charges, fees, taxes, fines or whatever user liabilities for the particular application. This imposes the need for a communication link between on-board equipment and data processing facilities with implications in service availability that need further analysis.
Another important structural feature of Liability Critical Applications not necessarily presented in safety-critical ones is the need for an after-user data collection and processing centre, responsible for collecting and processing all relevant data from users in order to establish any possible charges, fees, taxes, fines or whatever user liabilities for the particular application. This imposes the need for a communication link between on-board equipment and data processing facilities with implications in service availability that need further analysis.
 


== Notes ==
== Notes ==
<references group="nb" />
<references group="nb" />


==References==
==References==

Latest revision as of 15:17, 18 September 2014


ApplicationsApplications
Title Criticality of GNSS Applications
Edited by GMV
Level Intermediate
Year of Publication 2011
Logo GMV.png

GNSS systems can serve to many different purposes or applications, with different tolerances to system failures or errors. Attending to the criticality that an unwarned error or failure of the GNSS system has for a particular application, these will be classified in different categories.

Categorization of the Criticality of GNSS Applications

In terms of criticality the GNSS Applications can be classified in three different groups:

  1. Safety Critical applications (SCA)
  2. Liability Critical applications (LCA)
  3. Non-Critical applications (NCA)

Safety Critical Applications

Safety Critical Applications are those that possess the potential of directly or indirectly causing harm to humans, destruction of the system, damage to property external to the system, or damage to the environment.[1]. All applications considered as safety critical, or having any safety implication, although indirect, are considered under this group.

Safety Critical Applications are not only those that a misbehavior can cause deaths and accidents, but also some other application that are prone to produce a reduction in the number or people injured or killed (as it is the case of emergency services, traffic information in real time, and so on). Both types have been considered under Safety Critical Application group.

Examples

Examples of Safety Critical Applications include:

  • air and maritime navigation or
  • advanced driving assistance systems (ADAS).

Liability Critical Applications

Liability Critical Applications are those where the consequences on navigation of undetected GNSS miss-performances can generate significant legal or economic consequences[2][3].

Examples

Examples of Liability Critical Applications are

  • road tolling,
  • traffic law enforcement,
  • Pay-As-You-Drive (PAYD) insurance,
  • On-street parking pricing,
  • Surveillance of Parolees and
  • Fleet management (special vehicle classes).

Non-Critical Applications

Non-Critical Applications are all applications not presenting any commercial, legal or safety implications. Due to these reasons, the technological requirements are, in general, more relaxed than the ones needed in previous application groups.

Most common uses of GNSS navigation devices, such as searching for nearby facilities (gas stations, restaurants, etc.) do not involve legal, economic or health risks, and hence are Non-Critical Applications.

Main Features of LCA and Comparison with SCA

Going through a bottom-up revision of LCA and their common points and differences with SCA, the four main performance parameters are going to be analyzed in terms of their impact in LCA and SCA.


Accuracy

SCA and LCA have accuracy requirements ensuring that the performance is adequate for the application. But from the point of view of most SCAs (such as civil aviation) it is not only required that accuracy is below a certain level, but also to be aware whenever the error falls outside the requirements. From the point of view of civil aviation safety, to have undetected errors outside the requirements with probabilities such as 1 in 200,000 would be unacceptable, hence accuracy by itself has very little to do with safety. Therefore, although accuracy can play a key role in some safety-critical applications, that role is not as directly linked to safety as that of integrity. In a similar way, accuracy is not directly linked with liability aspects of liability-critical applications; unlike integrity, it does not help solving user liability aspects.


Integrity

This is the key enabler for LCA and SCA. However, integrity requirements for LCA will tend, in principle, to be less stringent than for SCA, as the consequences of an integrity failure are much less dramatic. This is so when integrity requirements are established based on individual user’s point of view. From stakeholders’ perspective, integrity requirements might have to be established taking into account other elements necessary to make the business feasible and profitable. For instance, when a LCA involves a large number of users, integrity requirements might also aim to minimize the rate of user claims, in order for the application to be worthy. Also in SCA like civil aviation, this type of considerations (ultimately economic) have been made, e.g. deriving integrity requirements that account for an expected increase of air traffic operations and aim to keep the accident rate constant, thus preserving people’s perception of safety, but even such considerations have pushed in the direction of increasing (rather than relaxing) user safety.


Continuity

Can be essential in SCA (e.g. air navigation). A failure to provide the required continuity in aviation can have a negative impact on safety. However, in most LCA, continuity is not even a requirement, for instance, a road tolling system would require a sufficiently small protection level to be computed once in a while (depending on the topology of the road infrastructure and on the charging scheme) for road usage identification purposes. However, an aircraft needs valid positions and sufficiently small protection levels to be computed continuously for a period of time long enough to cover an entire approach and landing operation. In general we can say that the concept of continuity as different to availability usually is not a requirement for LCA although depending on the mission and on the operational concept of the application itself this could be different.


Availability

Has no safety implications in SCA and no liability implications in LCA. However, both for SCA and LCA, a poor availability performance would have a deep impact on system credibility and worthiness. For instance, in the cases of road user charging or pay-as-you-drive insurance, low availability implies that users cannot be charged (or are being undercharged) for a service that would otherwise be chargeable, and hence the ultimate recipients of the chargeable fees (governments, service providers, road infrastructure operators, insurance companies, etc.) would not get the economic profit necessary to make the system sustainable. Something similar happens for SCA; if GNSS systems do not provide enough availability for air navigation, alternative systems will have to be used, but safety is not affected. This is the only impact on SCA as long as there exists a backup navigation means, as it is the case in GNSS air navigation; there is no GNSS system certified as sole means for air navigation, whatever the navigation mode or phase of flight. Beware, however, that this could be different with other (future) safety-critical applications, provided that an adequate standardization and certification entity does not exist yet, which would establish the necessary requirements at this respect to force the existence of backup systems. This could be the case of a GNSS-based autopilot system (a currently evolving idea of ADAS systems designers).

So, if integrity, continuity, availability and accuracy are the critical aspects of a SCA, only integrity and availability are generally the critical aspects of a LCA.


Role of Integrity for SCA and LCA

Therefore one of the key concepts involved in the preceding classification is integrity, as it refers precisely to the ability of the system to provide a measure of the trust that can be placed on the positioning information it provides, and to provide timely warnings when the desired level of trust is not achieved.

In what concerns integrity, there are two main aspects to consider:


Target integrity risk

For a LCA, the target integrity risk would in principle be more relaxed than for a SCA as there are no human lives at risk. However, as mentioned above, depending on the service volume and on the maximum allowable frequency of claims that the system can afford while being commercially worthy, the target integrity risk could have to be extremely low, reaching the levels of civil aviation requirements or even beyond.


Time-To-Alert (TTA)

This is definitely a differentiator between SCA and LCA. For SCA, time-to-alert requirements are as stringent as a few seconds [nb 1], but for a LCA, the TTA can be in the order of minutes to days. Consider, for instance, the case of road user charging or that of on-street parking pricing; any reasonable implementation of such systems would issue a daily, weekly or even monthly invoice for the chargeable fees, so there would be no need for an alarm being raised within a few seconds after the events as the undue charges could be subtracted later on, as long as they are subtracted before the invoice is issued. Probably, one of the most demanding LCAs in matters of TTA is surveillance of parolees, but even that would require a TTA in the order of minutes (note that this application is not regarded here as a means for rapid intervention before a crime is committed -in that case it would be better classified as a SCA- but rather as a way to check that parolees are not violating the movement restrictions imposed on them). Despite all of the above, the TTA in a LCA can become quite restrictive depending on system architecture: a relaxed TTA would generally require to be able to store and recover old-aged data, and this implies large amounts of data to be either stored at the on-board equipment or sent to the ground control centre. If none of these two can be achieved, TTA requirements could become far more demanding.


Other Differencing Characteristics between SCA and LCA

From a high-level structural and organizational perspective, there are other aspects that make a difference between these two worlds (SCA and LCA):

Safety-critical applications tend to ignore commercial or economic aspects when establishing their standards, procedures or requirements, in order to avoid any interference of economic or commercial interests that could, otherwise, have a negative impact on safety.
Liability-critical applications, along with the legal aspects, are more directly affected than safety-critical ones by commercial aspects, being even possible to establish an almost perfect mapping that links, on one hand, integrity requirements to the legal aspects (user liability) of the application and, on the other hand, availability requirements to the commercial aspects of the application (in the sense that less availability implies smaller income, as user liabilities cannot be applied when positioning/integrity service is unavailable).

Another important structural feature of Liability Critical Applications not necessarily presented in safety-critical ones is the need for an after-user data collection and processing centre, responsible for collecting and processing all relevant data from users in order to establish any possible charges, fees, taxes, fines or whatever user liabilities for the particular application. This imposes the need for a communication link between on-board equipment and data processing facilities with implications in service availability that need further analysis.


Notes

  1. ^ According to the Annex 10 of the Convention On International Civil Aviation[4], “the time-to-alert shall be 5.2 seconds for an SBAS that supports precision approach or APV-II operations, and 8 seconds for an SBAS that supports APV-I operations”


References

  1. ^ NASA Software Safety Standard NASA-STD-8719.13B w/Change 1, July 8, 2004
  2. ^ Interoperability for Liability Critical Applications, M. Azaola (GMV), International GNSS Committee, Working Group B, Special Meeting on GNSS User Positioning Integrity, Munich, 2010
  3. ^ Integrity in urban and road environments and its use in liability critical applications, J Cosmen-Schortmann, M A Martinez-Olagüe, M Azaola-Saenz, M Toledo-Lopez, Position Location and Navigation Symposium 2008 IEEEION (2008)
  4. ^ Annex 10 (Aeronautical Telecommunications) To The Convention On International Civil Aviation, Volume I – Radio Navigation Aids, International Standards And Recommended Practices (SARPs), ICAO Doc. AN10-1, 6th Edition, July 2006.