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
Rui.Pereira (talk | contribs) 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}} | ||
}} | }} | ||
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 == | == 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) | |||
# Liability Critical applications (LCA) | |||
# 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.<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. | |||
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<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>. | |||
====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 == | == 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]]''' | |||
'''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''' | '''[[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 | :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 | :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 | :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 | == 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- | '''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. | ||
== | == Other Differencing Characteristics between SCA and LCA == | ||
From a high-level structural and | 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 | 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
Applications | |
---|---|
Title | Criticality of GNSS Applications |
Edited by | GMV |
Level | Intermediate |
Year of Publication | 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.
Categorization of the Criticality of GNSS Applications
In terms of criticality the GNSS Applications can be classified in three different groups:
- Safety Critical applications (SCA)
- Liability Critical applications (LCA)
- 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.
- 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.
- 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.
- 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.
- 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
References
- ^ NASA Software Safety Standard NASA-STD-8719.13B w/Change 1, July 8, 2004
- ^ Interoperability for Liability Critical Applications, M. Azaola (GMV), International GNSS Committee, Working Group B, Special Meeting on GNSS User Positioning Integrity, Munich, 2010
- ^ 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)
- ^ 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.