In a previous blog, I reviewed the different card types that you might want to consider for your transport ticketing solution. The purpose of that piece was to confront some preconceptions regarding the performance of CMD2 cards and to educate on how some cards might not be best suited for certain ticket types; especially commercial tickets and in particular those used in the retail industry.
In this piece, I want to add to that discussion on CMD2 cards but highlighting something I’ve noted in the past year – it’s still really difficult to differentiate between the CMD2 cards on offer! There are some really important differences between them but you seem to need considerable ITSO knowledge to understand what the detailed specifications or test reports (if you can get them) actually mean. Several of these are key features you should be looking for when selecting your card – and not just the price.
If you are the individual working for a PTE or operator that has given the responsibility for selecting the smart card to be used for a commercial bus or rail scheme, then please read on.
Size
Size is not everything in the CMD2 world, but bigger certainly does help for commercial tickets. With native solutions it is still true that you generally get more memory per penny, but I will reiterate here that having a partner that can help you configure the available space in the most appropriate manner is just as important. Read my previous blog on ‘Top 5 UK smart card myths dispelled’ for further detail on size.
Speed
Unfortunately there are no consistent, historical benchmarks readily available for comparison – be they laboratory based or under real world ticketing conditions. For example, even during certification, a raw figure from the certifying body cannot be compared as it is not always clear for any (especially historical) report:
- What version of test hardware was used
- What version of test software was used
- What communications speed between terminal (POST) and card has been used
- What ISAM version has been used
- What communication speed between the ISAM and the terminal have been used
- And so on…
This is compounded by another two points
Secure Messaging
Looking at an ITSO certificate for a product does not reveal if that card supports Secure Messaging or not. Why is this important? If loading something of value – especially if that value is significant e.g. a weekly, monthly or annual season ticket – you want to ensure that the ticket being sent has not been tampered with and its integrity has been verified. As a commuter, you want to ensure you have got what you paid for. As an operator you want to ensure that no one has interfered with the value of the ticket you have sold – especially during a fulfilment process.
This is especially true in the case where you, as an operator, want to provide remote ticket download solutions via the internet and mobile phones.
Not using Secure Messaging is one way card suppliers can boost their performance figures – but in truth the performance hit with Secure Messaging is more to do with the communication with the ISAM rather than the card. This is simply due to the increased number of commands sent to the ISAM by the POST (terminal) in a transaction with Secure Messaging. If that ISAM communication speed is ‘cranked up’ to its maximum available, then the performance ‘penalty’ of using ‘Secure Messaging’should be entirely invisable to the end user. As an example, the card only transaction time of a Rambus Ecebs Pearl or Diamond card is under 50 milliseconds for a ‘typical’ transaction using Secure Messaging.
Anti-tear
This point is simpler to identify and there are two types:
- Software
- Hardware
Software anti-tear for CMD2 is well defined and understood across the ITSO world. The technologists among you are probably thinking that hardware ant-tear would be an obvious way to improve performance (less execution time for the back-up) – and, in an ideal world, I would agree. However, hardware anti-tear is less clearly defined and implementations are few and varied. Thus interoperability suffers if an implementation using hardware anti-tear is adopted. The good news is that with the performance available in today’s smart cards (especially native offerings), hardware anti-tear is not required – even with Secure Messaging as defined above.
In summary:
- Think about the tickets you want to load
- Make sure you have both the raw space and configeration to handle those tickets
- Provide your customers with the best possible security protection by using Secure Messaging
- Maximise interoperability with Software Anti-tear
