READER OR COUPLING DEVICE?
In the world of contactless and smartcards, the word ‘reader’ is often used for the electronical device communicating with the card.
But this doesn’t necessarily indicate what the role of the device is, i.e. how it runs. Let’s make things a bit clearer...
READING, BUT NOT ONLY...
First, you have to keep in mind that a smartcard, either contact or contactless, is not read the same way as a USB file or a floppy disk.
A card responds to certain preregistered commands according to NFC and RFID standards. Often, an authentication process exists which can be encrypted for security purposes.
Some commands are simply reading data, but other commands include writing data, crediting a bank account, checking the validity of a subscription... The choice of commands - which determines the type of transaction to be completed – doesn’t concern the ‘reader’ but the application running it.
COUPLING DEVICE VS SMART READER
The application running the ‘reader’ works on a host system (generally a computer) and understands the ‘reader’ as a technical bridge, enabling it to send commands to the card and receive responses.
This concept of a technical bridge lent the device its name of ‘coupling device’, an expression accepted by ISO standards as proof of it being more than a simple ‘reader’.
COUPLING DEVICE FUNCTION DIAGRAM
The application's logic is provided by such host systems: this allows more possibilities of upgrading.
Cost is therefore related to application development.
'SMART READER' FUNCTION DIAGRAM
The application’s logic is hosted in the ‘smart reader’: this provides faster implementation of commands but upgradibility is limited.
There are many cases where this architecture {coupling device + host system} is not relevant.
This is the case when a host system is not fast enough or doesn’t have enough memory to complete solo transactions with cards.
Another example of when it isn’t relevant is when a card carries more than just a number or short ID: for cost and system upgradibility, the card ‘reader’ needs to be interchangeable with barcodes and magnetic track readers.
FOCUS ON SPRINGCARD DEVICES
Springcard’s ‘smart readers’ are identified by the /RDR suffix added to their name. Those emulating a USB keybord are called RFID Scanners.
Coupling devices are compliant with the “PC/SC” standard. All of our devices that have “PC/SC” in their name are coupling devices.
However, the K663 module and the CSB4 among others, are also coupling devices, but they run according to SpringCard’s proprietary protocol.
You’ll notice many of our coupling devices and ‘smart readers’ share electronic parts. It enables you to shift the running mode simply while upgrading the firmware!
A LITTLE STORY
The Town Center car park has two types of clients: occasional users and regulars. In the past the occasional clients entering the car park used tickets with a magnetic strip and the regulars were using magnetic badges. Both tickets and badges were read by the same readers. But the system proved to be expensive to use: the badges kept being “demagnetized”, the readers got dirty regularly, and the moving parts needed a lot of maintenance.
So it was decided to replace the magnetic badges with contactless badges and to put a 'reader' at each crossing point.
But what to choose: coupler or smart reader? That is the question!
Matthieu, the head technician of the car park, analysed the existing infrastructure:
- no IT was used at the entrance or exit barriers
- the magnetic readers were linked by long cables to a computer situated in the guard hut
- the software used for the car park management was satisfactory for a number of years: why bother changing?
He choosed to integrate smart readers into the existing equipments. Once set, the 'readers' were able to check the authenticity of the cards and to make a link with the ID number of the regular user. A small change had been made in logistics management, and the new 'readers' worked with the ancient system of magnetic readers.
Matthieu was totally satisfied with this solution: for a reasonable investment cost, he had improved the comfort of the regulars and decreased the maintenance required to keep the magnetic readers operating.
But the story doesn't stop there...
Some months later, the Town Center car park signed a partnership with the company providing public transportation. All the company’s clients would be provided with free parking, under the condition that their tram tickets were validated within the two hours prior to exiting the car park.
Matthieu asked the company if they had a server with API (an interface that allows to use an application for data exchange) that would help the car park management to know if the tickets were eligible for the free scheme. However, The company didn't use such a server and the data was only available on the cards.
A new parameter was then added: the Town Center car park's readers would not only have to 'read' the cards but also identify the type of card -regular parking users, regular transport users or occasional transport users. And for the transport cards, it would no longer be a simple question of finding a user number, but also browsing the entire data history in order to find the time stamp of the user’s tram journey.
To complicate the problem further, the scheme would include the possibility for the 'readers' to write on the card the time and date corresponding to the user’s entrance or exit out of the car park. This would be to ensure that a same card could not be used to abuse the free system by multiple vehicles.
Matthieu this time has to opt for couplers. And he had to change the car park's software to implement this complex logging system. But he succeedeed and was satisfied once again. Not only did he bring in a new service, but he gained full control of the cards’ transactions. And in addition, the system could be changed hawe'ver he wanted.
As for now, Matthieu is thinking of new changes as scrapping the magnetic badges entirely and upgrading the regular users to NFC smartphone technology...