摘 要： 介紹了智能卡COS現狀及存在的問題，針對底層通用問題，借鑒Java智能卡的優點實現與底層無關的COS，即針對不同的硬件平臺，無需重新編寫代碼。根據參數的不同提出了幾種不同的解決方案。
關鍵詞： 智能卡；移植；硬件
智能卡在計算機技術、網絡技術、數據庫處理技術、高頻技術、數據保護和密碼學等的應用日趨廣泛，因此智能卡的數量也在直線上升，因此在各個卡之間應用的移植問題引起了人們的關注。
智能卡操作系統COS（Chip Operating System）是針對某一種特定芯片開發的，該操作系統通常由芯片生產商開發，因為只有他們才真正了解芯片底層的技術細節。每個廠家芯片COS開發的環境都不一樣，在COS支持的上層應用不變的情況下，當更換不同的硬件時，需要了解新硬件COS的開發環境、新硬件底層的技術細節，重新將上層邏輯應用移植到新的硬件上時，移植的工作量非常大，不低于重新編寫一次COS，而且移植過后COS的穩定性也需要重新測試，這樣極大制約了智能卡應用的快速發展。另外，智能卡COS目前使用的開放式系統研發環境，存在較高的版權費用，軟件成本偏高；而使用自然語言開發的COS，目前大多使用層次結構，效率較低，編寫的代碼量較大，降低了硬件的效率并增加了存儲成本。針對以上問題本文提出了解決不同硬件之間操作系統移植的解決方案。通過對COS結構底層模塊的研究，結合Java卡的硬件無關的優點，設計出與底層無關的COS。
1 COS結構模型
智能卡的設計一般分為三層結構：硬件抽象層、核心層和應用層。其中硬件抽象層設計與智能卡芯片物理結構相關的功能，使其對上層透明；核心層包含了智能卡的主要結構和功能：卡啟動程序及初始化、內外部認證、命令解析、安全問題及文件系統等核心功能；應用層主要提供基于硬件抽象層和核心層的不同應用。隨著技術的發展，應用層將提供更多的有利且方便用戶的應用[1]。智能卡結構如圖1所示。
2 Java智能卡
Java卡是在智能卡硬件系統基礎上通過軟件構造的一個支持Java程序下載/安裝并運行的軟/硬件系統。通過引入Java虛擬機技術，Java智能卡在保留了原有智能卡應用的便捷、安全等特性的同時，繼承了Java技術的硬件無關特性，將智能卡應用程序的開發同智能卡硬件系統相分離，簡化了應用程序的開發，提高了應用程序的可重用性。Java智能卡包括：智能卡硬件系統、與智能卡硬件系統相關的本地方法集、Java智能卡虛擬機JCVM、Java智能卡類庫、Java智能卡應用管理組件、Java智能卡運行環境JCRE以及Java智能卡應用[2]。其系統結構如圖2所示。
智能卡COS與Java卡的區別：
從圖1、圖2可以看出，智能卡模塊之間的調用是直接利用下層的函數與各模塊的相互作用來實現應用程序，而Java卡是通過一個虛擬機來實現。此虛擬機即是Java卡與硬件無關特性的關鍵模塊，卡內的虛擬機負責依據不同的智能卡硬件和操作系統特性來執行安裝到卡上的CAP文件中的字節碼。
3 智能卡的設計及其可行性分析
根據Java卡的特性，提供本地方法集將與硬件相關的問題包含在一個模塊內，同時提供Java智能卡類庫，為應用程序調用下層函數提供統一接口。同時Java智能卡類庫還包含了所有可能用到的類庫及應用擴展類庫，以方便用戶安裝盡可能多的應用。
將此思想應用到C編寫的智能卡，可以將所有智能卡底層的硬件驅動全部包含進來，使得硬件驅動模塊成為硬件驅動集模塊，同時又保持API接口不變，這樣上層應用設計時就不需改變調用接口，還是以同一接口調用，即可完成應用的移植問題。
硬件驅動集，使上層都使用統一接口。考慮到所有函數調用都使用相同意義的參數，根本無法區別驅動集中的任一相應函數。因此，不可能將所有驅動的參數都放到接口的參數列表中來調用對應的底層函數。因為這樣從參數的個數來區別驅動集的函數不可行。為此本智能卡的設計采用了如下方法：
（1）借鑒網絡編程時，通過參數來指定協議確定通信，因此可以增加一個參數來指定智能卡的類型來確定需要調用的函數。例如對于readflash函數：void fs_read_Flash（unsigned char*XRamAddr，unsigned long sAddr， unsigned int Length）通過增加參數char TYPE來確定類型。此時函數變為：
void fs_read_Flash（char TYPE，unsigned char*XRamAddr， unsigned long sAddr， unsigned int Length）
然后通過swith…case即可以區分各個驅動函數從而實現驅動集的分類。而對于各個具體的驅動函數則通過它們的硬件名來命名其函數名以區分各個驅動函數。這樣就不會混合各個驅動函數。改進的微內核層結構如圖3所示。
此方法應用到Java卡的類庫的特點是并非所有的庫函數都會用到，但對于所有的可能情況都考慮到了，因為智能卡的種類是有限的，因此通過swith語句來區分各個卡的驅動函數，此方法是可行的。
但此方法存在一個問題是：對于上層調用硬件驅動時需指明硬件類型，因此當硬件改動時，應用層的移植需要修改所有硬件類型。雖然可利用工具查找并替換來完成，但這也是此方法的一個缺點。
此外，也可以將驅動層與硬件綁定，每個功能相同的驅動采用同一函數名，同時驅動層的各驅動的參數相同，因此在上層調用接口不變的情況下就可以調用不同硬件的相應驅動，無需改變任何函數及參數。
（2）借鑒Java卡的特點，可以將硬件與本地方法即硬件驅動綁定在一起，而上層接口保持不變。若各個與硬件綁定的驅動函數參數不一致，可以在函數內部進行調整使得對上層接口保持一致性。
?。?）最簡單的方法就是將所有的智能卡硬件設定一個規范，所有的智能卡都遵循此規范，這樣某一智能卡的COS在所有智能卡中都可以使用，某一智能卡上的應用在其他智能卡上也可以同時使用，這樣就實現了智能卡的移植問題。即制造統一的智能卡芯片，所有的智能卡的硬件驅動層相同，此時上層調用的接口也相同，所有的應用都是在相同的底層基礎上開發的，相互之間的移植也是完全適用的。
在智能卡的迅速發展中，對于此移植問題的解決，可以保證上層應用開發的一致性，使得更多的應用可以在卡間相互應用，使智能卡的整體性能得到提升，應用也更加廣泛。
參考文獻
[1] 李春風.歐陽小星RF_SIM卡的多應用COS研究與設計[J].計算機工程與應用，2011（2）：57-59.
[2] 張大偉.靳偉Java智能卡原理與應用開發[M].北京：電子工業出版社，2007.