Patent Application
20070279226
An example of an RFID transceiver tag and a monitoring system including plural such tags, according to the invention, will now be described with reference to the accompanying drawings, in which:
The monitoring system of this example utilises three RFID tags 10A, 10B, 10C. Each is identical in components, but is distinguishable from the other RFID tags by a tag ID held in memory within the tag (see below).
The controller 20 (see
TTP's Matrix RFID technology consists of a hardware and software platform encompassing an off-the-shelf high frequency transceiver 211,212 with integrated microcontroller 210 operating in the instrument, scientific and medical band (˜433 MHz). The Matrix RFID module 209 interfaces to the key switch 203, sounder 206 and LED's 204, 205 and its microcontroller 210 runs a basic Matrix stack and a specially written controller application. It is capable of operating in 433, 868 and 915 MHz bands, selectable in software. Four different transmitter power levels are usable, configurable through software. In addition the controller 20 has 4K Flash ROM 214, containing the Matrix stack software (device driver level) and the controller application software (application level). Each RFID tag (see
The microprocessor 106 includes a ROM110 containing the stack and application software.
In this example, three tags 10A, 10B, 10C are provided for a system for securing three articles 30A, 30B, 30C against unauthorised movement (e.g., theft) and set up of the system is as follows.
There are four possible states for the system to be in and these are:
The alarm can be reset using the arming key (not shown) in the key switch 203 by placing the controller into the disarmed state. The Installation, Armed and Disarmed states are selected using the three different positions of the key switch 203. The controller's LED 204 indicates which mode is currently selected by flashing several times per second in the Installation state and once every two seconds in all other states.
The four system states are described below.
This is the initial state of the system. The controller 20 is plugged in and switched on with the key switch 203 in its “Adopt Tags” position. At this point the controller knows nothing about the tags 10. The controller broadcasts a message (see below) periodically on very low power that advertises the next available tag ID, starting at “1”. Any tag 10 that has previously not been adopted by the controller responds to this broadcast with a message accepting the adoption. The controller 20 then responds to the tag confirming its acceptance of the tag into its group and updates its own internal count of adopted tags in order that it can broadcast to the next tag ID. In a production system, the tags have ID's set at manufacture and the controller enumerates the tags with a local group ID or something. This prevents collision because the controller individually addresses the tags to confirm their local group ID. Each tag 10 as it is adopted now leaves it's uninitialised state and enters a disarmed state while the controller 20 continues to advertise the next available tag ID. The process continues until the controller 20 is set to enter its disarmed mode (by the key switch 203) or the number of adopted tags 10 reaches the maximum allowed for in the system (this can vary from system to system as desired).
All messages are in the format: <Source Address><Target Address><Type of Message><Some Data (Type of Message Dependent)>
For example the Initialisation (adopt) message from controller to tags would be: [From:Controller][To:All Tags][Type:Adopt][Data:Next Available Tag ID]
As all messages follow the same format, it is just the value of the fields that change. Messages can be one to one instead of broadcast (as with the comms between two tags in a pair). The Data component is dependent on the type of message, for example with the “Adopt” message, the data is the address that the tag may take. In the “Synchronise” message, the Data component represents the state of the system (disarmed, pair up, trio up, armed).
At this point, there is no distinction between the tags 10; they are all just tags assigned to the controller 20. The tags 10A, 10B, 10C can all be in range when the controller is powered up or brought into range one at a time. The internal system numbering of the tags is unimportant to the user, but the controller 20 has enumerated them sequentially, for example the first uninitialised tag 10A would have been enumerated as number 1, the second 10B as number 2 and the third 10C as number 3. This allows for the system to have been configured previously but then set back into “Adopt tags” mode and further tags added if needed.
The key switch 203 on the controller 20 is turned to the “Disarmed state” position and the controller sends out periodic broadcast messages to all tags 10A, 10B, 10C. These broadcast messages are sent out both in the Disarmed mode and the Armed mode and are used to convey system state information (Disarmed, Pair Up, Trio Up, Armed) to all the tags. In the disarmed mode, this just serves to confirm to the tags that they are all disarmed.
It is in this mode that tags are placed on the articles to be secured with a minimum of at least two tags within close proximity of each other. Each of the tags 10A, 10B, 10C is secured to the corresponding article 30A, 30B, 30C in a suitable manner. This may be by way of adhesive or some other permanent fixing or lockable fixing method. There can obviously be many more than two tags together, the pairing/trioing algorithm discussed in the next section separates them all into pairs.
The key switch 203 on the controller 20 is turned to the “Armed state” position. However there are two states that must be traversed automatically in order for the system to reach the Armed State. The first is the Pair Up phase and the second is the Trio Up phase.
The controller 20, in turn sends a message to each tag 10A, 10B, 10C, starting with tag 10A (tag 1) and requests that it broadcast a message on its lowest power, inviting any listening tag that has not already become associated to become its paired tag. The controller 20 waits a short period of time for a response from tage number 1 (the tag 10A). If none is received, then it moves on to the next tag in its list, tag 10B (number 2) and so on. If a suitable unpaired tag, for example tag 10C (number 3), responds to the signal from tag 10A, then the tag 10A confirms the pairing to the tag 10C and reports its own ID and the ID of the tag 10C back to the controller 20, which responds with a Group ID for the pair of tags 1A, 10C. The tag 10A at this point effectively becomes a detector tag (as will be described further below). The controller stores this information and knows that tag 1 and tag 3 are paired and also stores information to ensure that neither of these tags are to be contacted again by the controller during the pairing process. For example, tag 10B (number 2) might be contacted next by the controller and, effectively, be invited to become a detector tag, but tag 10C (number 3) would not as it has already been recorded as being a paired tag in the tag 10A/10B pair.
Once the controller has contacted all tags in it's adopted group, whether they have responded and been paired or not, it enters the Trio Up phase.
In order to reduce transmission collisions, each tag 10 uses its adopted tag ID as a period to delay before responding to a potential detector tag. In this way, if tag 10A (number 1) was advertising for a tag to pair with and it was within range of tags 10B (number 2) and 10C (number 3), then it would most likely pair with tag 10B (number 2) which would have responded after, say 2 milliseconds, whereas tag 10C (number 3) would have responded after 3 milliseconds. The same anti-collision algorithm is used in the Trio Up tag negotiations.
The Trio Up state does not actually produce groups of three tags as all groups in the example system are pairs. However, in the case that there are an odd number of tags in proximity to each other, a tag (in this case tag 10B) that has not been reported to the controller 20 as part of a pair in the Pair Up phase will be sent a message by the controller 20 inviting it to broadcast a low power message and any non-detector tag (in this case 10C) that was previously paired up with a detector tag (in this case 10A) will respond with a message and also become a tag to the previously unpaired detector tag 10B, effectively becoming the non-detector tag in two pairs, 10A/10C, 10B/10C.
The operation of this mode is identical to the Pair Up mode i.e. the controller 20 broadcasts to previously unpaired tags in turn, tags broadcast on low power, if a response is received, they confirm the pairing and then report theirs and their paired tag's ID back to the controller which confirms the grouping with a Group ID. In the case that no suitable tag is found, then the tag is simply not part of any group and is unable to participate in the monitoring process. This is considered a user error and may be reported either by a specific alarm state or signal or by a specific sequence of LED flashing, for example, and can only be rectified by disarming, physically relocating the tags and arming again.
Once all tags 10 are paired into detector-tag/non-detector-tag groups, the system enters the armed state. During this state, the controller 20 sends out a synchronisation message every 2 seconds. This is listened out for by all detector tags and non-detector tags and the message contains details of the state of the system (Disarmed, Armed, etc.), for example if the user has turned the system back to disarmed mode, a signal provides for all tags to re-enter that mode. It also serves as a baseline in time for the tags. Each tag pair was assigned a Group ID by the controller 20 when the detector tag of the group (pair) reported its pairing to the controller. These are sequentially numbered and identify a window of time whereby the respective detector tag measures the range to its paired tag and reports back with that range to the controller 20. The controller knows how many pairs it can sustain and equally divides the window between synchronisation pulses (which is approximately 2 seconds) into “max pairs” number of slots. Each pair was given a group ID when it reported it's pairing during Pair/Trio Up which corresponds to the window in which it can transmit.
If no report is received, it is assumed that the detector tag has been tampered with and a continuous alarm is sounded on the controller alarm 206. The alarm is serviced at every Synchronisation message sent out in Armed mode (i.e. every 2 seconds). The reports of the pairs are examined and any pairs that reported movement set an alarm flag. The Alarm buzzer is then activated until the user changes the system state to Disarmed mode using the keyswitch.
Within each group's window, the detector tag (10A in the first case of the present example) broadcasts a ping message simply a message from one tag to the other requesting a response (Pong) on its lowest power to its associated non-detector tag 10B, which responds with a pong if it can hear it. Should the non-detector tag 10B have been moved further away and out of (low power) range of the detector tag (which would typically be about 1 metre) at the lowest power level, then the detector tag would fail to hear a response message (Pong) from the non-detector tag 10B within the first third of their pair's time window and would increase it's power and re-transmit the Ping message. If the non-detector tag 10B can now hear on the higher power level, it increases its power and sends a response back. The detector tag 10A then reports back to the controller that some movement has taken place (either of the tags or in the ambient conditions affecting the tags, eg a tag being wrapped in metal foil) and the controller indicates this audibly by blipping the sounder alarm 206, but not sounding it continuously. At this point, this “amber” alert is reversible by moving the detector tag 10A and non-detector tag 10C back within low power range on the pair's next reporting window. If a pong is not received by the detector tag 10A in this higher power, second third, of the pair's reporting window, then the non-detector, paired, tag 10C has either been tampered with or moved so far out of range as to trigger the alarm. The detector tag 10A reports the alarm condition back to the controller using the reporting message in the final third of its reporting window.
The controller 20 then raises a continuous audible alarm which can be reset only by turning the system back to its disarmed state.
After the first group's (pair's) 10A, 10C, window, the next group's (pair's) 10B, 10C window is entered and that pair performs the same scan as described immediately above.
The idea behind the windows is to reduce transmission collisions and also to allow the tags in particular groups to “sleep” in a very low power consumption mode until either their reporting window, or the synchronisation pulse is reached.
If the key switch 203 is now turned to another state, this will be broadcast in the next synchronisation message and all tags will enter that state.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0610558.9 | May 2006 | GB | national |
