1、引言
　　
　　在儀器儀表迅速發展的同時，計算機和網絡技術也在迅速發展，PC機已經從高速增長進入到平穩發展時期，嵌入式系統的出現和廣泛應用，使計算機和網絡進入了后PC時代，基于嵌入式智能儀表遠程監控系統作為工業控制網絡重要發展方向之一。而嵌入式控制器是能夠實現智能儀表遠程監控的關鍵設備，是工業控制儀表與Internet連接的橋梁。
　　
　　2、控制器總體介紹
　　
　　嵌入式智能儀表的結構及其與Internet的連接方案設計如圖1。
　　
　　圖1基于嵌入式智能儀表的遠程監控系統　　嵌入式控制器是用于執行獨立功能并具有以復雜方式處理數據能力的控制系統，它內置在工業儀表上，由三部分組成:高速處理器、嵌入式Web服務器和工業儀表接口。嵌入式控制器以高速處理器為核心，由高速處理器和其他芯片協同工作來控制電子設備或裝置，能夠完成監視、控制等各種自動化處理任務。嵌入式控制器是一種很好的基本接入設備，它通過工業儀表接口與儀表相連。嵌入式控制器在TCP/IP數據傳輸的基礎上，將Web功能融入整個裝置。客戶只要擁有瀏覽器，即可方便的與控制器進行通信，對現場智能儀表進行過程參數的查看與設定，控制對象的關閉與開啟。
　　
　　基于嵌入式儀表的遠程監控系統的核心是嵌入式控制器，嵌入式控制器是一個典型的嵌入式系統，嵌入式控制器的系統設計遵從嵌入式系統設計的相關理論。系統設計需要考慮把軟件和硬件的結構作為一個統一協調的整體。嵌入式系統趨向于采用高平臺（Platform）和采用面向對象的UML-RT來進行系統的分析和設計。因此，我們在設計嵌入式控制器時，采用UML-RT和平臺（Platform），使嵌入式控制器有一個彈性的架構，能夠方便快速的改變或擴充功能，滿足系統要求。
　　
　　3、嵌入式控制器的需求分析
　　
　　我們利用UML的用例圖（usecase）來對嵌入式控制器進行需求分析。用例圖從用戶的觀點描述了系統硬件和軟件的功能。按照前面我們對嵌入式控制器的功能描述，我們得出系統的用例圖，如圖2所示。其中包括七個不同的用例和兩個不同的角色。　　用戶角色可進行查看數據，設定數據，開啟和關閉控制對象（智能儀表），控制對象可以接收和發送數據，相應開啟和關閉的操作指令。數據處理中心負責數據的封裝，發送，計算等數據處理工作。
　　
　　4、平臺（platform）的劃分和設計
　　
　　在完成了系統的需求分析之后，開始劃分本平臺的系統結構，所謂本平臺的系統結構就是指平臺系統對各級之間界面的定義及其上、下層的功能分配，而且每一層又有它自己的系統結構。主要按照功能、邏輯順序來劃分多級層次結構。在劃分系統結構的時候，主要需要綜合平衡下面的一些問題:
　　
　　1、本質上，它是從平臺用戶在使用本平臺進行開發時，所看到的本平臺的屬性，包括概念性結構，一些接口和功能特性。從概念和功能上把它看作是有多級構成的層次結構，有利于對嵌入式控制器及開發平臺本身的正確理解。要研究哪些應當透明，哪些不應當透明。透明的好處是可以不用管它，簡化了該級的設計。
　　
　　2、一般來說，很多功能既可以放在上層，也可以放在下層，而且它們在邏輯功能上是等效的。選擇什么樣的上下層分配比例，主要取決于易用性，復雜度及現有的硬件狀況等。
　　
　　3、系統結構的設計與實現，究竟應該從哪一層開始，也是一個重要的問題。比如對于一個三層的結構，可以有從上到下、從下到上、由中間開始等多種選擇。從上述幾點考慮，嵌入式控制器平臺的系統結構如圖3所示。
　　
　　我們把嵌入式控制器系統分為3個抽象層次:體系結構平臺（ARCplatform），應用程序編程接口平臺（APIplatform），定制的應用程序平臺（ASP）。ARC平臺包含了微處理器存儲系統，接口電路，I/O通道及芯片之間的內部連接。微處理器系統由S3C2410微處理器、FLASH,SDRAM,CS8900A網絡控制芯片等一族“微架構”組成。API平臺包括RTOS實時操作系統，嵌入式Web服務器，設備驅動程序等。API平臺是軟件抽象層，把ARC平臺的實現細節進行封裝。API平臺提供接口服務，并對這些接口按類別進行分組。比如用戶需要知道RTOS是否提供占先式任務調度接口，嵌入式Web服務器提供的HTTP,TCP/IP接口。ASP平臺提供用戶的直接操作界面和專門的應用服務，如讓用戶通過瀏覽器查看和設定智能儀表的控制參數。　　在每個平臺都有相應的服務質量（QoS）的要求。在ARC平臺對功耗、存儲量、處理速度、通訊能力等都有要求。S3C2410,CS8900A等芯片可以很好的滿足這些要求。在API平臺對運行任務的個數，任務切換時間等也有要求，嵌入式Web服務器和嵌入式Linux能滿足這些要求。在ASP平臺要求進行實時的參數查看和參數設定。采用JavaApplet能很好的做到這些。
　　
　　對嵌入式控制器系統進行平臺的劃分，并且對各個平臺提出相應的服務質量參使我們在設計的初始階段對整個設計有全局的觀念，由于各個平臺之間相對獨對以后出現的新的設計要求和設計修改具有很好的適應能力。
　　
　　5、基于UML-RT的嵌入式控制器設計
　　
　　在對嵌入式控制器劃分平臺后，我們可以用UML-RT的符號體系對嵌入式控制器系統進行建模。我們把建模的過程分為兩個階段。*階段是考慮系統的對外接口。第二階段是考慮系統內部的平臺建模。
　　
　　在*階段，嵌入式控制器的建模見圖4。根據前面用例圖的需求分析，得出系統需要與環境交互的端口有兩個:一個是與控制對象即智能儀表進行通訊。一個是和用戶進行交互。為了支持和用戶交互以及控制對象通訊，我們定義了兩個容器（capsule）u:UserInteRFace和t:TransferData。容器p:ProcessData則是用來處理數據。容器可以包含相關的軟件和硬件結構，數據傳送可通過并口和串口進行，這種傳送和處理器藕合的很緊，我們用UML-RT的擴展符號表示。同樣，《SWp1》表示在處理器P1上執行的處理與控制對象通訊的程序。我們用這種方式還可以對u:UserInterface和p:ProcessData進行細化。　　在*階段的基礎之上，我們結合前面對平臺的劃分，進行平臺建模。系統的ARC平臺的建模如圖5所示。　　圖5表示了ARC平臺的基本組件和它們的拓撲圖結構，利用這個圖可以進一步的進行對象建模。這個模型提供了一個框架，并可以方便的增加，移動，替代，修改框架內的元素。UML-RT的端口可以有效的表示模型元素之間的接口。
　　
　　API平臺處于ARC平臺和ASP平臺之間，包括RTOS嵌入式Web服務器，設備驅動程序等。從UML-RT角度看，API平臺是ARC容器與ASP容器之間的通訊管道。在這里ARC容器和ASP容器直接通過連接器相連。
　　
　　ARCProxy從ASP容器的端口中接收調用信息，然后把這個信息通過RTOSAPI送到合適的設備驅動程序，讓設備驅動程序去和ARC平臺通訊。異步或同步的通訊可以通過這個方式進行。驅動程序和RTOS是緊密相關的。ASP平臺的建模同樣可以通過類似的方式表現。
　　
　　綜上所述，結合UML-RT和Platform進行嵌入式控制器的設計，我們看到它們能夠很好的對嵌入式軟硬件進行抽象，提供良好的文檔資料。基于UML-RT和Platform設計的系統架構，對設計過程出現的新的設計要求和設計修改具有很好的適應能力，設計者可以及早的發現并更正錯誤。