What is an Advanced Card Format and Why Do I Want It

Definitions

Card Type describes the number of bits available inside a card and the placement of the data and parity bits relative to each other.  One speaks, for instance, of 26 bit or 37 bit cards. 

Facility Code is a value associated with a list (or sequence) of card numbers. 

Clarification: Every card is programmed with an internal card number.  This is the number that is assigned in the access control software to a cardholder.  The internal card numbers for 26-bit card types range 0 to 65,535. 26-bit card types also contain a facility code.  Facility codes can range from 0 to 255 in 26-bit card types.  So the full definition of a card is its facility code + its internal card number.  The facility code is important because it serves to differentiate two cards that are encoded with the same internal card number so long as their facility codes are different.  

Card Format is an indication that is sent to a Controllers on how the bits inside the related cards are to be interpreted (i.e. what bits are data bits, what bits are parity bits, what data bits specify the card #, and what data bits specify the Facility Code).  Example Card Formats: "Standard 26-bit, with facility code" or "37 bit with Facility Code (HID 10304)"

Illustration of the Problem

Say that a certain Card Type provides for the cards to have 1) enough bits to create 50,000 distinct card numbers, and 2) additional bits to specify 200 Facility Codes.  Then there can be 50,000 x 200 = 10 million distinctly recognizable cards of this Card Type.   That would be:

Card numbers 1-50,000 with Facility Code =1

Card numbers 1-50,000 with Facility Code =2

Card numbers 1-50,000 with Facility Code =3

etc…

However, some controllers do not differentiate card #s on the basis of their assigned Facility Code – and this is the case with the Mercury hardware.   Then, card # 12345 with Facility Code 3 and card # 12345 with Facility Code 10 are read as the same card #: 12345.  So cards that are really different are seen as duplicates.  This weakness not only leads to the controllers perceiving duplicate card numbers , but also constrains the possible number of distinct cards to 50,000 in this example (instead of 10 Million). 

This issue does not affect properties where it is unlikely that multiple Facility Codes of the same Card Type will exist, or where there is no need for more cards than can be associated with a particular Facility Code.   But the issue can be significant in environment such as multi-tenant office buildings or multi-building portfolios where several tenant companies are likely to be using popular Card Types such as the 26-bit or 37-bit Types.   There, a process that ignores the Facility Code is extremely likely to cause a duplicate card number issue.    

The Advanced Card Number Strategy - How it Works

This strategy largely solves the problem by reducing the risk of duplicate card issues by several orders of magnitude:

When a new batch of card numbers is submitted for upload to BluSKY, it appears as a list of card #s along with their associated Facility Code.  This is the unadulterated information that is provided by the manufacturer and used in the upload.

BluSKY stores this data in separate fields within its cards table: for each card submission, one field holds the internal card number, and the other field holds the facility code.  (There is another field to hold the externally imprinted card number (the one that is printed on the card) - but that is not significant to this discussion.

But BluSKY also automatically generates a third field in its card table: it is called the “advanced card number” field.  The field contains the concatenation of the facility code and the internal card number.

BluSKY also creates an Advanced Card Format for the subject cards that specifies NO facility code checking.… meaning that the Facility Code bits inside the card and the Card Number bits are to be interpreted as a single binary card number, i.e. the Advanced Card Number.

This Advanced Card Format is then sent to the controller.  The result is that two cards with originally the same internal card number but a different Facility Code will surely be recognized as different cards because their advanced card numbers are different.   

Illustrative Example

This is easy to illustrate using a simplified example:

1.  Let there be a Card Format called “8-bit with Facility Code” that states that the first 4 data bits in a card represent the Facility Code, and the last four bits represent the “Internal Card Number”:
   • Suppose that the data bits inside one of those cards were 0011 0001:  The controller, following the “8-bit with Facility Code” rules would identify the card as belonging to Facility Code =3 (0011 binary), and Internal Card Number = 1 (0001 binary)
   • Suppose now that the data bits inside another card were 0111 0001:  The controller, following the Card Format rules would read the card as belonging to Facility Code =7 (0111 binary), and Internal Card Number = 1 (0001 binary)
   • The two cards have Card Number = 1 but they are differentiated because their Facility Code is different.
2. Suppose now that the controller is unable to take Facility Codes into account:
   • Then, both cards would be read as Card Number 0001 = 1 and they would be perceived as duplicates.
3. Suppose now that the “8-bit with Facility Code” Card Format is replaced with an “8-bit without Facility Code” format, and the format specifies that cards shall be read as Advanced Card Numbers
   • Then the examination of the first card by the Controller would yield (Advanced) card # 0011 0001 = 49, and
   • The examination of the 2^nd card would yield (Advanced) card # 0111 0001 = 81.
   • And the two cards are perceived as two entirely different card numbers.

Important Notes

The use of the Advanced Card Number strategy is totally transparent to the Reseller and to the end-customer.  The familiar process of adding, editing, and deleting cards in BluSKY is unchanged.  BluSKY handles the process of constructing the Advanced Card Numbers and the associated Card Format(s) and sending them to the controllers in the background, out of sight of the system users.

Controllers are often limited to a relatively small number of stored Card Formats – sixteen (16) in the Mercury Hardware.  Even if a controller can differentiate different card formats, a distinct format definition is needed for each Facility Code in a Card Type.   So, in our example, the total number of allowable cards of the 8-bit Card Type would be 50,000 x 16 = 800,000,  but the Advanced Card Number strategy allows Ten Million distinct cards of that type.