Tolling - Revision history

Filipe.Pelica: Included editor logo.

2014-09-18T17:00:10Z

Included editor logo.

← Older revision		Revision as of 17:00, 18 September 2014
Line 4:		Line 4:
	\|Level=Basic		\|Level=Basic
	\|YearOfPublication=2011		\|YearOfPublication=2011
			\|Logo=GMV
	\|Title={{PAGENAME}}		\|Title={{PAGENAME}}
	}}		}}

Filipe.Pelica: removed broken link.

2014-09-09T10:59:10Z

removed broken link.

← Older revision		Revision as of 10:59, 9 September 2014
Line 6:		Line 6:
	\|Title={{PAGENAME}}		\|Title={{PAGENAME}}
	}}		}}
	It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.		It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>Simulation tools for the assessment of GNSS based Road Tolling Systems, J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.

	Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an integrity level and the acquisition/generation of evidences that can be used to prove that the charged amount is correct.		Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an integrity level and the acquisition/generation of evidences that can be used to prove that the charged amount is correct.

Filipe.Pelica: fixed broken link.

2014-09-09T10:58:22Z

fixed broken link.

← Older revision		Revision as of 10:58, 9 September 2014
Line 6:		Line 6:
	\|Title={{PAGENAME}}		\|Title={{PAGENAME}}
	}}		}}
	It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[~~http://www.gmv.com.pt/empresa_GMV/comunicacion/documentos_tecnicos/enc_gnss_2008-GNSS%20based%20road%20tolling%20systems.pdf~~ Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.		It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.

	Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an integrity level and the acquisition/generation of evidences that can be used to prove that the charged amount is correct.		Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an integrity level and the acquisition/generation of evidences that can be used to prove that the charged amount is correct.

Carlos.Lopez at 10:58, 23 February 2012

2012-02-23T10:58:00Z

← Older revision		Revision as of 10:58, 23 February 2012
Line 1:		Line 1:
	{{Article Infobox2		{{Article Infobox2
	\|Category=Applications		\|Category=Applications
	\|Authors=Rui Barradas Pereira.		\|Authors=Rui Barradas Pereira, GMV
	\|Level=Basic		\|Level=Basic
	\|YearOfPublication=2011		\|YearOfPublication=2011
	~~\|Logo=GMV~~
	\|Title={{PAGENAME}}		\|Title={{PAGENAME}}
	}}		}}

Rui.Pereira at 11:02, 8 November 2011

2011-11-08T11:02:21Z

← Older revision		Revision as of 11:02, 8 November 2011
Line 1:		Line 1:
	{{Article Infobox2		{{Article Infobox2
	\|Category=Applications		\|Category=Applications
	~~\|Title={{PAGENAME}}~~
	\|Authors=Rui Barradas Pereira.		\|Authors=Rui Barradas Pereira.
	\|Level=Basic		\|Level=Basic
	\|YearOfPublication=2011		\|YearOfPublication=2011
	\|Logo=GMV		\|Logo=GMV
			\|Title={{PAGENAME}}
	}}		}}
	It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[http://www.gmv.com.pt/empresa_GMV/comunicacion/documentos_tecnicos/enc_gnss_2008-GNSS%20based%20road%20tolling%20systems.pdf Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.		It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[http://www.gmv.com.pt/empresa_GMV/comunicacion/documentos_tecnicos/enc_gnss_2008-GNSS%20based%20road%20tolling%20systems.pdf Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.
Line 16:		Line 16:
	The data collected by the OBUs is usually sent to a central server that consolidates the payment information for the users of the system. These systems require a communication channel between the OBU and the central equipment. [[Wikipedia:Cellular network\|Cellular network]] is generally used but other means of communication can also be used such as [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]. [[Wikipedia:Cellular network\|Cellular network]] communication relies on existing public networks while the other communication methods might require specific road side infrastructures.		The data collected by the OBUs is usually sent to a central server that consolidates the payment information for the users of the system. These systems require a communication channel between the OBU and the central equipment. [[Wikipedia:Cellular network\|Cellular network]] is generally used but other means of communication can also be used such as [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]. [[Wikipedia:Cellular network\|Cellular network]] communication relies on existing public networks while the other communication methods might require specific road side infrastructures.

	These OBUs can rely on [[SBAS Fundamentals\|Satellite Based Augmentation Systems (SBAS)]] like [[EGNOS General Introduction\|EGNOS]] or [[WAAS]] to achieve better [[Accuracy\|accuracy]] and to make decisions based on the [[Integrity\|integrity]] and [[Availability\|availability]] provided by those systems. There are also devices equipped with built-in autonomous algorithms that handle and decrease the effects of local errors, such as non-line-of-sight multipath. These kinds of mechanisms may guarantee an acceptable protection level (PL) for a ETC system, dismissing the use of additional sensors that would add complexity and cost to the systems.		These OBUs can rely on [[SBAS Fundamentals\|Satellite Based Augmentation Systems (SBAS)]] like [[EGNOS General Introduction\|EGNOS]] or [[WAAS General Introduction\|WAAS]] to achieve better [[Accuracy\|accuracy]] and to make decisions based on the [[Integrity\|integrity]] and [[Availability\|availability]] provided by those systems. There are also devices equipped with built-in autonomous algorithms that handle and decrease the effects of local errors, such as non-line-of-sight multipath. These kinds of mechanisms may guarantee an acceptable protection level (PL) for a ETC system, dismissing the use of additional sensors that would add complexity and cost to the systems.

	In terms of hardware requirements the devices used for tolling are very similar to [[Vehicle Trackers\|vehicle trackers]]. To support tolling, a device should have GNSS support and have wireless communication abilities either through [[Wikipedia:Wide area network\|WANs]] (e.g. [[Wikipedia:Cellular network\|cellular network]]) or [[Wikipedia:Local area network\|LANs]] (e.g. [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]). Some systems can have user interface, although this is not mandatory for tolling applications. The only specific requirement - that might not be present in [[Vehicle Trackers\|vehicle trackers]] - is integrity support, since tolling is a liability critical application. Depending on the architecture and on the pricing complexity, the OBU might have different requirements in terms of processing and storage capabilities.		In terms of hardware requirements the devices used for tolling are very similar to [[Vehicle Trackers\|vehicle trackers]]. To support tolling, a device should have GNSS support and have wireless communication abilities either through [[Wikipedia:Wide area network\|WANs]] (e.g. [[Wikipedia:Cellular network\|cellular network]]) or [[Wikipedia:Local area network\|LANs]] (e.g. [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]). Some systems can have user interface, although this is not mandatory for tolling applications. The only specific requirement - that might not be present in [[Vehicle Trackers\|vehicle trackers]] - is integrity support, since tolling is a liability critical application. Depending on the architecture and on the pricing complexity, the OBU might have different requirements in terms of processing and storage capabilities.
Line 68:		Line 68:
	* '''Skymeter''': Has developed an OBU that is installed along with an LCD display to show the charged tolling and some other informations.		* '''Skymeter''': Has developed an OBU that is installed along with an LCD display to show the charged tolling and some other informations.
	* '''Toll Collect''': Has developed and is running the toll billing system for trucks (LKW-MAUT) on German motorways.		* '''Toll Collect''': Has developed and is running the toll billing system for trucks (LKW-MAUT) on German motorways.
	* '''Kapsch TrafficCom''': provides on-board units that are read/write devices designed to ensure high data security and integrity with high speed internal processing		* '''Kapsch TrafficCom''': provides on-board units that are read/write devices designed to ensure high data security and integrity with high speed internal processing.
	* '''EFKON''': The OBU autonomously determines the position of the vehicle, identifies road sections subject to tolling according to predefined rules, calculates the charge value (if any) inside the OBU, and transmits the result to the toll center		* '''EFKON''': The OBU autonomously determines the position of the vehicle, identifies road sections subject to tolling according to predefined rules, calculates the charge value (if any) inside the OBU, and transmits the result to the toll center.
	* '''Siemens VDO''': A hybrid OBU (on-board unit) in the vehicle manages both microwave and satellite-based toll systems		* '''Siemens VDO''': A hybrid OBU (on-board unit) in the vehicle manages both microwave and satellite-based toll systems.

	== Notes ==		== Notes ==

Rui.Pereira: moved Work in Progress:Tolling to Tolling over redirect

2011-05-27T15:47:08Z

moved Work in Progress:Tolling to Tolling over redirect

← Older revision	Revision as of 15:47, 27 May 2011
(No difference)

Rui.Pereira at 13:27, 26 May 2011

2011-05-26T13:27:07Z

← Older revision		Revision as of 13:27, 26 May 2011
Line 7:		Line 7:
	\|Logo=GMV		\|Logo=GMV
	}}		}}
	It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[http://www.gmv.com.pt/empresa_GMV/comunicacion/documentos_tecnicos/enc_gnss_2008-GNSS%20based%20road%20tolling%20systems.pdf Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>~~. On the other hand there's the need of implement urban tolling that is usually called Congestion Charge Zone (CCZ) with the aim to avoid urban pollution and urban traffic congestion~~. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.		It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS<ref>[http://www.gmv.com.pt/empresa_GMV/comunicacion/documentos_tecnicos/enc_gnss_2008-GNSS%20based%20road%20tolling%20systems.pdf Simulation tools for the assessment of GNSS based Road Tolling Systems], J Simón, J. Caro, J. Cosmen, GMV</ref>. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted<ref>[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0124:0143:EN:PDF Directive 2004/52/EC of Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community]</ref>.

	Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an ~~accuracy~~ level and the acquisition/generation of ~~some kind of irrefutable~~ evidences that can prove the amount ~~of applied charges~~.		Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an integrity level and the acquisition/generation of evidences that can be used to prove that the charged amount is correct.

	== Application Architecture ==		== Application Architecture ==

Teresa.Ferreira: /* Application Examples */

2011-05-25T14:37:41Z

Application Examples

← Older revision		Revision as of 14:37, 25 May 2011
Line 65:		Line 65:
	* '''Intelligent Mechatronic Systems''': Has developed the DriveSync® product which is a modular vehicle telematics system that uses Global Positioning System (GPS) and cellular technologies to track vehicles.		* '''Intelligent Mechatronic Systems''': Has developed the DriveSync® product which is a modular vehicle telematics system that uses Global Positioning System (GPS) and cellular technologies to track vehicles.
	* '''GMV''': Developed the allroadTM product which is a standalone OBU which guarantees a 99,99% of reliability bellow the established protection level (22 m in open sky environment and 75 m in urban environment).		* '''GMV''': Developed the allroadTM product which is a standalone OBU which guarantees a 99,99% of reliability bellow the established protection level (22 m in open sky environment and 75 m in urban environment).
	* '''Satellic''': Developed platform ~~makes it possible to implement~~ flexible road ~~toll~~ solutions based on free-flow-systems.		* '''Satellic''': Developed a platform that implements flexible road tolling solutions based on free-flow-systems.
	* '''Skymeter''': Has developed an OBU that is installed along with an LCD display to show the charged ~~tool~~ and some other informations.		* '''Skymeter''': Has developed an OBU that is installed along with an LCD display to show the charged tolling and some other informations.
	* '''Toll Collect''': Has developed and is running the toll billing system for trucks (LKW-MAUT) on German motorways.		* '''Toll Collect''': Has developed and is running the toll billing system for trucks (LKW-MAUT) on German motorways.
	* '''Kapsch TrafficCom''': On-board units are read/write devices designed to ensure high data security and integrity with high speed internal processing		* '''Kapsch TrafficCom''': provides on-board units that are read/write devices designed to ensure high data security and integrity with high speed internal processing
	* '''EFKON''': The OBU autonomously determines the position of the vehicle, identifies road sections subject to ~~toll~~ according to predefined rules, calculates the charge if ~~required~~ inside the OBU, and transmits the result to the toll ~~centre~~		* '''EFKON''': The OBU autonomously determines the position of the vehicle, identifies road sections subject to tolling according to predefined rules, calculates the charge value (if any) inside the OBU, and transmits the result to the toll center
	* '''Siemens VDO''': A hybrid OBU (on-board unit) in the vehicle manages both microwave and satellite-based toll systems		* '''Siemens VDO''': A hybrid OBU (on-board unit) in the vehicle manages both microwave and satellite-based toll systems

Teresa.Ferreira: /* Application Characterization */

2011-05-25T14:34:11Z

Application Characterization

Teresa.Ferreira: /* Application Architecture */

2011-05-25T14:22:58Z

Application Architecture

← Older revision		Revision as of 14:34, 25 May 2011
Line 38:		Line 38:
	== Application Characterization ==		== Application Characterization ==
	[[File:Road Features Examples.png\|Road Features Examples\|500px\|thumb\|right]]		[[File:Road Features Examples.png\|Road Features Examples\|500px\|thumb\|right]]
	The goal of this kind of application is ~~having~~ an “error-free” charging computation ~~which will make this application~~ acceptable by institutions and users ~~and with high utility value~~.		The goal of this kind of application is to have an “error-free” charging computation with high utility value, making it acceptable for institutions and users.
	Providing integrity of the computed position allows ensuring that vehicles are not charged incorrectly. This is done establishing a threshold value for the position protection level, i.e. if a computed position ~~corresponds to~~ a ~~protection value that exceeds the~~ threshold ~~value~~ that position it will not be used to compute charging values.		Providing integrity of the computed position allows ensuring that vehicles are not charged incorrectly. This is done by establishing a threshold value for the position protection level, i.e. if a given computed position exceeds a computed threshold, then that position will not be used to compute charging values.

	From the user point of view tolling ~~application will be working~~ in a transparent way since the user doesn’t have to operate the OBU ~~that are~~ installed on its vehicle. Eventually the user ~~receive~~ a monthly detailed report justifying the charged amount.		From the user point of view, tolling applications work in a transparent way, since the user doesn’t have to operate the OBU installed on its vehicle. Eventually the user receives a monthly detailed report justifying the charged amount.

	GNSS-based ~~tooling~~ relies on the detection of road features that will determine the ~~road usage~~ to be charged~~. The charge to be applied will be determined from~~ a ~~tariff that combines~~ the road usage ~~with other~~ related information ~~to reach the price to be charged~~.		GNSS-based tolling relies on the detection of road features that will determine the amount to be charged, as a combination of the road usage and related information.

	The road features that normally ~~are be~~ used for charging are<ref>ISO/TS 17575:2010 Electronic fee collection -- Application interface definition for autonomous systems</ref>		The road features that are normally used for charging purposes are<ref>ISO/TS 17575:2010 Electronic fee collection -- Application interface definition for autonomous systems</ref>
	* '''Zone''' - The car is charged when inside (or outside) a geographical zone.		* '''Zone''' - The car is charged when inside (or outside) a geographical zone.
	* '''Corridor''' - The car is charged when it goes through a geographical corridor or a sequence of corridors. A corridor normally corresponds to a road (although it can correspond to a set of parallel roads). A corridor is usually a rectangle that is crossed by the vehicle longitudinally. Direction might be relevant ~~depend~~ on the ~~charge~~ policy.		* '''Corridor''' - The car is charged when it goes through a geographical corridor or a sequence of corridors. A corridor normally corresponds to a road (although it can correspond to a set of parallel roads). A corridor is usually a rectangle that is crossed by the vehicle longitudinally. Direction might be relevant depending on the charging policy.
	* '''Virtual Gantry''' - The car is charged when ~~crosses~~ a virtual perpendicular line on the road in the same way as in going through a toll booth. A virtual gantry consists of two quadrilaterals joined by one side. The common side defines the line that when crossed triggers the charge. One of the quadrilaterals signals that the vehicle is entering the gantry and other ~~that is exiting the gantry~~. ~~To be changed the~~ vehicle needs to cross the entry quadrilateral, the virtual line and the exit quadrilateral in sequence.		* '''Virtual Gantry''' - The car is charged when crossing a virtual perpendicular line on the road, in the same way as in going through a toll booth. A virtual gantry consists of two quadrilaterals joined by one side. The common side defines the line that when crossed triggers the charge. One of the quadrilaterals signals that the vehicle is entering the gantry and the other its exit. The vehicle needs to cross the entry quadrilateral, the virtual line and the exit quadrilateral in sequence in order to be changed.

	Several road features can be combined to make more complex road features.		Several road features can be combined to make more complex road features.

	~~The identification of this road~~ features are ~~them~~ combined with other information to determine a charge. Some of this information can be:		Road's features are then combined with other information to determine a charge value. Some of this information can be:
	* '''Vehicle Characteristics'''		* '''Vehicle Characteristics'''
	* '''Time and Date'''		* '''Time and Date'''
Line 59:		Line 59:
	* '''Speed'''		* '''Speed'''

	The concept of road tolling can be used for other similar ~~application~~ such as CO<sup>2</sup> charging and pay what you drive insurance schemes.		The concept of road tolling can be used for other similar applications such as CO<sup>2</sup> charging and pay what you drive insurance schemes.

	== Application Examples ==		== Application Examples ==

← Older revision		Revision as of 14:22, 25 May 2011
Line 12:		Line 12:

	== Application Architecture ==		== Application Architecture ==
	ETC applications are implemented using On Board Units (OBUs) developed for that specific purpose that use GNSS data to compute the charging values. Some also integrate ~~with~~ additional sensors such gyroscopes, accelerometers or OBD (On-Board Diagnostics) input data to minimize ~~the effect of positioning errors may have in collecting~~ incorrect charges ~~and, in~~ particular, to prevent the charging of vehicles that are not using the road or urban area subject to toll.		ETC applications are implemented using On Board Units (OBUs) developed for that specific purpose that use GNSS data to compute the charging values. Some OBUs also integrate information from additional sensors - such as gyroscopes, accelerometers or OBD (On-Board Diagnostics) input data - in order to increase accuracy and minimize incorrect charges. In particular, to prevent the charging of vehicles that are not using the road or urban area subject to toll.

	The data collected by ~~the~~ the OBUs is sent to a central server that ~~consolidated~~ the payment information for the users of the system. These systems require a communication channel between the OBU and the central equipment. [[Wikipedia:Cellular network\|Cellular network]] is generally used by other means of communication can also be used such as [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]. [[Wikipedia:Cellular network\|Cellular network]] communication relies on ~~the~~ existing public networks while the other communication methods might require specific road side infrastructures.		The data collected by the OBUs is usually sent to a central server that consolidates the payment information for the users of the system. These systems require a communication channel between the OBU and the central equipment. [[Wikipedia:Cellular network\|Cellular network]] is generally used but other means of communication can also be used such as [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]. [[Wikipedia:Cellular network\|Cellular network]] communication relies on existing public networks while the other communication methods might require specific road side infrastructures.

	These OBUs can rely on [[SBAS Fundamentals\|Satellite Based Augmentation Systems (SBAS)]] like [[EGNOS General Introduction\|EGNOS]] or [[WAAS]] ~~achieving~~ better [[Accuracy\|accuracy]] and ~~making~~ decisions based on the [[Integrity\|integrity]]~~, reliability~~ and [[Availability\|availability]] provided by those systems. There are also devices equipped with built-in autonomous algorithms that handle and decrease the effects of local errors, such as non-line-of-sight multipath. These kinds of mechanisms guarantee an acceptable protection level (PL) for a ETC system dismissing the use of additional sensors that would add complexity and cost to the systems.		These OBUs can rely on [[SBAS Fundamentals\|Satellite Based Augmentation Systems (SBAS)]] like [[EGNOS General Introduction\|EGNOS]] or [[WAAS]] to achieve better [[Accuracy\|accuracy]] and to make decisions based on the [[Integrity\|integrity]] and [[Availability\|availability]] provided by those systems. There are also devices equipped with built-in autonomous algorithms that handle and decrease the effects of local errors, such as non-line-of-sight multipath. These kinds of mechanisms may guarantee an acceptable protection level (PL) for a ETC system, dismissing the use of additional sensors that would add complexity and cost to the systems.

	In terms of hardware requirements the devices used for tolling are very similar to [[Vehicle Trackers\|vehicle trackers]]. To support tolling a device should have GNSS support and have wireless communication abilities either through [[Wikipedia:Wide area network\|WANs]] (e.g. [[Wikipedia:Cellular network\|cellular network]]) or [[Wikipedia:Local area network\|LANs]] (e.g. [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]). Some systems can have user interface although this is not mandatory for tolling applications. The only requirement that might not be present in [[Vehicle Trackers\|vehicle trackers]] is integrity support ~~that is required~~ since tolling is a liability critical application. Depending on the architecture and on the pricing complexity the OBU might have different requirements in terms of processing and storage capabilities.		In terms of hardware requirements the devices used for tolling are very similar to [[Vehicle Trackers\|vehicle trackers]]. To support tolling, a device should have GNSS support and have wireless communication abilities either through [[Wikipedia:Wide area network\|WANs]] (e.g. [[Wikipedia:Cellular network\|cellular network]]) or [[Wikipedia:Local area network\|LANs]] (e.g. [[Wikipedia:Wi-Fi\|Wi-Fi]], [[Wikipedia:Bluetooth\|Bluetooth]], [[Wikipedia:Dedicated short-range communications\|DSRC]]). Some systems can have user interface, although this is not mandatory for tolling applications. The only specific requirement - that might not be present in [[Vehicle Trackers\|vehicle trackers]] - is integrity support, since tolling is a liability critical application. Depending on the architecture and on the pricing complexity, the OBU might have different requirements in terms of processing and storage capabilities.

	[[File:Tolling Process.png\|Tolling Process\|500px\|thumb\|right]]		[[File:Tolling Process.png\|Tolling Process\|500px\|thumb\|right]]
	The electronic fee collection (EFC) process implemented by this application can be divided in the following steps:		The electronic fee collection (EFC) process implemented by this application can be divided in the following steps:
	* '''Position Determination''' - Determination of the PVT (Position, Velocity and Time) using the GNSS data available that might be combined with other sensor data such as gyroscopes, accelerometers or OBD.		* '''Position Determination''' - Determination of the PVT (Position, Velocity and Time) using the GNSS data available that might be combined with other sensor data such as gyroscopes, accelerometers or OBD.
	* '''Road Usage''' - Determination of the roads features used by the vehicle being tolled. This information ~~will include~~ the time at which the vehicle used those road features.		* '''Road Usage''' - Determination of the roads features used by the vehicle being tolled. This information includes the time at which the vehicle used those road features.
	* '''Charge Calculation''' - Determination of the price to be ~~charge~~ to the owner or user of the vehicle.		* '''Charge Calculation''' - Determination of the price to be charged to the owner or user of the vehicle.
	* '''Payment''' - Payment of the charge		* '''Payment''' - Payment of the charge

	Although the main steps described ~~before~~ are ~~mostly~~ common to all EFC applications, the architecture of these systems can differ depending on which part of the system is run on the OBU or in the central system. Some possible approaches are<ref>Architecture Discussion for GNSS-based Electronic Fee Collection Systems: Fat vs. Thin OBU?, P. Gomes - GMV, R. B. Pereira - GMV, H. Appelbe - Mapflow, A. Mozes - Logica, ITS Europe 2007</ref>.		Although the main steps described previously are common to all EFC applications, the architecture of these systems can differ depending on which part of the system they are run: in the OBU or in the central system. Some possible approaches are<ref>Architecture Discussion for GNSS-based Electronic Fee Collection Systems: Fat vs. Thin OBU?, P. Gomes - GMV, R. B. Pereira - GMV, H. Appelbe - Mapflow, A. Mozes - Logica, ITS Europe 2007</ref>.
	* '''Fully Centralized''': In this architecture the OBU is a very light footprint and cost-effective device, with a reduced processing power. Its only task is '''Position Determination''' to calculate the PVT (Position, Velocity and Time), combine it with the identification of the vehicle and transmit the data to the central server. The central server receives the PVT data and is responsible for the remainder of the EFC process (road usage calculation and charge calculation).		* '''Fully Centralized''': In this architecture the OBU is a very light footprint and cost-effective device, with a reduced processing power. Its only task is '''Position Determination''', i.e. to calculate the PVT (Position, Velocity and Time), to combine it with the identification of the vehicle and to transmit the data to the central server. The central server receives the PVT data and is responsible for the remainder of the EFC process (road usage calculation and charge calculation).
	* '''Partially Centralized''': The OBU uses the PVT to calculate ~~the~~ '''Road Usage''' and ~~send~~ this information to the central server.		* '''Partially Centralized''': The OBU uses the PVT to calculate '''Road Usage''' and sends this information to the central server.
	* '''Fully Decentralised''': The OBU makes the '''Charge Calculation''' step calculating the charge. This architecture might even include the payment in the OBU using electronic purse cards.		* '''Fully Decentralised''': The OBU makes the '''Charge Calculation''' step calculating the charge. This architecture might even include the payment in the OBU using electronic purse cards.

	The choice of the adequate architecture ~~will be~~ a ~~balance~~ between the cost of OBU and the operation cost. Centralized architectures can use cheaper OBUs with less memory while decentralised architectures will require more processing power to calculate road usage and the charges ~~and~~ more memory to store context data such as maps and tariff information. Centralized architectures ~~will~~ require more upload bandwidth to send road usage to the central server ~~while~~ decentralized ~~will requires~~ more download bandwidth to update context data. ~~Another~~ relevant factors in the choice of architecture will be privacy and enforcement. These are usually conflicting factors since centralized architectures might raise ~~more~~ privacy concerns ~~while~~ are more easily monitored for fraud ~~and~~ decentralized architectures ~~will be~~ more protective of the user privacy ~~while~~ more difficult to monitor for fraud.		The choice of the adequate architecture is a trade-off between the cost of OBU and the operation cost. Centralized architectures can use cheaper OBUs with less memory while decentralised architectures will require more processing power to calculate road usage and the charges, as well as more memory to store context data such as maps and tariff information. Centralized architectures require more upload bandwidth to send road usage information to the central server, whereas decentralized architectures require more download bandwidth to update context data. Other relevant factors in the choice of architecture will be privacy and enforcement. These are usually conflicting factors since centralized architectures might raise privacy concerns since they are more easily monitored for fraud. Conversely, decentralized architectures are more protective of the user privacy, hence more difficult to monitor for fraud.

	These applications are considered liability-critical applications.		These applications are considered [[Criticality of GNSS Applications\|liability-critical applications]].

	== Application Characterization ==		== Application Characterization ==