AU2012101486A4 - Method and system for providing speed limit and advisory updates to users of a receiving device - Google Patents

Abstract

A method and system for providing the reference speed limit and advisory information for a given road to a user of a receiver is disclosed. Speed limit and advisory information is sent to a receiving device and includes data to be stored in the memory of the receiver. The formation of the speed limit update and advisory messages is performed and then sent using a broadcasting system. The speed limit and advisory data update is stored in the receiver; the system checks the digital map against the received data to make available the reference speed limit and advisory information. BROADCASTSYSTEM 20 i M 30 ~ DATA20(4) ENCODER& BROADCAST TRANSMrlTER RD5 ENCODING 20(3) F 20(5) CONTROL 20(2)| SOFTWARE pJ DATA FROM EXTERNAL |DBGR 5YSTEMS20(1)

Description

1 METHOD AND SYSTEM FOR PROVIDING SPEED LIMIT AND ADVISORY UPDATES TO USERS OF A RECEIVING DEVICE. FIELD This invention relates generally to providing a protocol for use in broadcasting the reference speed limit and other advisory information to Advanced Driver Assistance Systems (ADAS) or users of message receivers as found in navigation devices or smart phones. BACKGROUND Intelligent Speed Assist (ISA) is a generic term for a class of Advanced Driver Assistance Systems (ADAS) in which the driver is warned and/or vehicle speed is automatically limited when the driver is, intentionally or inadvertently, travelling over the regulatory speed limit for a given location. ISA systems establish the position of the vehicle, compare its current speed with the reference speed limit and respond if the vehicle exceeds this limit. ISA systems obtain information regarding the current position of the vehicle and the speed limit that applies to that location via a range of technical solutions. The most widely used approach utilises global positioning system (GPS) technology. Information regarding the road network and the speed limits are stored in an onboard digital map. The location of the vehicle on the road network is determined by a GPS receiver and based on information derived from the GPS. An on-board computer continuously analyses the location of the vehicle and compares the map speed limit for that location with the current (GPS-derived) speed of the vehicle. A warning is delivered when the onboard system recognises that the vehicle is travelling faster than the maximum speed limit for the current location. In most cities, it is common for the broadcast of data messages to supporting devices to advise such events as; Traffic Message information (TMC), Radio Station name (RS), Program Type (PTY), Radio Text (RT), and Radio Paging (RP). The messages are broadcast on a continuous or periodic basis. Message receivers can be found in such devices as radios, smart phones and GPS devices. These devices decode the data and present this information. One protocol for broadcasting these messages is the Radio Data System (RDS) for VHF/FM sound broadcasting in the frequency range from 87.5 to 108.0 mhz. These broadcast messages as defined in the RDS standard are used in Australia, New Zealand, Europe and elsewhere. Message broadcasts can also be transmitted on other broadcast systems including Digital Audio Broadcasting ("DAB"), Digital Multimedia Broadcasting ("DMB"), Hybrid Digital Radio ("HD Radio"), Digital Radio Mondiale (DRM), satellite radio and/or other protocols and radio systems. In these systems, the data messages conform to one or more pre-defined specifications and the message receiver decodes these messages. The security of message information is provided for within the RDS specification with the encrypting of message information and rendering it unusable until a receiving device has been authorised to decrypt the information, usually on payment of a subscription. Collison ref: 62951 2 The use of the traffic message channel for the provision of speed limit data is not possible due to limitations as to what can be transmitted as part of the traffic message protocol. Digital maps by their very nature are complex and proprietary, cannot be incrementally updated and require large amounts of memory or disk storage. The map information is never current as map publication updates are generally done annually and even when newly published, the speed limit information for any given area can be out of date. It is highly desirable to provide another method of messaging data which would meet the needs of Advanced Driver Assistance Systems (ADAS) and make available real time speed limit road network data. Thus, it would be beneficial to provide a means of transmitting speed limit road network data and other messages to supporting device such as ADAS, GPS and smart phone device. This method for real time broadcast of speed limit changes for fixed, variable and temporary limits, together with advisory information on speed zones and location information for speed cameras, red light cameras and point-to-point cameras is proposed. OBJECT OF THE INVENTION It is an object of the present invention to provide a method of providing speed limit and advisory information to a recipient. It is an object of the present invention to overcome, or at least substantially ameliorate, the disadvantages and shortcomings of the prior art. Other objects and advantages of the present invention will become apparent from the following description, taking in connection with the accompanying drawings, wherein, by way of illustration and example, an embodiment of the present invention is disclosed. SUMMARY According to the present invention, although this should not be seen as limiting in any way, there is provided a method and system for providing speed limit and advisory information to users and/or for use in Advanced Driver Assistance Systems is disclosed. A broadcast system transmits a series of messages to a message receiver. These messages include data to be stored in the memory of the receiver. The transmission of speed limit messages is performed as a transparent routine to the regular transmission of RDS messages which may include traffic information. Over a period of time, the transparent routine updates the memory of the receiver to include road network speed limit updates and other advisory information relevant to the current transmission reception area. In preference, the series of messages includes a first message and a second message. In preference, the first message is a user authorisation message, to verify the receiver is authorised to receive the second message. In preference, the second message contains location specific traffic information. Collison ref: 62951 3 The speed limit data and advisory information stored in the message receiver is generally only used if the user is travelling or the planned route, uses the road segment specified in the message. Text or text-to-speech advisory information in the message receiver is presented to the user based on an alert flag or validation based on the first message. In an example, the broadcast system transmits a first message that includes an alert flag. The message details "Your device has been updated". Upon receipt of the message with an alert flag, the message receiver retrieves the information (second message) and presents this information to the user or system of the receiver. In a further embodiment of the present invention there is described a method of providing speed limit and advisory information to an end-user or system of a message receiver, comprising: receiving a first message at the message receiver that causes the message receiver to recognise a second message; receiving the second message having data representing speed limit and advisory information; and storing the data representing the speed limit and advisory information in memory of the message receiver. In preference, In preference, the second message conforms to a proprietary protocol that co-exists within the same transmission as the first message. In preference, the method further comprises a method for comparing and analysing speed limit information from the geographic map database utilising the speed limit and advisory information in memory of the message receiver. In preference, the method further comprises a method for providing updated speed limit and advisory information for a road segment from information in memory of the message receiver. In preference, the message conforms to a Radio Data System (RDS) message broadcasting standard. These aspects and advantages will become apparent in reading the following detailed description, with reference, where indicated to the accompanying drawings. It is advised that this summary is merely an example and is not intended to limit the scope of the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is diagram illustrating components of a broadcast system, varies methods of transmission in a geographic region; FIG. 2 is a block diagram illustrating components of a vehicle with an on-board navigation system, as would be used in FIG. 1; FIG. 3 is a diagram illustrating data included in a message; Collison ref: 62951 4 FIG. 4 is a block diagram illustrating a receiver, as shown in FIG. 2; FIG. 5 depicts a message format for a message transmitted to the receiver, as shown in FIG. 2; FIG. 6 depicts a message format for a message transmitted to the receiver, as shown in FIG. 2; FIG. 7 depicts message format for a message transmitted to the receiver, as shown in FIG. 2; FIG. 8 is a block diagram illustrating an organisation of the geographic map database, as shown in FIG. 2; DETAILED DESCRIPTION I. Broadcast System Overview FIG. 1 is a diagram illustrating a region 10. The region 10 may be a metropolitan area, such as the Adelaide metropolitan area, the Sydney metropolitan area, or any other metropolitan area. Alternatively, the region 10 may be a state, territory, such as South Australia or the Australian Capital Territory. Alternatively, the geographic region 10 can be a combination of one or more metropolitan areas, states, territories and so on. Located in the region 10 is a road network 11. A broadcast system 20 is also located in the region 10. The broadcast system 20 broadcasts data 30 which can include such items as radio station name and traffic messages in the region 10. As described with respect to FIGS. 5-7, the broadcast system 20 can also broadcasts data 30 regarding speed limit and other advisory information. The broadcast system 20 may be operated by a government agency or may be privately operated. The broadcasting system 20 conforms to a digital message format and defined rules which is carried over RDS, GPRS, DAB, DMB, DRM, HD Radio, and so on. Vehicles 12(A), 12(B), 12(C), 12(D) travel on the road network 11 in the region 10. The vehicles 12 may include a variety of cars, trucks and motorcycles. Some or all of the vehicles 12 include relevant equipment that enables them to receive the data 30 broadcasts by the broadcast system 20. The data 30 broadcasts from the broadcast system 20 may also be received and used in systems 90 that are not installed in vehicles (non-vehicle systems). These non-vehicle systems 90 may include, computers, notebooks, tablet devices, smart phones, televisions, radio receivers and so on. The non-vehicle systems 90 may receive the data 30 in the same manner as the vehicles 12. Alternatively, the non-vehicle systems 90 may receive the data 30 by other means, such as over fixed phone or fax lines, over the Internet, via cable and so on. The systems in the vehicles 12 and the non-vehicle systems 90 that receive the data 30 may include various different computing platforms. Collison ref: 62951 5 The broadcast system 20 provides for the collection of data from external systems relating to speed limit and advisory information. The collected data, the formatting of the data into messages and the transmission of these messages to the vehicles 12 in the region 10 is performed on a regular or continuing basis. The broadcast system 20 includes equipment and programming 20(1) for collecting the data relating to speed limit and advisory events in the region 10 from the external systems. This equipment and programming 20(1) includes, for example, various communications links (including wireless links), receivers, data storage devices, programming that saves the collected data. The broadcast system 20 also includes equipment and programming 20(2) for assembling, organising and formatting the collected speed limit and advisory data, which form part of the second message. This programming and equipment 20(2) includes RDS plugin, storage devices, programming that analyses the collected data for potential errors, programming that organises the collected data, programming that uses the data to prepare messages. The broadcast system 20 also includes suitable equipment and programming 20(3) for encoding the broadcasting data 30 into messages in one or more predetermined formats. The data 30, which includes both the first and second messages, can be the speed limit and advisory data collected and organised by the broadcast system 20. The equipment and programming 20(4) includes interfaces to encode and transmit, programming that communicates formatted messages at regular intervals to the transmitters. The broadcast system 20 also includes transmission equipment 20(5). This equipment 20(5) may comprise one or more FM, HD, DAB, GPRS or other transmitters, including antennas or other wireless transmitters. This equipment 20(5) provides for broadcasting the formatted messages as data 30 throughout the region 10. The broadcasting equipment 20(5) may be part of the broadcast system 20, or alternatively, the broadcast system 20 may use broadcasting equipment from other types of systems, such as paging systems, mobile phone systems, AM/FM radio stations and so on, to broadcast the data 30 to the vehicles 12 in the region. The broadcasting of data 30 includes any form of transmission, including direct wireless transmission. FIG. 3 illustrates the data 30 for an example message. The message can include various kinds of data 30. One useful kind of information that the message can include relates to variable speed limit changes. When used to provide information about speed limits, the message includes data 30 that identify one or more locations along a road segment that have changed speed limits, for which direction, and reason for the change. In the example shown in FIG. 3, the data 30 includes the following data components in the form of a first message and a second message: an alert flag 40(1) (first message), when set, will display or text-to-speech (TTS) the message text 40(10) (second message), region location information 40(2), an alert item 50(3) such as advisory/temporary, an alert type 50(4) such as variable speed limit, a application ID 40(5), class 40(6) such as car/truck, road location 40(7) includes a reference number that identifies the Collison ref: 62951 6 location for the affected road, direction of travel 40(8) for the limit change, and updated speed limit 40(9). The data 30 for the message may also include components that provide other information 40(x). The data 30 forms part of a specification for free format group messages established in the RDS system. The second message may form part of the first message but be wrapped up inside the first message and not available to the end user/recipient until such time as it is decoded. II. Navigation System Overview FIG. 2 depicts the components of one of the vehicles 12 shown in FIG. 1. The vehicle 12 may be a car, a truck, a motorcycle, or any other type of vehicle found in the region 10. A navigation system 100 is installed in the vehicle 12. The navigation system 100 is a combination of hardware and software components. In one embodiment, the navigation system 100 includes a control unit 130, database storage 151 being memory card, drive or other, connected to the control unit 130, and a non-volatile memory storage device 110 for storing a navigation application software program 120 and other information. The control unit 130 may consist of any type of central processor suitable for navigation systems. The navigation system 100 may also include a positioning system 131. The positioning system 131 may utilise GPS type technology, a dead reckoning type system or combinations of these or other systems. The positioning system 131 may include suitable sensing devices 132 that measure the travelling distance, speed, direction, and so on, of the vehicle 12. The positioning system 131 may also include appropriate technology to obtain a GPS signal. The positioning system 131 outputs a signal to the control unit 130. The signal from the positioning system 131 may be used by the navigation application software 120 that is run on the control unit 130 to determine the location, direction, speed, and so on, of the vehicle 12. The vehicle 12 includes a message receiver 134. The receiver 134 receives the data 30 from the broadcast system 20. For example, the receiver 134 may be an FM receiver tuned to an appropriate transparent frequency at which the broadcast system 20 is using to broadcast the data 30. The receiver 134 provides an output to the control unit 130 so that appropriate programming in the navigation system 100 can utilise the data 30 broadcast by the broadcast system 20 when performing speed limit comparison functions. FIG. 4 is a simplified block diagram of the message receiver 134 that may be used in the navigation system 100 depicted in FIG. 2. In this example, the receiver 134 is an RDS receiver. However, receiver design depends on the type of broadcast system 20 transmitting the data 30 and thus, the receiver 134 is not limited to any particular type of receiver. The receiver 134 includes an RDS decoder 136 that receives and formats the data 30 so as to make the contents of the second message, the traffic advisory information, available to be displayed. The RDS decoder 136 provides the formatted data to the control unit 135. The control unit 135 interprets the data and determines what action to take based on the data. For example, the control unit 135 may read data from or write data to memory 137. The memory 137 is not Collison ref: 62951 7 limited to any memory type. FIG. 4 depicts the receiver 134 having its own control unit 135 and memory storage 137, it is understood that the receiver 134 may share processing and memory with the navigation system 100 (i.e. an integrated system). For example, the receiver 134 may use the control unit 130 and the non-volatile memory 110. The receiver 134 may have additional components not depicted in FIG. 4. FIG. 2, the navigation system 100 also includes a user interface 140. The user interface 140 includes appropriate equipment that allows the end-user to input information into the navigation system 100. This input information may include a request to use the navigation features of the navigation system 100. For example, the input information may include a request for a route to a desired destination. The input information may also include requests for other kinds of information. The user interface equipment used to input information into the navigation system 100 may include a keypad, a keyboard, a microphone, and so on, as well as appropriate software, such as a voice recognition program. The user interface 140 also includes suitable equipment that provides information back to the end-user. This equipment may include a display 141, speakers 142 and other communication means. The navigation system 100 uses a map database 150 stored on a storage medium 138. The storage medium 138 is installed in the storage apparatus 151 so that the map database 150 can be read and used by the navigation system 100. The storage medium 138 may be removable and replaceable so that a storage medium with a compatible map database for the geographic region in which the vehicle is travelling can be used. In addition, the storage medium 138 may be replaceable so that the map database 150 on it can be updated easily. The geographic data 150 may be a geographic database published by any map providers so long as data 20(1) meets the data message 30 specification required for broadcast system 20. In one embodiment, the storage medium 138 is a CD ROM disk. In an alternative embodiment, the storage medium 138 may be a memory card in which case the storage apparatus 151 would be substituted with a memory card slot. Various other storage media may be used, including fixed or hard disks, DVD disks, or other currently available storage media, as well as storage media that may be developed in the future. The storage medium 138 and the geographic database 150 do not have to be physically provided at the location of the navigation system 100. In alternative embodiments, the storage medium 138, upon which some or all of the geographic data 150 are stored, may be located remotely from the rest of the navigation system 100 and portions of the geographic data provided via a communications link, as needed. In one type of system, the navigation application software program 120 is loaded from the non volatile memory 110 into a Random Access Memory (RAM) 133 associated with the control unit 130 in order to operate the navigation system 100. The control unit 130 also receives input from the user interface 140. The input may include a request for navigation information. The navigation system 110 uses the map database 150 stored on the storage medium 138, possibly in conjunction with the outputs from the positioning system 131 and the receiver 134 data, to Collison ref: 62951 8 provide various navigation features and functions. The navigation application software program 120 may include separate applications (or subprograms) that provide these various navigation features and speed advisory functions. These functions and features may include route calculation 121 (taking into account speed limit information), route guidance 122 (wherein detailed directions are provided for reaching a desired destination), map and speed display 123, and vehicle positioning 124 (i.e., displayed on map). Other functions and programming 125, in addition to these, may be included in the navigation system 100. The navigation application program 120 may be written in a suitable computer programming language such as C, although other programming languages, such as C++ or Java, are also suitable. FIG. 7 is a block diagram showing an example organisation of the geographic database 150 depicted in FIG. 2. In this example, the geographic database 150 is organised by data type. One way that the accessing of geographic data can be enhanced for performing various navigation functions is to provide separate collections or subsets of the geographic data 150 for use by each of the separate functions in the navigation application program 120. Each of these separate subsets is tailored specifically for use by one of the functions. For instance, the route calculation function 121 (in FIG. 2) normally requires only a portion of all the information in the geographic database 150 and receiver memory 134 that is associated with the road segment. When the route calculation function 121 is being run, it may require information such as the speed along a road segment, in which it will check both the map database 150 and check if there is an update received for that road segment in the receiver's memory 137. The route calculation will use the most current information. When using the map display function 141, information associated with a road segment, such as the speed limits can be displayed. When the map display function 141 is run, it uses only a portion of the information associated with the road segment, such as the shapes and locations of roads, names of the roads and current speed limit for direction of travel. Although there may be some overlap as to the types of information used by the various navigation functions, some of the data used by these navigation functions is only used by one of the functions. If all the information relating to each road segment were associated with it as a single data entry in a single database, each data entity record would be relatively large. Thus, whenever any one of the navigation functions accessed an entity record, it would have to read into memory a significant amount of information much of which would not be needed by the navigation function. Moreover, when reading the data entity from disk, relatively few data entities could be read at a time since each data entity would be relatively large. In order to provide the information in the geographic database 150 in a format more efficient for use by each of the navigation functions, separate subsets of the entire geographic database 150 for a given geographic region are provided for each of the different types of navigation functions to be provided in the navigation application program 120. FIG. 8 illustrates the Collison ref: 62951 9 geographic database 150 comprised of separate routing data 210 (for route calculation), cartographic data 211 (for map display), manoeuvre data 212 (for route guidance), point-of interest data 213 (for identifying specific points of interest, such as hotels, restaurants, airports, etc.), and junction data 214 (for identifying named intersections). In addition to these types of data, the geographic database 150 may include navigation feature data 215. This subset of data includes names of navigable features (such as roads). The geographic database 150 may not include all of these subsets. Moreover, the geographic database 150 may include other subsets of data 218. III. Providing Speed limit Updates It would be desirable to provide speed limit information and advisory notices to end-users or systems of the message receiver 134. To provide this speed limit and advisory notice information, the broadcast system 20 transmits messages which may include other system messages such as traffic messages. The message receiver 134 receives the messages and stores the data in these messages in the receiver's memory 137. This routine may operate in a continuous manner so that over time the receiver's memory 137 contains continually updated speed limit road data. The broadcast system 20 may transmit the speed limit messages at a slower rate than other messages such as traffic messages so that the continual updating of the receiver memory 137 does not interfere with each other. Additionally, the broadcast system 20 may transmit the speed limit messages when the broadcast system 20 does not have other messages to broadcast. For example, if the broadcasting system 20 typically broadcasts one hundred messages every five minutes in a region and only fifty messages are available, the broadcasting system 20 may transmit speed limit messages in the available bandwidth. The broadcasting system 20 may also limit the number of speed limit and advisory messages transmitted during a period of time. Upon detection of an alert flag (first message), the message receiver 134 provides advisory information (second message) to end-users or systems using the message text data. The alert flag together with positioning information 131, such as entering a road segment with a new speed limit will alert the user to this change. The end-user can receive speed limit and advisory information on devices which incorporate modifications to the navigation 120 operating system. No hardware modifications to the receiver 134 is required and there is no impact on the original purpose of the receiver 134. The following is a description of one example of how to provide speed limit information to the end-user or system of a message receiver. In this example, the protocol used for the messages is the RDS protocol (described in EN ISO 14819-1:2003), and the protocol used for the speed limit messages is a proprietary protocol. The proprietary protocol is recognised by the message receiver 134 by registering the protocol as an Open Data Application ("ODA") as described in the RDS standard. Upon registration, an application identifier ("AID") is assigned to the protocol. The receiver 134 recognises the application identifier without modifying the receiver Collison ref: 62951 10 134. This invention is not limited to these protocols. The general concepts of using a background routine for storing the speed limit data on a message receiver and using an alert flag for providing advisory information to a user of the receiver apply to other broadcast protocols and transmitted on different bearers such as FM, AM, GPRS, DAB, DRM, DMB, HD Radio, and so on. FIG. 6 depicts a message format 400 that is used to store speed limit information in the memory 137 of the receiver 134. The message format 400 is also used for triggering the receiver 134 to display advisory information to the user via the user interface 140. The broadcast system 20 transmits data using the message format 400 in a repetitive manner. In this way, the receiver's memory 137 is updated in a continuous manner. For example, the messages may be transmitted every 28 RDS groups (i.e., 1 group/2.5 seconds). As shown in FIG. 6, the message format 400 follows the group type 12A format as described in the RDS standard (EN ISO 14819-1:2003). However, any Open Data Application group that is available (i.e., not already assigned to a standard application) may be used for the message format 400. The message format 400 includes thirty-seven bits identified as x4-xO, b15-b0, and c15-c0 in FIG. 6. The message bits that contain "rfu" are reserved for future use. Bits x4-x2 represent a message type 401. When x4, x3 and x2 all contain a logic-0 value, is message type 401 and is a string having up to thirty-four characters. The string includes "class" (x1-b15) used to define i.e., car/truck etc. and "persistent ID" (b14-cO) used to define the road segment of the message format 400. When x4 contains a logic-0 value, x3 contains a logic-1 value and x2 contains a logic-0, is message type 402 and is a string having up to thirty-three characters. The string includes "direction" (b14-b13) to define direction of travel, "speed limit" (b12-b8) to define speed limit and "text" (b7-cO), which define the text which is represented by four groups of a six-bit code. A reduced ASCII character set is used. For example, the text message may be "NEW SPEED LIMIT IN PLACE" of the message format 400. When x4 contains a logic-1 value, x3 and X2 contains a logic-0 value, the message type is 403 and is a string having up to thirty-four characters. The string includes "direction" (b14-b13) to define direction of travel, "speed limit"(b12-b8) to define speed limit and "phoneme text" (b7 cO) which define the phoneme text which is represented by four groups of a six-bit code. A phoneme message is a message in phoneme format; the SAMPA phoneme standard is used. The actual phoneme message is located in the character bits 403. When x4 and x3 contains a logic-1 value, and X2 contains a logic-0 value, the message type is 404 and is a string having up to thirty-four characters. The string includes "direction" (b14-b13) to define direction of travel, "speed limit" (b12-b8) to define speed limit and "phoneme text" (b7-cO) which define the phoneme text which is represented by four groups of a six-bit code. A Collison ref: 62951 11 phoneme message is a message in phoneme format; the SAMPA phoneme standard is used. The actual phoneme message is located in the character bits 404. When x4, x3, x2 contain other value not described about, the message type is 405 and is undefined. As the message type is undefined, the remaining bits in the message are reserved for future use. For the message type 402, 403 and 404, "slot" data 406 is used for the text and phoneme message information. The slot data 406 identifies the character slots for the text and phoneme messages. For example, the slot data 406 consisting of binary 000 identifies character slots 1, 2, 3, 4; the count data 406 consisting of binary 001 identifies character slots 5, 6, 7, 8; and so on. Bits x1-c0 include a reserved area identifier 405. This area is reserved for future use. FIG. 5 depicts a message format 500 that is used to identify the specific group type used by the registered Open Data Application. The message format 500 is also used for indicating which region is current and the alert flag the receiver 134 will use to send information to the user or system. Preferably, the broadcast system 20 transmits data 30 using the message format 500 every 7.5 seconds; however, other transmission schedules (both regular and irregular) may also be used. At one group per seven-and-one-half-seconds, the receiver 134 is updated as to which speed is active in each type every two minutes. The message format 500 follows the type 3A group format as described in the RDS standard (EN ISO 14819-1:2003). The type 3A group conveys to the receiver 134 information about which Open Data Applications are carried on a particular transmission and in which groups they will be found. The message format 500 includes an Application Group Type code 322 (y4-yO), an Applications Identification (AID) code 332 (e15-eO), and message bits 502-505 (e15-eO). The Application Group Type code 501 indicates the group type used, in a particular transmission, to carry the specified Open Data Application. The first four bits (y4-y1) identifies the group type code, while the fifth bit (yO) identifies the group type version. In the example depicted in FIG. 5, the Application Group Type code 501 defines Open Data Application group 12A, which corresponds to the Open Data Application group format depicted in FIG. 6. The Applications Identification code 506 is a unique value that identifies a registered Open Data Application. After the receiver 134 receives a message with the type 3A group format specifying the Applications Identification code 506, the receiver 134 recognises messages having the Application Group Type code 501. Otherwise, the receiver 134 ignores these messages. In this example, the Applications Identification 506 is Hex 0000, which is an unspecified Application Identification. The message bits 502-505 contain the Open Data Application. In the example depicted in FIG. 5, the message bits include an alert flag 502 (e15), a region ID 503 (e14-e7), an alert item identifier 504 (e6-e4), and a alert type identifier 505 (e3-eO). Collison ref: 62951 12 The alert flag 502 is a single bit that identifies when to provide text information to the end-user of the receiver 134. Either a logic-0 or a logic-1 value can be used as a triggering event. When the alert flag 502 is set, a text or phoneme message is triggered and presented to the end-user as described with respect to FIG. 6. The region ID 503 identifies a region. Up to 256 regions can be defined. A region may be defined as a country, a region, a state, a city, a suburb, and so on. The receiver 134 may store records for up to 256 unique regions if memory allows, but generally records will be stored for two or three regions (e.g., a region and the regions to which a user travels). The alert identifier 504 identifies an alert item, such as regulatory, advisory, temporary, and so on. Up to sixteen alert items are available per transmission. The active alert item identifier 504 identifies what item is active for the alert type identified by the alert type identifier 505. Up to eight different alert items are available for each alert type category. Upon receipt of the alert flag 502, receivers 134 in the region identified in the region identifier 503 provide information for the alert item identified in the alert item identifier 504 for the alert type category identified by the alert type identifier 505. FIG. 7 is a flowchart of a method 600 for providing speed limit and other information using a RDS message channels. The method 600 uses a triggering mechanism for providing text information to an end-user of a message receiver. At block 601, the receiver 134 receives messages for updating speed limit information stored in the receiver's memory 137. At block 602, the receiver 134 receives a message triggering an alert message. As described with reference to FIG. 5, a message bit (e15) is assigned as the alert flag 502. The receiver 134 recognises when the alert flag 502 is set. This triggering mechanism may be described as an over-air trigger. At block 603, the receiver 134 retrieves the appropriate data from the receiver's memory 137. The receiver 134 selects the text data based on the alert type category identified in the alert type identifier 505, the active alert item identified in the active alert item identifier 504, for the region identified in the region identifier 503 of the triggering message. The information may be any information that the provider wants to provide an end-user of the receiver 134. At block 604, the retrieved information is sent to the end-user. The information is presented verbally and/or textually by the navigation system's user interface 140. Additionally or alternatively, the location(s) of the active alert item in the current region are identified on a map presented on the display 141. By using an Open Data Application for delivering speed limit and advisory information to the receiver 134, the information can be provided to end-users or systems regardless of location on a road network. Instead, the information can be delivered based on the broadcast area. Moreover, the speed limit information can be delivered without any hardware modifications to Collison ref: 62951 13 the receiver 134. As an additional benefit, the amount of data to be stored in the message receiver's memory 137 is minimal. As described with reference to FIG. 6, the necessary capacity of the memory 137 may be less than 32k bytes. Memory requirements may change based on the number of alert types, speed limit changes and text characters actually stored. While the example was described using the RDS standard (EN ISO 14819-1:2003), it is understood that other broadcast system standards may also be used to store speed information on a message receiver and then present the appropriate information to the receiver's end-user based on requirements. It is also understood that stream, packet, and other data transmission formats may be used to transmit data to the receiver. It is also understood that data having other data formats, including video and audio, may be stored on and retrieved from the receiver. The messages are not limited to a text or phoneme data format. In addition, the speed limit and advisory messages may include any type of information that the provider would like to provide to the receiver's end user or system and is not limited to speed limits. Moreover, the provider may target speed limit messages to particular types of message receivers. For example, a heavy vehicle manufacturer may advise on restricted speed limits for a class of vehicles to all message receivers installed in that manufacturer's vehicle. It is intended that the foregoing detailed description be regarded as illustrative rather than limiting and that it is understood that the following claims including all equivalents are intended to define the scope of the invention. The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention. Collison ref: 62951

Claims (5)

1. A method of providing speed limit and advisory information to an end-user or system of a message receiver, comprising: receiving a first message at the message receiver that causes the message receiver to recognise a second message; receiving the second message having data representing speed limit and advisory information; and storing the data representing the speed limit and advisory information in memory of the message receiver.

2. The method of claim 1, wherein the second message conforms to a proprietary protocol that co-exists within the same transmission as the first message.

3. The method of claim 1, further comprising a method for comparing and analysing speed limit information from the geographic map database utilising the speed limit and advisory information in memory of the message receiver.

4. The method of claim 1, further comprising a method for providing updated speed limit and advisory information for a road segment from information in memory of the message receiver.

5. The method of claim 1, wherein the message conforms to a Radio Data System (RDS) message broadcasting standard. Collison ref: 62951