熱門論文
最新論文
智能藥房信息管理與控制 系統的設計與研究
發布時間：2023-07-19 10:30
第一章緒論 1
1.1課題來源、研究背景及意義 1
1.2國內外智能藥房研究和應用現狀 1
1.2.1國外智能藥房研究、應用現狀 1
1.2.2國內智能藥房研究、應用現狀 6
1.3課題的研究內容 8
1.4論文的章節安排 9
第二章智能藥房信息管理與控制軟件系統需求分析 10
2.1數據流圖概述 10
2.2數據流分析 11
2.3用戶需求分析 13
2.4功能需求分析 13
2.5數據庫的概念模型建模 15
2.5.1數據庫的概念模型概述 15
2.5.2數據庫 E-R 建模 16
2.6本章小結 19
第三章智能藥房系統總體設計 20
3.1智能藥房的機械結構簡介 20
3.2智能藥房系統上位機和下位機的總體設計 21
3.3上位機信息管理與控制系統設計 22
3.3.1上位機信息管理與控制系統各電腦的功能 22
3.3.2上位機信息管理與控制系統的功能模塊 29
3.3.3上位機信息管理與控制系統流程設計 31
3.4下位機系統介紹 3 3
3.5本章小結 34
第四章系統的設計與實現 35
4.1通信模塊 35
4.1.1TCP/IP 網絡協議 35
4.1.2上位機主控電腦與各電腦之間的通信數據格式 39
4.1.3串口通信協議 40
4.2數據庫的設計與實現 43
4.2.1 關系數據庫選擇 48
4.2.2 數據庫字典建立 44
4.3上位機控制模塊的設計與實現 48
4.3.1 模擬 HIS 系統 48
4.3.2 主控模塊 53
4.3.3人工發藥模塊 67
4.3.4 補藥模塊 69
4.4 補藥控制系統硬件設計 70
4.4.1 補藥控制系統概述 70
4.4.2主控制器模塊 70
4.4.3傳感器模塊 72
4.4.4 A/D 轉換模塊 73
4.4.5 LCD 液晶顯示模塊 74
4.4.6RS485 通訊模塊 75
4.5本章小結 75
第五章系統測試 76
5.1軟件測試概述 76
5.2測試環境搭建 77
5.2.1數據庫配置 77
5.2.2模擬環境搭建 78
5.3測試流程 80
5.4 測試結果分析 87
5.5本章小結 89
第六章總結與展望 90
6.1工作總結 90
6.2工作展望 90
參考文獻 92
攻讀碩士學位期間的學術活動及成果情況 95
插圖清單
圖 1.1 德國 ROWA 公司的 Topspeed 智能藥房 2
圖 1.2 德國 ROWA 公司的智能藥房 3
圖 1.3 瑞士 swisslog 公司的智能藥房圖 3
圖 1.4 法國 APOTEKA 公司的智能藥房 4
圖 1.5 荷蘭 RoboPharm 公司儲藥槽式智能藥房 5
圖 1.6 德國 Hanel 回轉式的智能藥房 6
圖 1.7 垂直旋轉式智能藥房 6
圖 1.8 快速出藥系統外觀 8
圖 1.9 快速出藥系統內部 8
圖2. 1 系統頂層數據流圖 11
圖 2. 2 系統 0 層數據流圖 12
圖2. 3主控信息處理1層圖 12
圖 2.4 系統工作過程 15
圖 2.5 數據抽象過程及信息數據的形成 15
圖2.6藥品有關實體 E-R 圖 17
圖2.7處方相關實體 E-R 圖 18
圖2.8 軟件管理與控制系統相關實體 E-R 圖 19
圖 3.1 斜坡式存儲結構側視圖 20
圖 3.2 智能藥房系統總體結構圖 22
圖 3.3 上位機信息管理與控制系統組成圖 22
圖3. 4模擬醫院HIS系統功能模塊 23
圖 3.5 接口系統工作流程圖 24
圖 3.6 發藥系統功能模塊 25
圖 3.7 異型包裝發藥系統功能模塊 26
圖3.8發藥工作流程圖 27
圖3.9補藥工作流程圖 28
圖 3.10 補藥窗口系統功能模塊 29
圖 3.11上位機主控系統的功能模塊 31
圖 3.12 主控系統處理處方流程圖 32
圖 3.13 下位機系統示意圖 34
圖 4.1 TCP/IP 的參考模型 35
圖4.2模擬HIS系統主界面 48
圖 4.3 處方管理模塊 49
圖 4.4 處方過往記錄 50
圖 4.5 刪除處方界面 51
圖 4.6 添加處方界面 52
圖 4.7 用戶登錄界面 53
圖 4.8 登錄結果 54
圖 4.9 處方收發模塊主界面 56
圖 4.10 處方處理結果 56
圖 4.11 處方記錄模塊主界面 59
圖 4.12 刪除處方記錄 59
圖 4.13 重新發藥 60
圖 4.14 藥品信息管理界面 61
圖 4.15 用戶信息管理界面 63
圖 4.16 補藥界面設計 64
圖 4.17 補藥信息核對界面 64
圖 4.18 通信參數設置模塊 65
圖 4.19 系統日志模塊 66
圖 4.20 人工發藥模塊主界面 67
圖 4.21 人工取藥 68
圖 4.22 補藥模塊主界面 69
圖 4.23 補藥控制系統功能模塊組成如圖 70
圖 4.24 STM32F103ZET6 單片機 71
圖 4.25 單片機電源電路圖 72
圖 4.26DS18B20 與單片機連接電路圖 73
圖 4.27DS18B20 實物圖 73
圖 4.28 HX711 芯片連接電路圖 74
圖 4.29 TFT-LCD 液晶屏外觀圖圖 4.30 液晶顯示 74
圖 4.31 RS485 通信模塊電路圖 75
圖 5.1 模擬 HIS 系統主界面 78
圖 5.2VSPD 串口模擬 79
圖 5.3 發藥反饋完成 79
圖 5.4 STM32 核心板 80
圖 5.5 處方收發模塊主界面 81
圖 5.6 處方處理結果 81
圖 5.7 處方記錄模塊主界面 82
圖 5.8 添加管理員 83
圖 5.9 刪除用戶 84
圖 5.10 建立通信 85
圖 5.11 人工發藥 86
圖 5.12 發藥操作 86
圖 5.13 補藥操作 87
表格清單
表 2.1 基本圖形元素 10
表 4.1 從模擬 HIS 電腦到主控電腦的通信數據格式 39
表4.2從主控電腦到模擬HIS電腦的數據格式 39
表4.3 從主控電腦到發藥窗口電腦的數據格式 39
表4.4 從發藥窗口電腦到主控電腦的數據格式 40
表4.5 從主控電腦到補藥窗口電腦的數據格式 40
表4.6 從補藥窗口電腦到主控電腦的數據格式 40
表4.7 發藥動作指令格式 41
表4.8 數據段具體格式 41
表4.9 補藥動作指令格式 41
表4.10補藥指令中的數據段格式 41
表4.11 握手動作指令格式 42
表4.12 實時監控查詢指令格式 42
表4.13 信息反饋指令格式 42
表4.14串口參數設置 43
表 4.15 常用的關系數據庫的特點和使用場合 43
表 4.16 用戶信息表 44
表4.17 HIS詳細處方表 44
表4.18品信息表 45
表4. 1 9藥品庫存表 45
表 4.20 藥品生產廠商表 46
表 4.21 藥品詳細清單表 46
表4.22待補充藥品信息表 46
表 4.23 病人掛號表 47
表 5.1 模塊測試 88
表 5.2 測試結果 88
第一章 緒論
1.1課題來源、研究背景及意義
本課題來源于合肥工業大學校企合作項目，題目為智能藥房信息管理與控制 系統的設計與研究，該項目的主要目的是提高醫院藥品的管理效率，同時提高醫 院藥品的發藥與補藥的工作效率，降低由于人工取藥帶來的失誤。隨著技術的發 展，各行各業都在科技的驅動下迎來了一個新的高度，尤其是工業、農業的快速 發展，提高了人民的生活質量。隨著生活水平的提高，人們對自身健康投入更多 的金錢和精力，與之緊密聯系的醫療技術得到了更廣泛的關注［1］。由于信息技術的 發展，醫院藥房大都有自己的HIS（醫院信息管理系統尸］，醫院信息管理系統使用 計算機技術輔助醫院發藥和補藥，解放了勞動力，減少了由于人工參與帶來的失 誤，提高了整個醫院的工作效率［3-6］。現在大多數醫院的發藥模式依舊是人工取藥 模式，醫院工作人員在收到處方后，需要按照儲位信息對藥品進行一一取出，然 后匯總校對無誤后交給患者。這樣無疑是不能降低人工工作強度，還會帶來由于 人工操作帶來的失誤，對患者的健康造成一定的影響，這些問題會影響醫院醫生 的治療水平，同時會危及到醫院的形象和發展［7-8］。智能藥房應運而生，配套的智 能藥房信息管理與控制系統技術的發展不僅能解決這些問題，還能提高藥品信息 存儲的高效性，減少患者等待取藥的時間。
智能藥房技術的革新是醫院藥房新的發展方向，醫院藥房實現自動化發藥是 藥房發展的最終趨勢［9］。通過快速發藥機、智能倉儲系統、智能藥房信息管理與控 制系統等實現了自動化發藥和補藥、密集存儲藥品。這就避免了醫院藥劑師拿著 藥單到處取藥，降低了人工的工作強度，而且降低了發藥流程和補藥流程的工作 時間，這在一定程度上緩解了醫院人滿為患的現象。高度自動化的智能藥房用信 息管理與控制系統控制發藥和補藥操作，然后由下位機執行系統完成補藥和補藥 動作，這樣就使得工作失誤率低、工作效率高。
1.2國內外智能藥房研究和應用現狀
1.2.1國外智能藥房研究、應用現狀
20 世紀 90 年代以來隨著計算機技術、控制工程技術的快速發展，國外很多公 司開始研發智能藥房設備，并且將智能藥房設備與醫院信息管理系統對接，實現 自動或半自動發藥［10-14］，由于智能藥房的便捷性，國外越來越多的智能藥房產品 被研制出來［15］，在國外尤其是歐洲市場得到了廣泛的認可。這些智能藥房按它們
特點主要歸納為如下幾種：
(1)機械手式的智能藥房
目前德國 ROWA 公司的智能藥房是號稱“歐洲第一”的智能藥房,它的技術水 平相對成熟,也是在世界上相對較早的對智能藥房這項技術進行研究的。德國 ROWA 成立于二十世紀 90 年代，該公司的機械手式的智能藥房最具有代表性的， 如圖 1.1 所示。歐洲領域使用該機械手式智能藥房的數量超過 1000臺。在歐洲的
市場反應良好,歐盟中的 14個國家正在使用這個設備。這種設備最大的特點就是能 對盒裝藥品進行密集儲存，提高空間利用率，利用機械手代替醫院工作人員來回 搬運藥品［16］。該系列藥房很快在中國打開了市場,已經成功應用在上海市黃浦區南 京路的上海市第一醫藥商店,人們的認可度和社會反應效果良好,帶來的經濟利益 也使投資者更加看好這種智能藥房。此智能藥房的硬件設備能夠與醫院HIS系統 進行對接，讀取醫院的處方信息,方便醫院工作人員管理藥品和處方信息［17］。機械 手式的自動化藥房取代了原有的人工取藥,降低了人力勞動的時間和強度,但是這 種智能藥房明顯存在以下幾點不足與弊端:
其一,機械手成本太高,只有效益不錯的三甲醫院可以負擔得起,因此此類智能 藥房在國內大多數中小型醫院很難廣泛流通。
其二,取藥發藥的處理效率不高,機械手同一時刻單次只能夠抓取某一盒藥品, 無法并行處理,因此不適用于國內一線城市及絕大多數省會城市中大型醫院藥房和 藥店。
其三,抓取藥品的種類范圍受限,機械手式智能藥房主要采用的是真空吸附和 夾持藥品相結合的技術,因此部分非盒裝的藥品無法采用真空吸附的技術抓取藥品。
綜上所述，這種機械手只適合國內的商用藥店和小型的處方藥店［18］，不適用
于中大型醫院。
(a) Overall map of smart pharmacy (b) Partial map of smart pharmacy
圖 1.1 德國 ROWA 公司的 Topspeed 智能藥房
Fig 1.1 Topspeed intelligent pharmacy of German ROWA company
（a）岀藥系統 （b）進藥系統
a） Drug delivery system （ b） Drugfeeding system
圖 1.2 德國 ROWA 公司的智能藥房
Fig 1.2 Intelligent pharmacy of German ROWA company
瑞士 Swisslog 設計岀了一種與上面介紹的不同的機械手式智能藥房，它是采 用機械手搬運標準藥盒的方式進行上藥補藥操作，但是每個藥盒都是一樣的，藥 盒里的藥品也是一樣的，瑞士 Swisslog公司的Boxpick智能藥房（見圖1.3a）和 Pillpick智能藥房（見圖1.3b）。這兩種智能藥房的缺點就是更適用于醫藥公司, 不太適用于醫院藥房。
1.3(a) Boxpick 智能藥房 1.3(b) Pillpick 智能藥房
1.3( a) Boxpick smart pharmacy 1.3( b) Pillpick smart pharmacy
圖 1.3 瑞士 swisslog 公司的智能藥房圖
Fig 1.3 A smart pharmacy from swisslog, Switzerland
（2）斜坡儲藥槽式智能藥房
法國 APOTEKA 公司和荷蘭 RoboPharma 公司經過幾年的研究設計，終于研發 出了一款斜坡儲藥槽式智能藥房，這種智能藥房避開了機械手式的缺點 （見圖 1.4 和圖1.5所示）［19］。為了滿足某些醫院的需求，名為TopSpeed的儲藥槽式智能藥房 被德國 ROWA 推出［20］。斜坡儲藥槽式智能藥房按照藥品包裝的長寬高將設備劃分 成一個個小的儲藥槽中，當沒有發藥動作時，有擋板會擋住藥品使其不能下落； 當需要發藥時，擋板會被抽離，藥品會在自身重力的作用下下滑到出藥口。取藥 裝置底端采用緩沖物進行緩沖,緩沖對藥品進行了一定的保護作用,因此這種方式 逐漸占領了市場成為主流設計方案。若要想提高效率增加藥物的存貯的劑量就只 有增加儲藥槽, ,這樣就使得生產成本較高，因此，目前這種智能藥房在中國也沒有 很大的市場。
（a）智能藥房外觀圖 （b）智能藥房局部視圖
(a) Appearance diagram of intelligent pharmacy (b) Local view of intelligent pharmacy
圖 1.4 法國 APOTEKA 公司的智能藥房
Fig 1.4 APOTEKA's smart pharmacy in France
圖 1.5 荷蘭 RoboPharm 公司儲藥槽式智能藥房
Fig 1.5 RoboPharm smart pharmacy, Netherlands
(3)散裝藥品的智能藥房
這種智能藥房的工作原理是采用機械手在程序的驅動下完成取藥補藥，同時 可以自動封裝、自動貼標簽。這種形式的智能藥房主要適用于瓶裝藥，但我國目 前藥品大多以盒裝藥為主。另外，這種智能藥房更適用于醫藥分離的藥房，但我 國目前醫藥還是一體的，故此種類型的智能藥房目前很難在中國市場流通。這種 藥房在歐洲已經占有非常大的市場，生產這種藥房的公司代表有英國 Mission 公司， 該公司比較代表性的智能藥房是 ScriptPro Robot 智能藥房。
(4)數控立體回轉式的智能藥房 數控立體回轉式的智能藥房的設計靈感來源于市場上一些大型自動化工廠的
數控立體回轉式倉庫,這種倉庫可以將零件與產品進行科學的管理與存放,智能藥 房模仿該種模式將醫院倉庫里的藥品信息及醫生工作人員的信息進行管理并同醫 院HIS(Hospital Information System)系統進行對接，在充分利用空間的情況下，設計 添加了供醫院藥房相關工作人員操作的保護裝置系統和人機接口裝置。顯而易見, 該種智能藥房是一種半智能化藥房,因為好多工作需要人來協助才能完成。
數控立體回轉式的智能藥房的典型代表作品是由德國 Hanel 生產的(見圖 1.6， 圖 1.7) ,它的工作原理是:利用回轉的傳動鏈將可移動的儲藥斗進行鉸接,不同種類 的藥品按照類別被存放在不同的儲藥裝置內部。在發藥過程中,當發藥指令發岀時, 處方上所需藥品的儲藥斗在電機的帶動下按照管理系統發岀的發藥指令轉動到數 控立體回轉式的智能藥房的正面的取藥口以便于藥劑師完成取藥的動作操作,然后 將所有藥品信息進行再次審核后交付給病人完成發藥動作。補藥操作與發藥動作 原理相同,在設備接收到補藥指令后,電機將需要補藥操作的儲藥斗依次轉動到設
備的正面,此時藥房藥劑師可以將需要補給的藥品放入到相應的補藥口的藥斗里完 成補藥動作。
圖 1.6 德國 Hanel 回轉式的智能藥房 圖 1.7 垂直旋轉式智能藥房
Fig 1.6 Germany Hanel revolving smart pharmacy Fig 1.7 Vertical rotary smart pharmacy
這種由轉動儲藥斗而實現的回轉式智能藥房可以完成不同包裝規格藥品的儲 存、發放和補給,但由于每次的取藥和補藥動作都要在電機的帶動下轉動儲藥斗,并 且每次的轉動的速度比較慢,因此造成發藥和補藥的效率偏低,同時由于醫院藥房 空間的限制,設備的儲藥斗比較有限,因此所能存儲的藥品數量有限,種種原因使得 該種設備的廣泛推廣使用受到了限制［21-22］。
1.2.2國內智能藥房研究、應用現狀
我國目前醫院藥房藥品絕大多數還是盒裝藥品,因此,盒裝藥品智能藥房設備 產品在國內醫院藥房市場缺口比較大。西方國家及日本雖說已經研發出了很多各 種形式的智能藥房,但是還是沒有能夠適應中國特有國情的能夠實現既快速、又準 確發藥和補藥的智能藥房,在中國這樣一個人口大國,各個醫院的藥品種類和數量 是比較龐大的,這就首先需要智能藥房的管理系統能和醫院的信息管理系統能夠完 全融合,兩者不能僅僅只是信息的簡單傳遞。 1978 年以來，隨著中國經濟的快速發 展，國內智能藥房發展迅速［23-25］，相關學術工作者已經認識到研制智能藥房設備 的必要性，已經開始在智能藥房領域開展相關研究，主要分以下幾個階段：
2004年，國家 863計劃中有一個智能藥房開發與設計的項目，這雖不是是國 內最早提出智能藥房研究的，但對智能藥房在國內的發展意義非凡。北京航空航 天大學機器人研究所聯合一家公司研制開發出了一臺智能藥房，并且得到了專家 的稱贊。該智能藥房配套的軟件系統能方便地管理藥品信息和用戶信息，有效的 降低了醫院工作人員的工作強度。軟件系統配合智能藥房下位機執行系統能完成 自動發藥的過程，在一定程度上降低了由于人工取藥帶來的錯誤。但該智能藥房 的應用對象主要是中藥，而且只能用于處方量不多的小型醫院，該智能藥房無法 在國內流通［26］。
1988 年，航天工業部第三研究院第三十五研究所提岀自動發藥機的構思［27］， 這是我國最早一次提岀智能藥房概念，相對于歐洲國家來說，我國關于智能藥房 的理論研究的起步并不比他們遲，但是當時的中國依然是貧困大國，科研工作者 沒有資金支持相關的工作，醫院也沒有足夠的費用引進昂貴的智能藥房，關于智 能藥房的研發也就沒什么太大的實質性進展。
1995 年，中國人民解放軍成都軍區總醫院工作人員意識到大量藥品管理的難 度，醫院領導和四川大學教授探討智能發藥和智能藥房信息管理系統的相關問題， 四川大學科研團隊提岀可以設計一種智能藥房信息管理系統［28］，以減輕醫院工作 人員的負擔，該系統雖能利用計算機對醫院處方信息進行管理，然后醫院工作人 員按藥單找藥取藥，然后將藥品放置在傳送帶上，在電機的驅動下將藥品運動到 發藥窗口以待患者取藥，這種系統的智能化水平偏低，發藥補藥效率還是很低下， 未能從根本上解決問題，導致系統的實用性不高。
2000 年，李伯孝提岀可以使用回轉式的藥架［29］，藥架從上到下被分為很多層， 每層可以放置很多不同的藥品，需要某種藥時，就要人轉動藥架，這種裝置由于 操作簡單而且價格不高，在當時的醫院風靡一時，受到很多醫院工作人員的喜愛， 但這種裝置由于不能對處方和藥品進行智能管理，導致發藥上藥失誤率較高，而 且需要醫院工作人員對藥架上的藥品存放位置有一定的記憶，藥架占地面積較大， 并不適用于目前經濟繁榮的中國。
2002 年，胡乃鋼設計岀了一臺斜儲藥槽智能投藥機［29］，該智能投藥機配合岀 藥機構能夠實現自動岀藥，采用傾斜的儲藥槽可以一方面提高空間的利用率，這 種裝置是現代智能藥房的雛形。
2006年上半年，蘇州隆科技有限公司技術高管在歐洲交流學習中，參觀了一 家引進了德國 ROWA 公司機械手式智能藥房的醫院，倍受啟發，回到國內聯合北 京航空航天大學機器人研究所設計岀了國內第一臺機械手式智能藥房，在當時一 些小型醫院特別受歡迎，但由于機械手式智能藥房固有的缺點，不能滿足于國內 較大型的醫院藥房。但是在開發設計的過程中，科研工作者通過不斷的交流學習， 積累了很多寶貴的經驗，為今后智能藥房的研究指明了道路與方向。蘇州隆科技 有限公司與北京航天航天大學在此期間已經開展了對儲藥槽式智能藥房的研發設 計。
2007年下半年，由這兩家單位聯合設計的第一臺儲藥槽式智能藥房問世（見圖 1.8 和圖 1.9所示），為了測試該智能藥房，聯系張家港一家醫院試用該智能藥房， 經試用后，該智能藥房受到了醫院工作人員的一致好評，但也反應了一些小問題， 研發工作者在得到這些反饋后決定在第一代儲藥槽式智能藥房的基礎上改進與優 化。2008 年年底，第二代儲藥槽式智能藥房設計研發項目正式啟動，科研工作者 在市場調研的基礎上大膽創新，歷經數年，終于研制成功第二代儲藥槽式智能藥 房，目前該智能藥房被國內多家醫院引進使用，反應效果良好。快速出藥系統外
觀及內部圖如圖 1.8 和 1.9 所示。
圖 1.8 快速出藥系統外觀
圖 1.9 快速出藥系統內部
Fig 1.8 appearance of rapid drug delivery system Fig 1.9 Inside the rapid drug delivery system
總而言之，雖說國內關于智能藥房的構思起步跟西方歐美國家差不很多，但 是由于中國當時比較落后，國外的智能藥房水平比中國高出很多。但經過業界科 研工作者的努力，到 2007 年以后，國內的智能藥房也迅速崛起，各種各樣的智能 藥房開始涌入市場，配套的信息管理系統也越來越成熟，這就在一定程度上進一 步縮小了與國外智能藥房的差距［31-33］。
1.3 課題的研究內容
本課題來源于校企合作項目，結合項目要求、意義以及項目的實際情況，課 題主要設計智能藥房的上位機信息管理系統，并且搭建智能藥房下位機執行系統 完成功能測試。課題的主要研究內容如下：
（1） 智能藥房信息管理軟件系統能通過局域網從醫院HIS系統接收處方信息。
（2） 智能藥房信息管理軟件系統能對經接口系統篩選的處方進行處理，將相 應的發藥或補藥動作指令發送給下位機系統。
（3） 當某種藥品低于其自身最小存儲量時，系統會報警提示補藥操作，并且 將所需補充藥品信息顯示在液晶LCD顯示屏上以方便藥劑師補藥。
（4） 醫院發藥、補藥以及智能藥房軟件系統的運行狀態等都能通過相應的界 面查看到，方便工作人員開展工作。
（5） 對快速發藥機和異型包裝藥架數據庫進行實時更新管理，當有新的藥品 需要添存放在快速發藥機里，根據藥盒的尺寸為其分配合理的位置。
（6） 可以高效管理醫院的醫生信息、病人信息、藥品信息、處方信息和數據 庫信息等。
（7） 用戶可以通過信息管理軟件系統實時查看發藥、補藥進度及處方過往記 錄。
（8） 智能藥房信息管理軟件系統還具有一些輔助功能，如不同用戶權限級別 不同、在突然斷電或者系統故障時能及時保存數據的功能等。
1.4 論文的章節安排
本文總共有六章，各章節的安排如下： 第一章:緒論。首先介紹本課題的研究背景、研究意義以及國內外的發展現狀， 其次描述課題的主要研究內容及實現的具體功能，最后給出論文的章節安排。
第二章:智能藥房信息管理與控制軟件系統需求分析。首先引入數據流圖的概 念，再根據數據流分析的方法對上位機信息管理軟件系統進行分析，得到軟件系 統的用戶需求分析、功能需求分析等，最后對數據庫 E-R 模型進行設計，構建了 藥品相關實體、處方相關實體及系統相關實體的 E-R 圖。
第三章:智能藥房系統總體設計。首先簡單介紹智能藥房系統的機械結構，介 紹智能藥房盒裝藥密集存儲的原理，其次詳細對智能藥房上位機和下位機的整體 設計以及上位機各功能模塊進行了分析，然后給出了上位機信息管理與控制系統 的主要工作流程，最后對智能藥房下位機系統進行了簡單介紹。
第四章:系統的設計與實現，其中包括通信模塊、數據庫模塊、控制模塊和下 位機補藥控制模塊。控制模塊包括主控模塊、接口模塊和補藥模塊，主控模塊是 核心模塊，包括系統控制、處方管理、用戶信息管理和藥品信息管理等主要功能。 對下位機補藥控制系統模塊進行了設計與實現。
第五章:系統測試。首先搭建測試環境，包括模擬HIS系統和下位機執行系統， 其次對信息管理與控制系統的基礎功能模塊進行測試，然后對系統接收和處理處 方的功能進行多次測試，最后分析測試結果。
第六章:總結與展望。首先簡明扼要地總結了課題研究的成果，最后對課題今 后需要改善的地方提出了自己的觀點。
第二章 智能藥房信息管理與控制軟件系統需求分析
2.1 數據流圖概述
當今社會如何從大量的數據信息中提取對自己有用的信息則成了非常重要的 問題。信息技術在信息篩選的過程中起著至關重要的作用，能否在軟件開發前期 對用戶的需求分析進行歸納和總結，則成了軟件設計開發的重要衡量標準。因此， 在軟件開始編程前，需要對用戶的需求信息進行分析和提取，這樣就可以避免后 期設計的軟件無法達到用戶的期望的情況［34-36］。目前最受歡迎的分析方法是結構 化分析方法。
數據流圖也稱為數據流程圖(date flow diagram, DFD)，是一種便于用戶理解和 分析系統數據流程的圖形工具［37］。對于像智能藥房相關信息比較復雜的軟件系統， 采用數據流圖可以比較便捷的理清信息之間的相互聯系。數據流圖是結構化分析 方法中的一種，它可以逐步求精的對問題進行分析［38］。其四種圖形結構如表 2.1 所示。
表 2.1 基本圖形元素
Tab 2.1 Basic graphic elements
元素 定義 符合 備注
數據流
加工 數據和數據流向
對數據進行的操作 箭線
圓形或圓角矩形 一個成分的數據組 成，方向表示流向 每個加工都有編號， 說明該加工在層次分
數據存儲 要存儲的數據 兩條平行線 解中的位置
流向存儲的數據流表
示向數據存儲中寫數
據或查數據，流岀數
外部實體 軟件系統之外的提供
者或者使用者 正方形或立方行 據存儲表示讀岀數據 或者查詢結果 表示數據輸入的源點 或者數據輸岀的終點
在智能藥房信息管理與控制軟件系統設計的過程中，采用數據流分析能夠幫
助開發設計人員更加高效地分析和設計出優質的軟件系統。
2.2 數據流分析
在智能藥房的總體框架的設計中，上位機軟件系統處于智能藥房系統的核心 位置，在醫院信息管理系統與發藥補藥設備之間起到關鍵的橋梁作用。本節采用 結構化分析方法以數據流圖作為分析手段對智能藥房信息管理與控制系統系統進 行相關分析，系統的頂層數據流圖如圖 2.1 所示。
Fig 2.1 System top layer data flow diagram
圖2.1中，上位機信息管理系統通過局域網接收來自醫院HIS系統的處方信息， 其中包括發藥電子處方和補藥電子處方。上位機軟件系統首先判斷接收的電子處 方的格式及內容是否符合要求，如果不滿足要求，則將電子處方信息反饋給醫院 HIS 系統，讓醫生重新編輯符合要求的電子處方，滿足要求的電子處方會被上位機 主控系統初步預處理，然后構造發藥或補藥指令給下位機中控系統，中控系統會 控制下位機執行系統完成發藥或者補藥操作。下位機軟件系統接收到指令信息完 成相應的動作，并且能及時地反饋處理狀態給上位機軟件系統。在整個發藥或補 藥的過程中，上位機主控系統可以主動查詢下位機執行系統的處理狀態。
系統 0 層數據流圖如圖 2.2 所示。
Fig 2.2 System 0 layer data flow diagram
在圖 2.2 中，首先接口系統與醫院信息管理系統對接，接收醫院發送過來的電 子處方，然后判斷處方是否有效，如果處方信息格式錯誤或者內容無效，電子處 方無法被進一步處理，無效處方信息會被反饋至醫院處方編輯處，等待醫院醫生 再次編輯新的電子處方。格式和內容均無問題的處方會被上位機信息管理系統進 行預處理，并將電子處方信息保存至本地數據庫。如果處方上所需藥品信息充足， 則向下位機執行系統發送發藥指令，如果處方上有藥品不足，則庫存不足藥品信 息會保存至待補充藥品表中，同時上位機主控系統向補藥電腦發送補藥指令，待 補藥窗口電腦完成補藥動作后，會將動作結果反饋至上位機主控系統。
主控信息處理1層圖如圖2.3所示。
圖 2. 3 主控信息處理 1 層圖
Fig 2.3 1 layer diagram of master information processing 在圖 2.3 中，首先經接口系統篩選后的有效電子處方會被上位機主控系統分析 處理，同時將電子處方保存至本地數據庫有效處方表中。然后上位機主控系統對 有效電子處方待處理序列按時間先后順序進行預處理，得到每種藥品在快速發藥 機的具體位置坐標（或異型藥在藥架的第幾行第幾列），判斷處方上所需藥品數 量是否足夠，如果有些藥品存量不足，則需要向補藥電腦發送補藥指令，同時， 將操作指令信息存儲在儲配操作指令表數據庫中。補藥電腦收到補藥信息后，藥 劑師按照補藥藥單進行人工補藥操作。下位機執行系統在完成發藥或者補藥操作 后，需要將處理狀態反饋至上位機主控系統，同時需要更新本地數據庫的相關信 息。
2.3 用戶需求分析
顧名思義，用戶需求分析是從用戶的角度分析軟件系統的功能。在與用戶溝 通的過程，了解到用戶希望系統能實現發藥自動化和補藥半自動化。用戶需求的 主要內容如下:
（1） 智能藥房信息管理軟件系統能通過局域網從醫院HIS系統接收處方信息。
（2） 智能藥房信息管理軟件系統能對經接口系統篩選的處方進行處理，將相 應的發藥或補藥動作指令發送給下位機中控系統。
（3） 當某種藥品低于其自身最小存儲量時，系統會報警提示補藥操作，并且 將所需補充藥品信息顯示在液晶 LCD 顯示屏上以方便藥劑師補藥。
（4） 醫院發藥、補藥以及智能藥房軟件系統的運行狀態等都能通過相應的界 面查看到，方便工作人員開展工作。
（5） 對快速發藥機和異型包裝藥架數據庫進行實時更新管理，當有新的藥品 需要添存放在快速發藥機里，根據藥盒的尺寸為其分配合理的位置。
（6） 用戶可以通過信息管理軟件系統實時查看配藥、發藥進度及處方過往記 錄。
（7） 能藥房信息管理軟件系統還具有一些輔助功能，如不同用戶權限級別不 同、在突然斷電或者系統故障時能及時保存數據的功能等。
2.4 功能需求分析
引入智能藥房管理系統的目的就是為了降低醫院工作人員的工作強度，簡化 工作流程，輔助醫院醫師和藥劑師自動或半自動完成發藥和補藥的過程。總結來 說，智能藥房信息管理與控制系統需要具備以下功能：
（1）用戶和藥品的基本信息管理
對存放在快速發藥機和異型藥架上的藥品信息進行管理，在醫生檢索查詢某 種藥品時能夠了解到該藥品的本地規模（本地剩余量）、藥品編號、藥品類別、 藥品所在行和所在列、藥品有效期和生產日期等。對于剩余庫存不多的藥品，醫 生要提醒補藥房管理人員及時補充藥物。
對系統管理員、藥劑師和醫師的基本信息進行管理，在用戶使用該系統時， 不同的工作人員功能也不相同，每個工作人員都有自己唯一的賬號和密碼。系統 管理員可以定期刪除已退休和離職工作人員的基本信息，也可以根據需要新增一 些新入職人員的基本信息，以便他們能順利參與到工作中來。
（2） 本地數據庫的藥品存量管理
1） 當上位機主控系統收到每個處方發藥完成后，都要及時修改快速發藥機和 異型藥架的數據庫。
2） 由于每種藥品的需求量各不相同，因此需要對每種藥都要設置最小存儲量， 當藥品存儲量低于最小存儲量時，系統會將補藥信息發送至補藥窗口電腦，同時 該藥品的信息會顯示在液晶顯示屏上，必要時要設置報警燈提示藥劑師補藥。
（3） 處方實時監控管理
在智能藥房系統工作過程中，每個處方中的藥品信息（包括序列號、處方編號、 處方日期、藥品編號、發藥數量、發送狀態等）、系統運行狀態、系統異常記錄等 都會實時的顯示在界面上，藥劑師等工作人員可以隨時查看。
（4） 系統控制
1） 處方發藥工作過程
上位機信息管理系統在收到接口系統的待處理處方序列后，系統會自動檢查 電子處方上所指定生產廠商的藥品庫存數量是否滿足所需，如不滿足，則需要提 醒藥劑師緊急人工補藥，同時上位機軟件管理系統會按照時間先后順序的原則對 發藥臨時表中的電子處方進行處理，然后發送發藥指令給下位機中控管理系統， 下位機中控管理軟件系統會根據相應的最優算法優化發藥路徑，繼而控制執行機 構將電子處方中盒裝待取藥品按最優路徑發藥，藥品運動至取藥窗口以供藥劑師 核對并交給病人。電子處方中如若有非盒裝藥等異型包裝藥品，在異型包裝貨架 前的藥劑師可以通過人工取藥窗口電腦查看到需人工拿取的藥品，取藥窗口藥劑 師把盒裝和異型包裝藥匯總到一起交給病人。
2） 半自動化補藥控制
當本地數據庫里的藥品低于設定的最低存量時，系統會向補藥窗口電腦發岀 補藥操作指令，在項目測試的階段，補藥信息會顯示在液晶LCD顯示屏上以供藥 劑師補藥操作。
Fig 2.4 System working process
2.5 數據庫的概念模型建模
2.5.1 數據庫的概念模型概述
數據庫概念模型是對現實世界的抽象反映，它不依賴于具體的計算機系統， 是現實世界到機械世界的一個中間層次［39］，軟件都是基于某種數據模型的［40］，數 據庫管理系統（DBMS）并不直接支持現實世界數據模型，因此很多數據必須經過 一定的轉換或者抽象，才能被 DBMS 存儲和管理。數據抽象過程及信息數據的形
Fig 2.5 Data abstraction process and the formation of information data
數據庫概念模型是目前數據庫設計最有效的方法之一，概念模型也是對現實 的信息世界的一種抽象與建模，還是數據庫設計人員之間便捷的溝通方式。因此， 數據庫概念模型一方面應該具有簡便、直觀、有效和易懂的特點，另一方面，它 還應該能夠清晰直接的表示生活中的各種各樣的實體信息［41］。在數據庫概念模型 設計的過程中，主要會遇到如下的重要概念：
(1)實體(Entity ):實體是現實社會里真實存在并且各自有自身特點的事物， 人或者物都可以稱作為實體，這些實體是看得見摸得著的具體的，例如某人在商 店的一次購物、學生的一次選課等；也可以是抽象的概念以及事物與事物之間的 聯系，例如病人的一次醫院就診、藥劑師每一次的發藥補藥等都可以稱之為實體。
(2)屬性(Attribute ):每個實體是區別于其他實體的，實體所區別于其他實 體的特性稱之為實體的屬性，實體的屬性并不一定是唯一的，一個實體的屬性可 能具有多個。例如，醫生實體的屬性有醫生姓名、醫生性別、醫生職稱、醫生年 齡、醫生科室、醫生備注等。
(3)鍵(Key )：實體的屬性里，有且僅有一個是用來區別其他實體的，這個 屬性被稱之為鍵，鍵還被稱作實體的關鍵字或者關鍵詞。例如，藥品名稱是藥品 的鍵。
(4)域(Domain ):每一個屬性值的取值上限取值下限則構成了屬性值的域。
(5)實體型(Entity Type ):特征和性質相同的實體的屬性相同。
(6)實體集(Entity Set )：同型實體的集合稱為實體集。例如，一個公司的 所有成員則可以構成一個實體集。
(7)聯系(Relationship ):在現實的世界里，沒有任何一個實體是獨立存在不 與其他實體存在聯系的。
2.5.2 數據庫 E-R 建模
描述方法數據庫概念模型的最有效的即是“實體一聯系方法”(E-R方法)， E-R方法是英文Entity-Relationship Approach的簡稱，E-R方法是一種面向問題的 解決方法，利用E-R方法可以準確而快速的對復雜的世界信息進行梳理和建模， 這種方法描述了實體型、實體屬性以及實間的相互關系，這三種基本概念是E-R 模型的主要組成部分［42-43］。 兩個實體型之間的聯系可以分為三類:(1)一對一的 聯系(1:1) ； (2) 一對多的聯系(1:M) ； (3)多對多的聯系(M:N)；
經過對智能藥房信息管理與控制系統的綜合分析，對醫院相關實體信息進行 整理后可以將藥房實體分為以下三類:
(1)藥品和相關信息實體
1)藥品信息實體:主要描述與藥品相關的基本信息，其中主要包括藥品拼音、
藥品名稱、藥品有效期、藥品類別和藥品備注等。
2） 藥品庫存信息實體：主要描述與藥品相關的位置信息，其中主要包括存儲 編號、藥品編號、最大庫存量和最小庫存量等。
3） 藥品供應商信息實體：主要描述與藥品相關的供應商信息，其中主要包括 供應商聯系方式、供應商名稱等。
4） 藥品生產商信息實體：主要描述與藥品相關的生產商信息，其中主要包括 生產商名稱、生產商編號和生產商備注信息等。
5） 藥品供給信息實體：主要描述藥品信息實體與藥品信息供應商信息實體之 間的聯系，其中主要包括藥品供給編號、藥品供給日期、藥品供給價格和藥品供 給數量等。
由于一種藥品可以被多家公司生產與制造，所以藥品供應商與藥品生產商是 一對多（1:M）的關系；一種藥品可以由多家藥品供應商供應，同時，一家藥品供 應商可以供應多種藥品，所以藥品供應商與藥品信息是多對多（M:N）的關系；一個 位置只能用來存放一種藥品，但一種藥品可以存放在多個位置里，所以藥品信息 與位置信息是一對多（1:M）的關系。藥品有關實體E-R圖如圖2.6所示。
圖 2.6 藥品有關實體 E-R 圖
Fig 2.6 Drug related entity E-R diagram
（2）處方和相關信息實體
1） 有效處方信息實體:主要是經醫院接口系統判斷處理過后的有效電子處方 信息，其中主要包括HIS處方編號、藥品數量以及各處方處理狀態，處理狀態包 括已處理和待處理兩種狀態。
2） HIS 詳細處方信息實體:主要描述醫生在最開始看完患者病情后編輯的電子 處方，其中主要包括電子處方編號、電子處方日期和醫生信息描述等。
3） 操作指令信息實體:主要描述智能藥房信息管理與控制系統向下位機執行 系統發送的發藥或者補藥指令，其中主要包括發藥操作指令、補藥操作指令和藥 品存儲指令。
4） 病人掛號信息實體:主要描述病人掛號的一些有關信息，其中主要包含有 病人姓名、病人年齡和掛號時間等。
5） 藥品信息實體:主要描述與藥品相關的基本信息，其中主要包含有藥品備 注、藥品類別、藥品名稱等。
處方相關實體的關系反映在E-R圖中，這里就不 贅述。如圖2.7所示。
Fig 2.7 Prescription related entities E-R diagram
上文詳細描述了藥品及其相關實體信息、處方及其相關實體信息，但對于一 套完整的信息管理與控制的概念模型來說，還必須要有一些服務于軟件管理與控 制系統的實體信息，一套信息管理與控制可以對應多個服務實體信息，因此信息 管理與控制與服務于系統的實體信息是一對多（1: M）的關系。軟件管理與控制系統 相關實體 E-R 圖如圖 2.8 所示。
圖 2.8 軟件管理與控制系統相關實體 E-R 圖
Fig 2.8 Software management and control system Entity E-R diagram
2.6 本章小結
本章主要介紹智能藥房信息管理與控制軟件系統需求分析。首先引入數據流 圖的概念，再根據數據流分析的方法對上位機信息管理軟件系統進行分析，得到 軟件系統的用戶需求分析、功能需求分析等，最后對數據庫 E-R 模型進行設計， 構建了藥品相關實體、處方相關實體及系統相關實體的 E-R 圖，為下章的內容奠 定了基礎。
第三章 智能藥房系統總體設計
3.1智能藥房的機械結構簡介
目前市場上的藥品絕大多數都采用盒裝的形式，少數異型包裝的藥品存水平 放在異型包裝藥的貨架上，由于異型包裝藥品的數量還是相對較少的，可以由藥 劑師進行人工取藥，這樣也不會耽誤處方發藥的流程。但是，盒裝藥品的種類和 數量是繁多的，如果還采用普通貨架水平存放藥品、人工取藥的方式的話，就會 導致各個儲藥層之間有很大間隙，空間使用率低下，不能達到藥品的密集存儲； 并且藥劑師不能在較短的時間內找到需要拿取的藥品，或者會發生拿錯藥的現象，
這樣無疑是工作量大、但工作效率也會不高。為了有效解決以上問題，智能藥房 系統采取了如圖 3.1 的藥品存儲結構。
圖 3.1 斜坡式存儲結構側視圖
Fig 3.1 Side view of sloping storage structure
該斜坡式存儲結構的工作原理是藥品利用自身重力下滑到出藥口，撤銷出藥 口前的擋板，藥品就能順利落到出藥口，然后由藥劑師對所有藥物匯總交給患者。
該斜坡式存儲結構的傾斜角一般在15°到 30°之間，角度過大，在擋板機構撤開后， 藥品容易出多；角度過小，藥品雖有下滑的趨勢，藥品所受摩擦力等于重力在X 軸方向的分力，導致藥品不能順利下滑到出藥口。
當某種藥品不足時，藥槽內置的報警燈會報警提示藥劑師補藥，藥劑師根據 上位機發送過來的待補藥表信息進行人工補藥操作，藥劑師也可以定期主動對需 求量比較大的藥品進行補充。
采用這種存儲結構的智能藥房對空間的利用率很高，同時這種結構配合智能 藥房軟件系統能實現藥房全自動化發藥，這就在很大程度上減輕了藥劑師的工作 強度，提高了發藥的效率。
3.2智能藥房系統上位機和下位機的總體設計
智能藥房系統軟件分為上位機和下位機兩部分。上位機主要實現管理與控制 的功能，下位機則主要實現相應的執行動作的功能。
上位機管理與控制軟件系統用來接收來自醫院信息管理系統（HIS）發過來的 電子處方，經過對電子處方的一系列的分析處理以后，確定電子處方中的盒裝藥 品在本地數據庫的庫存是否足夠，如若藥品庫存足夠的話，藥品在智能藥房快速 發藥機中的位置分布（X,Y）也能顯示在人機交互界面上。然后通過串口通信向下 位機控制軟件發送發藥指令，調出相應倉位的藥品到出藥口的藥籃中。當本地數 據庫藥品信息不足時，上位機管理與控制軟件系統向下位機控制軟件（STM32單片 機）發送補藥信息。
下位機主要分為下位機軟件控制和下位機硬件執行系統。下位機控制系統主 要分為下位機發藥控制系統和下位機補藥控制系統。下位機中控管理系統通過串 口 RS485 與上位機通信，接收來自上位機軟件系統的發藥或補藥指令，中控系統 對有效指令處理后構造動作指令給下位機執行機構，從而完成發藥或者補藥的過 程。由于補藥流程屬于半自動化，為方便藥劑師進行人工補藥，相應的補藥信息 顯示在相應的LCD液晶顯示屏上，同時這些數據會通過串口通信傳送給上位機信 息管理軟件系統，上位機信息管理軟件系統會根據這些數據自動修改本地藥品數 據庫。上位機信息管理軟件能根據數據庫中各種藥品數量的歷史數據自動生成不 同藥品的數量下限值，此下限值是根據該藥品近期的使用情況智能調節的，近期 使用量越大，下限值就會越高，相反，下限值會降低，上位機信息管理軟件根據 藥品數量下限值自動生成缺藥藥品的信息表可以供藥劑師進行主動人工補藥操作。
如果把智能藥房再細分來看的話，智能藥房系統可以分成五大部分：上位機 信息管理與控制系統、發藥控制系統、補藥控制系統、補藥顯示液晶屏、下位機 執行系統。細分后的智能藥房系統總體結構圖如圖3.2所示。
圖 3.2 智能藥房系統總體結構圖
Fig 3.2 Overall structure of intelligent pharmacy system
3.3上位機信息管理與控制系統設計
智能藥房上位機信息管理系統首先跟醫院 HIS 系統對接，接收并處理電子處 方，配合下位機完成發藥和補藥操作。在項目的實驗階段，上位機軟件系統由模 擬的 HIS 系統、上位機主控系統、人工發藥系統(異型包裝發藥電腦)、發藥窗 口系統、補藥窗口系統組成，如圖 3.3 所示。
圖 3.3 上位機信息管理與控制系統組成圖
Fig 3.3 Composition diagram of upper computer information management and control system
3.3.1上位機信息管理與控制系統各電腦的功能
(1)模擬醫院 HIS 系統電腦 在系統的前期測試實驗階段，可以設計一個模擬醫院 HIS 系統，實現編輯和 修改處方的功能。其主要功能如圖 3.4 所示。
鞠醫院HIS系統
圖 3. 4 模擬醫院 HIS 系統功能模塊
Fig 3.4 Function module of hospital HIS system
但是到最終的項目驗收交接階段，完成這些功能的是一個接口系統，接口系 統通過跟具體的醫院信息管理系統對接，接收并判斷電子處方是否為有效電子處 方，若為有效電子處方，將有效電子處方保存至本地數據庫待處理處方序列，最 后將處方信息發送至上位機信息管理系統；若為無效電子處方，則需要將無效電 子處方信息反饋至醫院HIS系統，等待醫生修改或者編輯新的電子處方。接口系 統工作流程圖如圖 3.5 所示。
圖 3.5 接口系統工作流程圖
Fig 3.5 Flow chart of interface system
(2)發藥窗口電腦
經接口系統處理和轉化后的電子處方發送給上位機主控系統，有效的電子處 方發送給發藥窗口電腦，藥劑師可以通過發藥窗口電腦查看有效的電子處方序列， 藥劑師按照序列對電子處方的信息進行再次校對，校對無誤的電子處方可以控制 下位機執行機構進行發藥動作，如果電子處方上全是盒裝藥則發藥完成后可以將 藥交付給病人，否則要等待某些異型包裝藥人工發藥操作。當主控系統接收到不 止一個電子處方時，為了防止一臺電腦過于忙碌而影響發藥過程，發藥窗口電腦 一般設置兩臺或者兩臺以上，這樣主控系統可以把新電子處方信息發送給相對比 較空閑的電腦處理，這樣可以避免一臺電腦出現問題而導致發藥流程中斷的現象。
發藥窗口電腦主要功能模塊如圖 3.6 所示。
發藥窗□系統
圖 3.6 發藥系統功能模塊
Fig 3.6 Function module of drug delivery system
(3)人工發藥窗口電腦 部分有效電子處方上有些是異型包裝藥，這些藥因為形狀大小與盒裝藥差異 較大，無法放置在快速發藥機里，只能單獨放置在一個貨架上，這些藥只能由藥 劑師進行人工取藥發藥，當人工取藥完成后，由藥劑師對處方上盒裝藥品和非盒 裝藥品進行匯總，最后核對無誤后交付給病人。其主要功能模塊如圖 3.7 所示。
異型包裝藥發藥窗口
系統
圖 3.7 異型包裝發藥系統功能模塊
Fig 3.7 Function module of drug delivery system for atypical packaging
系統發藥工作流程如圖 3.8 所示。
圖 3.8 發藥工作流程圖
Fig 3.8 Flow chart drug distribution
(4)補藥窗口電腦
補藥窗口系統主要與智能藥房快速發藥機中的藥品規模和異型包裝藥架上的 藥品余量有關，它具有兩種工作模式，分別為主動補藥模式和被動補藥模式。在 正常的被動補藥過程中，上位機主控信息系統發送一系列的補藥信息給補藥窗口 電腦，補藥窗口系統對補藥信息按序列順序校對和處理，藥劑師按照校對后的序 列順序補藥，系統會將補藥處理狀態信息實時反饋給上位機主控系統，上位機主 控系統會自動更改本地藥品數據庫。另一種工作模式是在醫院病人較少或者無人 時，這時候系統比較空閑，補藥窗口藥劑師可以通過補藥窗口軟件端查看各個快
速發藥機和異型包裝藥架的藥品剩余量，確定需要人工補藥的藥品位置，由藥劑
師進行人工輸入需要補藥的補藥信息，然后系統會將補藥的信息反饋給上位機信 息管理系統，上位機系統自動更新本地藥品數據庫。補藥工作流程如圖 3.9 所示。
圖 3.9 補藥工作流程圖
Fig 3.9 Drug supplement flow chart
當主控系統接收到不止一個電子處方時，為了防止一臺電腦過于忙碌而影響 補藥過程，補藥窗口電腦一般設置兩臺或者兩臺以上，這樣主控系統可以把新電 子處方信息發送給相對比較空閑的電腦處理，這樣可以避免一臺電腦出現問題而 導致補藥流程中斷的現象。其主要功能模塊如圖 3.10 所示。
圖 3.10 補藥窗口系統功能模塊
Fig 3.10 Function module of drug supplement window system
(5)主控電腦
主控系統是智能藥房軟件系統的核心，在醫院發藥和補藥工作過程中起著承 上啟下的作用，主控電腦功能很多，主要有以下功能：接收來自醫院HIS系統的 電子處方并對電子處方進行處理；對醫院藥品信息進行管理，對醫院用戶信息進 行管理；及時主動對醫院藥房庫存清點，定期補充銷量較大的藥品；負責與醫院 HIS 系統、發藥和補藥窗口電腦以及下位機控制板之間的通信。
3.3.2上位機信息管理與控制系統的功能模塊
上位機主控軟件系統運行在主控服務器上，是連接醫院藥房管理系統與下位 機控制系統的樞紐，是智能西藥房系統管理和控制的核心。下面列出幾個重要的 功能模塊:
(1) 系統設置模塊 通信模塊是系統設置模塊中最核心的部分，智能藥房軟件系統在實際工作中 主要需要與三個模塊進行通信才能完成發藥和補藥的操作。分別為：
1)上位機主控系統需要與醫院 HIS 系統的接口系統進行通信，才能接收來自 醫院的處方信息。
2)上位機主控系統與發藥窗口和補藥窗口電腦等也要通過TCP/IP通信才能 進行數據的傳遞。
3）上位機主控系統與下位機執行系統之間通過串口通信，上位機主控系統可 以接受下位機反饋信息，例如，接收處方處理狀態的反饋。
（2） 處方收發模塊
1）處方接收模塊:在系統工作過程中，該模塊主要是接收來自醫院接口系統 或者模擬 HIS 系統發送的有效電子處方信息，經過系統的初步處理，將電子處方 加入到待處理處方序列，等待處方處理模塊對處方進行預處理，并把處方信息保 存至本地數據庫待處理處方表（HIS詳細處方表）中。
2）處方處理模塊：主要對待處理處方進行預處理操作，處理模塊按照時間順 序對待處理處方進行信息分析處理，首先得到處方上各種藥品在快速發藥機上的 具體位置，其次判斷處方上每種藥在本地數據里是否足夠，若有藥品不足，則需 要把缺藥信息匯總并保存至待補充藥品信息表里，同時向補藥電腦發送補藥指令。 若處方上藥品庫存大于或等于處方上所需藥品數量，則簡單辨別藥品類別，如果 是盒裝藥，則需要向快速發藥機發送發藥指令，否則向異型包裝藥電腦發送發藥 指令。
（ 3）處方歷史記錄模塊
主要用來記錄以往的處方，并且可以對以往處方進行刪除、添加等。
（ 4）藥品信息管理模塊
藥品信息管理模塊是供藥房藥劑師和醫生管理或查看藥品信息而設計的。藥 房藥劑師主要通過該模塊添加或者刪除一些藥品信息，而醫院醫生主要通過該模 塊查看某種藥品的主要信息，通過輸入藥品的某種屬性就可以查看藥品的全部信 息，如輸入藥品編號、藥品名稱等。
（ 5）用戶信息管理模塊
主要可以對系統管理員、藥劑師、醫生的賬號、密碼、權限等添加、刪除、 查看等。
（ 6）發藥管理模塊
發藥管理模塊運行在發藥窗口電腦，主要功能是是接收來自主控系統處方管 理模塊發來的發藥指令，將藥單信息發送給下位機中控管理系統，下位機中控管 理系統構造發藥指令完成發藥操作。
（ 7）補藥管理模塊
補藥管理模塊按照順序從補藥隊列中讀取補藥藥單，初步解析后獲得藥品的 數量和藥品存放位置，然后將補藥藥單發送給補藥窗口電腦，供藥劑師及時補藥 操作。
主控系統由各個功能模塊組成，這些功能模塊之間相輔相成，共同完成了處
圖 3.11 上位機主控系統的功能模塊
Fig 3.11 Function module of master control system of upper computer
3.3.3上位機信息管理與控制系統流程設計
系統的流程結合系統數據庫里的若干表可以清晰地表示出如圖3.12所示的幾 個步驟。
圖 3.12 主控系統處理處方流程圖
Fig 3.12 Flow chart of prescription processing in the master control system
（ 1 ）用戶人員輸入正確的賬號和密碼進入上位機主控系統，主控系統和其他 系統完成通信連接，接收接口系統或者醫院 HIS 系統傳遞的電子處方。
（ 2）在主控系統接收到電子處方后需要對其進行一系列的處理，處理順序為: 首先將接收到的電子處方保存到 HIS 詳細處方表中，同時也將其保存在內部處方 表中，最后電子處方進入到待處理處方隊列。
（ 3）通過對待處理處方隊列的預處理，讀取到上位機主控系統的藥品庫存表， 確定處方中各種藥品在快速發藥機中的行列數，是否有藥品庫存不夠，如若有， 則需要及時發送補藥信息給補藥窗口電腦，當藥品庫存充足時，將預處理得到的 位置和數量信息保存至內部處方表中，由主控系統將電子處方分配給目前較為清 閑的發藥窗口電腦，異型包裝藥發送信息給異型包裝藥架電腦，同時保存至發藥 窗口電腦待發藥序列里，同時電子處方狀態顯示已分配。
（ 4）將發藥窗口電腦系統和異型包裝系統里保存的處方按順序發送相應的發 藥指令給下位機控制系統和人工取藥客戶端，下位機控制系統驅動下位機執行機 構取出處方上的藥品，同時在大屏幕上顯示藥品編號、藥品名稱和藥品數量和病 人姓名等。
（ 5）接收下位機軟件系統反饋處理情況，同時修改快速發藥機藥品數據庫和 異型包裝藥品數據庫。
（ 6）待處方被發藥窗口電腦和異型包裝電腦處理完成后，電子處方狀態顯示 已處理，同時形成處方歷史記錄表。在空閑的狀態下，藥劑師可以主動向補藥電 腦系統請求補充一些藥品儲存量不多的藥品，以備忙時之需。
3.4 下位機系統介紹
在一些大型市醫院，每天看病拿藥的病人很多，如果全部讓一個中控管理系 統處理，病人等待時間較長，導致發藥和補藥的效率比較低。為此，可以讓上位 機信息管理系統同時跟多個中控系統通信，每一個中控系統又可以同時控制多組 快速發藥機。上位機將預處理后的電子處方信息構造的指令發送給中控系統，電 子處方經過中控系統程序的處理后，發送相應的指令給下位機執行機構，下位機 執行機構完成全自動發藥或者半自動補藥流程，同時更新本地數據庫。
中控管理層的核心是 STM32 單片機，其主要功能是對上位機主控系統發送的 指令進行解析，然后驅動下位機執行系統進行發藥或補藥。快速發藥機在智能藥 房系統中屬于下位機執行機構，主要接收來自中控管理系統發送來的發藥指令， 然后執行指令操作完成發藥或補藥的過程。快速發藥機和中控管理系統組成了智 能藥房下位機系統，下位機系統示意圖如圖 3.13 所示。
圖 3.13 下位機系統示意圖
Fig 3.13 Schematic diagram of lower computer system
3.5 本章小結
本章首先簡單介紹了智能藥房快速發藥機的核心結構-藥品存儲結構，然后介 紹了上位機和下位機的總體設計，詳細詳細論述了智能藥房上位機信息管理與控 制系統各電腦的功能、上位機主控系統的功能模塊以及主控系統的工作流程，最 后簡單論述了下位機執行系統的組成以各部分的功能。
第四章 系統的設計與實現
4.1通信模塊
4.1.1 TCP/IP 網絡協議
上位機軟件系統與取藥窗口電腦以及補藥電腦之間利用藥房搭建好的內部局 域網絡進行 Socket 網絡通信。由于藥單的數據比較重要，因此網絡通信采用的是 TCP/IP 網絡通訊協議。它是一種可靠的面向連接的協議，傳輸數據安全有序可靠， 提供超時重發、丟棄重復數據、檢驗數據、流量控制等功能，保證數據能從一端 傳到另一端。TCP/IP協議簇分為四層，包含應用層，傳輸層，網際互聯層，網絡 接口層。它的參考模型如圖 4.1 所示［44-45］。
圖 4.1 TCP/IP 的參考模型
Fig 4.1 TCP/IP reference model
傳統的TCP/IP通信過程依賴于socket，位于應用層和傳輸層之間，使得應用 程序可以進行通信。服務器和客戶端各有不同的通信流程。
（1）服務端
1)建立連接階段
1.調用socket()，分配文件描述符，即監聽套接字
2.調用bind(),將套接字與本地IP地址和端口綁定
3.調用listen。，監聽特定端口，socket()創建的套接字是主動的，調用listen使 得該文件描述符為監聽套接字，變主動為被動。
4.調用accept()，阻塞等待客戶端連接
2)數據交互階段
1.調用read(),阻塞等待客戶端發送的請求，收到請求后從read()返回，處理 客戶端請求
2.調用write。，將處理結果發送給客戶端，然后繼續調用read()等待客戶端請 求
3)關閉連接
當read()返回0的時候，說明客戶端發來了 FIN數據包，即關閉連接，也會調 用close()關閉連接套接字和監聽套接字。
服務端的主要模塊如下：
namespace iwtbam {
TcpServer::TcpServer(QObject* parent):
QObject(parent)
{
}
void TcpServer::init(int port)
{
m_port = port;
m_tcpSocket = new QTcpSocket(this);
m_tcpServer = new QTcpServer(this);
newListen();
connect(m_tcpServer,SIGNAL(newConnection()),this,SLOT(acceptConnection()));
connect(m_tcpSocket,SIGNAL(error(QAbstractSocket::SocketError)),
this,SLOT(displayError(QAbstractSocket::SocketError)));
}
void TcpServer::newListen()
{ if(!m_tcpServer->listen(QHostAddress::Any, m_port))
{
qDebug()<<m_tcpServer->errorString(); m_tcpServer->close();
return;
}
}
void TcpServer::sendMsg(const QString& msg)
{
m_tcpSocket->write(msg.toLatin1());
}
void TcpServer::sendMsg(const QByteArray &msg)
{
m_tcpSocket->write(msg);
}
void TcpServer::acceptConnection()
{
m_tcpSocket=m_tcpServer->nextPendingConnection();
// m_tcpSocket->write("hello world", 10);
qDebug()<<"new connectiong";
}
void TcpServer::displayError(QAbstractSocket::SocketError)
{
qDebug()<<m_tcpSocket->errorString(); m_tcpSocket->close();
}
}
(2)客戶端
1 )建立連接階段
1.調用socket()，分配文件描述符
2.調用connect()，向服務器發送建立連接請求
2)數據交互階段
1.調用write()，將請求發送給服務器
2.調用read()，阻塞等待服務器應答
3)關閉連接
當沒有數據發送的時候，調用close()關閉連接套接字，即關閉連接，向服務 器發送 FIN 數據報。
客戶端的主要代碼如下：
namespace iwtbam {
TcpClient::TcpClient(QObject* parent):
QObject(parent)
{}
void TcpClient::init(QString ip, int port)
{
m_tcpSocket = new QTcpSocket(this); m_tcpSocket->abort();
m_tcpSocket->connectToHost(ip, port);
}
QTcpSocket* TcpClient::getTcpSocket() const
{
return m_tcpSocket;
}
TcpClient::~TcpClient（）
{
}
}
4.1.2上位機主控電腦與各電腦之間的通信數據格式
（1） 從模擬 HIS 電腦到主控電腦的通信數據格式如表 4.1 所示。
表 4.1 從模擬 HIS 電腦到主控電腦的通信數據格式
Tab 4.1 Communication data format from analog HIS computer to master computer
處方編號 處方日期 序列號 病人姓名 藥品清單 用法說明
其中藥品清單包括處方上所需藥品名稱、藥品數量及藥品生產廠商等；用法 說明主要是醫生的醫囑和服用說明。各數據段之間以“*”作為分割，數據包的結 束符定義為“#”。
（2） 從主控電腦到模擬 HIS 電腦的數據格式如表 4.2 所示。
表 4.2 從主控電腦到模擬 HIS 電腦的數據格式
Tab 4.2 Communication data format from master computer to analog HIS computer
處方編號 處方接收狀態 備注說明
處方接收狀態分三種“已接收”、“未接收”、“待接收”。已接收說明處 方有效且主控系統接收成功，未接收說明電子處方無效且主控系統拒接收，待接 收說明處方等待主控系統接收處理。
（3） 從主控電腦到發藥窗口電腦的數據格式如表 4.3 所示。
表 4.3 從主控電腦到發藥窗口電腦的數據格式
Tab 4.3 Data format from the main control computer to the drug delivery window computer
處方編號 日期 病人姓名 發藥藥品清單 備注說明
發藥藥品清單包含處方中每種藥的基本信息，如每種藥品在快速發藥機中的 具體位置以及所需盒數等。
（4） 從發藥窗口電腦到主控電腦的數據格式如表4.4所示。
表 4.4 從發藥窗口電腦到主控電腦的數據格式
Tab 4.4 Data format from the dispensing window computer to the main control computer
處方編號 處方處理狀態 備注說明
處方處理狀態包含“發藥已成功”和“待發送”這兩種狀態，主控電腦可以 實時監控各個發藥窗口電腦對處方的處理狀態，方便主控系統合理分配待處理處 方。
（5） 從主控電腦到補藥窗口電腦的數據格式如表 4.5 所示。
表 4.5 從主控電腦到補藥窗口電腦的數據格式
Tab 4.5 Data format from the master computer to the tonic window computer
補藥編號 補藥清單 備注說明
當有藥品存量不足時，主控系統會將缺藥信息匯總成補藥清單，補藥清單包 括待補充藥品名稱、藥品補充數量等。
（6） 從補藥窗口電腦到主控電腦的數據格式如表 4.6 所示。
表 4.6 從補藥窗口電腦到主控電腦的數據格式
Tab 4.6 Data format from tonic window computer to master computer
補藥編號 補藥狀態 備注說明
主控系統的補藥管理模塊可以實時查看各個補藥單的補藥狀態。
4.1.3 串口通信協議
串口是上位機計算機與單片機之間最方便、最常用的一種通信協議。串口是 計算機上一種非常通用的設備通信協議。串行接口可以接受來自CPU的并行數據 字符，并且轉換為連續的串行數據流發送出去［46］。由于有些醫院傳輸距離較遠， 因此選用 RS485 進行通信。
由于上位機與下位機之間需要通過串口進行數據交換，因此制定一套合理的 通信協議是非常必要的。
（1）發藥動作指令格式
表 4.7 發藥動作指令格式
Tab 4.7 Drug action instruction
指令
頭 發藥編 號 指令長 度 指令類 型 病人姓 名 HIS處方編
號 數據 段 校驗 位 指令
尾
1B 2B 2B 1B 2B 2B NB 1B 1B
表 4.7 為上位機發藥動作指令格式，第一行列出了指令的具體說明，第二行則 定義了對應指令的長度。 指令長度指的是整個指令所占的總字節數，配合指令頭 和指令尾共同保證完整的數據幀。指令類型表示該操作指令的意義。校驗位為數 據提供校驗功能，以防數據丟失或錯位。
數據段具體格式如表 4.8 所示。
表 4.8 數據段具體格式
Tab 4.8 Data segment specific format
藥品編號 藥品名稱 發藥數量 藥品 X 坐標 藥品Y坐標 …
6B 20B 3B 1B 1B …
數據段并不是在每個指令中都需要，但在發藥指令和補藥指令中數據段是必
須的。數據段存儲藥品的位置、名稱以及數量等。
（2）補藥動作指令格式
表 4.9 補藥動作指令格式
Tab 4.9 Supplementary drug action instruction format
指令
頭 補藥設 備編號 指令長 度 指令類 型 補藥編
號 補藥名稱 數據 段 校驗 位 指令
尾
1B 2B 2B 1B 12B 20B NB 1B 1B
表 4.9 為上位機補藥指令格式，與發藥指令相似，不同點是把處方編號換成了 補藥編號。補藥指令中的數據段格式如表 4.10 所示。
表 4.10 補藥指令中的數據段格式
Tab 4.10 The data segment format in the tonic instruction
補藥編號 補藥名稱 補藥數量 藥品X坐標 藥品Y坐標 …
12B 20B 3B 1B 1B •…
3）握手動作指令格式
表 4.11 握手動作指令格式
Tab 4.11 Handshake action instruction format
指令頭 設備編號 指令長度 指令類型 校驗位 指令尾
1B 2B 2B 1B 1B 1B
表 4.11 為握手指令格式，用于檢測上位機與下位機通信是否正常。
（4）實時監控查詢指令格式
表 4.12 實時監控查詢指令格式
Tab 4.12 Real-time monitoring of query instruction formats
指令頭 設備編號 指令長度 指令類型 備用 校驗位 指令尾
1B 2B 3B 1B 2B 1B 1B
表 4.12 為上位機查詢指令格式，相比于動作指令，由于不需要具體的藥品信 息傳輸，因此不需要數據段，保留兩個字節備用。
（5）信息反饋指令格式
表 4.13 信息反饋指令格式
Tab 4.13 Information feedback instruction format
指令頭 設備編號 指令長度 指令類型 反饋狀態 校驗位 指令尾
1B 2B 2B 1B 2B 1B 1B
表 4.13 為下位機反饋指令格式，各功能模塊采用統一反饋格式。
4.1.3 串口通信參數設置
QT 提供了 QtSerialPort 類與 QSerialPortInfo 類，該類實現串口相關操作，與 Windows的serialport類相似，其中QtSerialPort實現串口的讀寫、初始化相關操作; QSerialPortlnfo類提供相關串口信息。串口參數設置如表4.14所示。
表 4.14 串口參數設置
Tab 4.14 Serial port parameter setting
參數項 設置
波特率 9600bps
數據位 8
校驗位 None
停止位 1
端口選擇 COM2
4.2數據庫的設計與實現
4.2.1 關系數據庫選擇
結構模型中按照關系模型建立的關系數據庫是由 E.F.Codd 開發的。以往，數 據庫理論上的工作探索是很少的［47］，關系方法的建立加速了關系數據庫的發展。 與其他類型數據庫相比，關系數據庫擁有靈活模型，獨立的數據，語言接口良好， 理論基礎堅實的特點，因此關系數據庫在數據庫系統中是最受歡迎的［48-49］。
常用的關系數據庫的特點和使用場合如表 4.15 所示:
表 4.15 常用的關系數據庫的特點和使用場合
Tab 4.15 Commonly used relational database features and use occasions
特性 Oracle 數據庫 SqlServer 數據庫 Mysql 數據庫 Access 數據庫
數據存儲量在
大型或超大型數 100M以下，
中型數據存儲
數據存儲量 據存儲量，通常 小型數據存儲量 100M以上易岀
量，通常數據存
數據存儲4G以 現服務器假死現
儲量在4G以下
上 象
開源數據庫平
支持多種操作系 支持 Window 操 支持 Window 操
操作系統支持 臺，支持多種操
統 作系統 作系統
作系統
使用成本 高 較高 免費 較低
大型企業和國家 中小型企業和單
使用場合 中小型企業 小型企業
重要機關單位 位
根據本課題的實際需求，分析比較上述數據庫平臺，數據庫平臺選擇 SQL
Server 系列數據庫，其擁有 SQL Server2000、SQL Server2005 和 SQL Server2008 數據庫。SQL Server2000數據庫的數據輸入輸出速率慢、數量少，性能最差，而 SQL Server2008性能最好。本課題選用SQL Server2008為平臺，此平臺訪問方式 多樣，用戶能夠直接登入系統，也可以遠程訪問，其運行過程中的數據都能夠在 數據庫中存儲，而且其數據能夠程序更新。
4.2.2 數據庫字典建立
數據庫字典的建立是數據庫設計過程中非常重要的一個環節，即數據庫的邏 輯結構設計。要實現數據庫的邏輯結構設計，必不可少的就是各種信息表的設計， 根據系統的詳細需求分析，智能藥房數據庫字典應主要包含用戶信息表、HIS詳細 處方表、藥品信息表、藥品庫存表、藥品生產廠商表、藥品詳細清單表、待補充 藥品信息表、病人掛號表等幾十個表。根據第二章建立的 E-R 模型，可以方便地 畫出每個實體的E-R圖，然后再根據E-R圖可以快速建立每個實體的結構表，以 下只重點闡述幾個比較重要實體的結構設計表。
（1）用戶信息表的結構設計如表4.15所示
表 4.16 用戶信息表
Tab 4.16 User information table
列名 數據類型 字段長度 是否主鍵 允許 Null
用戶賬號 Varchar 10 是 否
用戶名 Varchar 20 否 是
用戶密碼 Varchar 20 否 是
用戶權限 Int 4 否 是
2）HIS 詳細處方表結構設計如表 4.17 所示
表 4.17 HIS 詳細處方表
Tab 4.17 HIS detailed prescription table
列名 數據類型 字段長度 是否主鍵 允許 Null
處方編號 Varchar 30 是 否
藥品編號 Varchar 30 是 否
藥品名稱 Varchar 30 否 是
發藥數量 Int 4 否 是
發藥狀態 Varchar 30 否 是
病人姓名 Varchar 20 否 是
（3）藥品信息表結構設計如表 4.18 所示
表 4.18 品信息表
Tab 4. 18 Drug information table
列名 數據類型 字段長度 是否主鍵 允許 Null
藥品編號 Varchar 20 是 否
藥品名稱 Varchar 20 否 是
藥品拼音碼 Varchar 100 否 是
本地規模 Varchar 20 否 是
藥品類別 Varchar 20 否 是
藥品禁忌 Varchar 50 否 是
藥品生產期 Varchar 20 否 是
藥品有效期 Varchar 20 否 是
藥品備注 Varchar 100 否 是
4）藥品庫存表結構設計如表 4.19 所示
藥品庫存表的主鍵是存儲編號，唯一的對應于快速發藥機設備或者異型包裝 藥架中的相應位置，藥品的 X 和 Y 分別代表藥品所在行和所在列，不同藥品在藥 品庫存表里的最小庫存量和最小庫存量都不同。
表 4.19 藥品庫存表
Tab 4.19 Drug stock table
列名 數據類型 字段長度 是否主鍵 允許 Null
存儲編號 Varchar 20 是 否
藥品編號 Varchar 20 否 否
藥品所在行 Varchar 20 否 是
藥品所在列 Varchar 20 否 是
最大庫存量 Int 30 否 是
最小庫存量 Int 30 否 是
5）藥品生產廠商表結構設計如表 4.20 所示
表 4.20 藥品生產廠商表
Tab 4.20 Drug manufacturer table
列名 數據類型 字段長度 是否主鍵 允許 Null
生產商編號 Varchar 20 是 否
生產商名稱 Varchar 50 否 是
生產商地址 Varchar 50 否 是
生產商電話 Varchar 20 否 是
生產商郵編 Varchar 10 否 是
生產商聯系人 Varchar 20 否 是
生產商備注 Varchar 100 否 是
6）藥品詳細清單表結構設計如表 4.21 所示
表 4.21 藥品詳細清單表
Tab 4.21 Drug detailed list
列名 數據類型 字段長度 是否主鍵 允許 Null
藥品清單編號 Varchar 20 是 否
HIS 處方編號 Varchar 20 是 否
藥品名稱 Varchar 30 否 是
藥品類別 Varchar 30 否 是
藥品數量 Int 20 否 是
藥品總價 Float 20 否 是
7）待補充藥品信息表結構設計如表4.22所示
表 4.22 待補充藥品信息表
Tab 4.22 Supplemented drug information table
列名 數據類型 字段長度 是否主鍵 允許Null
藥品編號 Varchar 20 是 否
補藥數量 Int 4 否 是
補藥狀態 Varchar 30 否 是
補藥時間 Varchar 20 否 是
補藥位置 Varchar 20 否 是
補藥備注 Varchar 50 否 是
8）病人掛號表結構設計如表 4.23 所示
表 4.23 病人掛號表
Tab 4.23 Patient registration form
列名 數據類型 字段長度 是否主鍵 允許 Null
掛號編號 Varchar 20 是 否
病人姓名 Varchar 20 否 是
病人性別 Varchar 20 否 是
病人年齡 Varchar 20 否 是
主治醫師 Varchar 20 否 是
掛號科室 Varchar 50 否 是
掛號日期 Int 20 否 是
以下列岀創建藥品信息表的 SQL 語句腳本，該表的 PRIMARY KEY 為藥品信
息：
CREATE TABLE [dbo].[medicine_info](
[medicine_no] [varchar](20) NOT NULL,
[medicine_name] [varchar](20) NULL,
[medicine_sacle] [varchar](20) NULL,
[medicine_pinyin] [varchar](100) NULL,
[medicine_categroy] [varchar](20) NULL,
[medicine_production_date] [varchar](20) NULL,
[medicine_term_validity] [varchar](20) NULL,
[medicine_taboo] [varchar](100) NULL,
[medicine_remark] [varchar](100) NULL,
PRIMARY KEY CLUSTERED
(
[medicine_no] ASC 以下是創建用戶信息表的 SQL 語句腳本，其他表的與之類似，不再一一贅述。 CREATE TABLE [dbo].[user_info](
[user_name] [varchar](10) NOT NULL,
[user_password] [varchar](20) NOT NULL,
[user_permission] [int] NOT NULL,
[user_type] [varchar](1) NOT NULL, PRIMARY KEY CLUSTERED
[user_name] ASC
4.3上位機控制模塊的設計與實現
4.3.1模擬HIS系統
(1)處方管理模塊：模擬HIS系統要實現的最重要的功能就是編輯并發送處 方，然后上位機主控系統對從模擬 HIS 系統通過局域網接收到的處方進行處理。 系統主要包括處方管理模塊和過往記錄模塊。處方管理模塊界面信息顯示主要分 為兩大部分，上方為電子處方的詳細信息，包括處方編號，病人姓名和性別，醫 生姓名，處方日期等。在主界面的下方，顯示處方中每種藥的基本信息，包含藥 品編號，藥品名，藥品單價和藥品數量等。主界面設計如圖 4.2所示。
圖 4.2 模擬 HIS 系統主界面
Fig 4.2 Simulate the main interface of HIS system
在圖 4.2 中，最右側有三個按鈕，分別可以“保存”，“發送”或者“新建” 處方信息；在左下角也有三個按鈕，可以“添加”，“修改”或者“刪除”藥品 信息。通過“添加”按鈕，處方中相關信息都會顯示在中間藥品信息中，如圖 4.3(a) 和(b)所示。添加完處方中藥品信息后，就可以點擊“發送”按鈕發送處方給上位 機軟件系統。
病人姓名： 處方曰期：
藥物信息
藥品緘號
10001
藥品全額
300
(b)
圖 4.3 處方管理模塊
Fig 4.3 Prescription management module
(2)處方過往記錄模塊:模擬HIS系統還具有進行查看處方過往記錄的功能，
當有醫院醫生與病人對處方信息有糾紛時，可以查看過往歷史記錄，以便核對或
更正已發生的錯誤，它的界面設計如圖 4.4 所示。
Fig 4.4 Prescription history
在圖4.4中，可以選中某個處方，然后“查看”、“添加”、或者刪除處方信
息，以刪除處方編號“201800000”為例， 其結果如圖4.5所示。
(b)
圖 4.5 刪除處方界面
Fig 4.5 Delete prescription interface
以添加處方編號“201800002”為例，添加處方界面如圖 4.6 所示。
a)
b)
圖 4.6 添加處方界面
Fig 4.6 Add prescription interface
本模塊的主要代碼如下：
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent), ui(new Ui::MainWindow)
{
ui->setupUi(this);
this->setWindowTitle(”模擬 HIS 系統”)；
//初始化通信系統
m_server = new iwtbam::TcpServer；
m_server->init(9999)；
//初始化菜單
initMenu()；
//初始化顯示表格
initTable()；
//初始化按鈕控件
initBtns();
//初始化數據庫
initDB();
//保證數據庫處方數據表 ID 順序唯一增長
m_curAccount = 0;
m_isSave = false;
long long no = m_medDao.max()+1;
if(no<=1)
no = 2018000000;
m_curPresNo = QString::number(no);
ui->m_edtPresNo->setText(m_curPresNo); ui->m_edtPresAcount->setText(QString::number(m_curAccount)); ui->stackedWidget->setCurrentIndex(0);
ui->m_edtPresDate->setDateTime(QDateTime::currentDateTime());
}
4.3.2 主控模塊
(1)用戶登錄界面
當用戶需要使用系統時，需要輸入正確的用戶名“admin”和正確的密碼“root”
才能登錄到主界面。登錄界面如圖 4.7 所示。
圖 4.7 用戶登錄界面
Fig 4.7 User login interface
當用戶名或者密碼有一個是錯誤的時候，會提示“密碼或用戶名錯誤”，當 連續3 次以上錯誤時，系統會自動鎖定界面，需要管理員開放權限方能進入到系 統，登錄結果如圖 4.8 所示。
圖 4.8 登錄結果
Fig 4.8 Login results 本模塊的主要代碼如下：
void LoginWindow::login()
{
qDebug()<<"login\n"；
//獲得輸入的密碼和用戶名
QString username = ui->m_editUser->text()；
QString password = ui->m_editPass->text()； //獲取數據庫中存儲的密碼和用戶名
QSqlQuery query；
query.prepare("select user_password, user_permission from user_info where user_name=:0")；
query.bindValue(":0",username)； query.exec()； //循環比對，查看輸入的用戶名是否存在，相應的密碼是否正確， 不存 在或者不正確進行提醒
if(query.next())
{
QString temp = query.value(0).toString();
if(temp == password)
{
m_mw = new MainWindow(query.value(1).toInt()); qDebug()<<query.value(1).toInt();
m_mw->show();
hide();
return;
}
QMessageBox::information(this,"登錄失敗"，”密碼或用戶名錯誤 ",QMessageBox::Cancel);
}
else
{
qDebug()<<"error";
QMessageBox::information(this,"登錄失敗"，”密碼或用戶名錯誤 ",QMessageBox::Cancel);
}
(2)處方收發模塊
當用戶輸入正確的賬號和密碼后，就能進入到如圖 4.9 所示的界面，可以監控 下位機執行系統的運行狀態和處方處理狀態。
圖 4.9 處方收發模塊主界面
Fig 4.9 Main interface of prescription transceiver module
在圖 4.9 中，主控系統在與下位機、補藥窗口、人工取藥窗口等完成通信后， 點擊開始發藥后，系統會接收來自模擬HIS系統的處方，并對處方進行處理，處 理后的結果如圖 4.10 所示。
圖 4.10 處方處理結果
Fig 4.10 Prescription treatment results
本模塊的主要代碼如下：
void MainWindow::readHisData()
{
//從與 HIS 系統建立的 TCP 鏈接獲取實時發過來字節數據
QByteArray buffer = m_hisSock->readAll();
qDebug()<<buffer.size();
if(!buffer.isEmpty())
{ //解析字節數據，獲取處方信息
QDataStream in(&buffer,QIODevice::ReadOnly);
PresInfo info;
in >> info;
//出處方中，循環訪問其中的每一個藥劑，添加到發藥的序列中
for(int i = 0;i<info.m_medicineInfo.size();i++)
{
QStringList curMedicine = info.m_medicineInfo.at(i); qDebug()<<curMedicine;
DeliveryMedicineInfoDao dao;
QString id = QString::number(dao.max() + 1);
QStringList dataList2 ={id,
info.m_basicInfo.at(0),
info.m_basicInfo.at(4),
info.m_basicInfo.at(5),
curMedicine.at(0),
curMedicine.at(1),
curMedicine.at(3),
"待發送",
info.m_basicInfo.at(1)};
QStringList dataList = {id,
info.m_basicInfo.at(0),
info.m_basicInfo.at(1),
curMedicine.at(0),
curMedicine.at(1),
curMedicine.at(3),
"待發送"};
QStringList info2; m_otherDao.look(curMedicine.at(0),info2); qDebug()<<curMedicine.at(0);
//對于處方中的藥品進行檢查，針劑型藥品進行手動取藥，盒裝的進行自動抓藥
if(info2.size()>0 && info2.at(1)=="針劑")
{
dataList [ 6]="手動取藥"； dataList2[7]="手動取藥"； qFetch.append(id)；
}
else
{
qSend.push_back(id)；
}
dao.add(dataList2)； if(!ui->m_comboFliter->currentIndex()||ui->m_comboFliter->currentText()==dataList[6 ])
{ iwtbam::insertDataToTable((QStandardItemModel*)ui->m_tableData->model(),dataLis t)；
}
m_db.commit()； qDebug()<<dataList2；
}
}
else
{
qDebug()<<"read empty!"；
}
（3）處方記錄模塊 處方記錄模塊主要記錄之前處理過的處方信息，如圖 4.11 所示。
圖 4.11 處方記錄模塊主界面
Fig 4.11 Main interface of prescription record module
在圖 4.11 中，選中某一行或者幾行處方，以處方編號“201800000”為例，點 擊“刪除”或“重新發藥”按鈕，結果分別如圖4.12和圖 4.13 所示。
啊 處方記錄 X
爭信息▼ 序列號
100001 出發編號
2018000002 病人姓名 病人•性別
男 藥物名稱
10004 藥物編號 藥物數量八
100002 2018000002 男 10003 C 1
100003 2018000002 男 10004 d 4
100004 2018000002 男 10003 C 1
100005 2018000002 男 10004 d 4
100006 2018000002 男 10003 c 1
100007 2018000002 男 10004 d 4
100008 2018000002 男 10003 c 1
100009 2018000002 男 10004 d 4
100010 2018000002 男 10003 c 1
100012 2018000002 男 10003 c 1
100013 2018000002 男 10004 d 4
100014 2018000000 男 10001 a 10
100016 2018000000 男 10001 a 10
1刪 除1
重新發藥 100017 2018000000 李四 男 10001 a 5
100018 2018000000 李四 男 10002 b 3 v
<■ >
圖 4.12 刪除處方記錄
Fig 4.12 Deletion of prescription records
圖 4.13 重新發藥
Fig 4.13 Readministration
本模塊的主要代碼如下：
void MainWindow::deliveryInfoFliter(QString status)
{
DeliveryMedicineInfoDao dao；
QList<QStringList> infos； if(status=="全部信息")
{
dao.fetch(0,infos)；
}
else
{
dao.fetch(0,status,infos)；
}
qDebug()<<infos；
QStringList headerLabels；
headerLabels <<"序列號"<<"處方編號"<<"病人姓名"<<"病人性別"<<"藥物名 稱"<<"藥物編號"<<"藥物數量"<<"發送狀態"<<"發送日期"；
//設置表格屬性，標題
QStandardItemModel* model =
(QStandardItemModel*)ui->m_tableData2->model();
model->clear();
model->setHorizontalHeaderLabels(headerLabels);
for(int i = 0;i<infos.size();i++)
{
//根據設置的篩選屬性往表中插入相應的處方記錄數據
iwtbam::insertDataToTable(model,infos.at(i));
}
}
4)藥品信息管理界面
本地數據模塊主要包括藥品信息管理模塊和用戶信息管理模塊，可以分別對
藥品和用戶信息進行增加、修改、刪除等操作。藥品信息管理界面如圖 4.14 所示。
圖 4.14 藥品信息管理界面
Fig 4.14 Drug information management interface
本模塊的主要代碼如下：
void MainWindow::del2()
{
QSqlTableModel *pMode = dynamic_cast<QSqlTableModel *>(ui->m_tableData3->model());
〃確定選中的數據在數據庫中的ID號
int row = ui->m_tableData3->currentIndex().row();
//檢查是否有行被選中
if(row<0)
{
QMessageBox::information(this,"提示"，”請選中一行！ ",QMessageBox::Yes|QMessageBox::No);
return;
}
//在表格和數據庫中同時刪除對應數據 pMode->removeRow(ui->m_tableData3->currentIndex().row()); pMode->submitAll();
}
(5)用戶信息管理模塊 用戶信息管理模塊功能跟藥品信息管理模塊類似，可以添加、刪除用戶信息。 用戶信息管理界面如圖 4.15 所示。
圖 4.15 用戶信息管理界面
Fig 4. 15 User information management interface
6）補藥管理模塊
補藥管理界面主要用來顯示補藥請求序列，補藥界面設計如圖 4.16 所示。 在輸入補藥編號后，可以查詢需要補充的藥品的基本信息，補藥信息核對界面設 計如圖 4.17 所示。
畫補藥模塊
圖 4.16 補藥界面設計
Fig 4.16 Tonic interface design
r 補藥信息核對
補藥編號：|1前帥40：3 |
確走
圖 4.17 補藥信息核對界面
Fig 4.17 Tonic information checking interface
在圖 4.17 中，主要顯示補藥編號為的藥品詳細信息，包括存儲編號、藥品編 號、藥品名稱、藥品類別等。當補藥藥劑師對補藥信息確認無誤后，開始補藥操 作。當補藥動作完成后，可以點擊確認按鈕，補藥信息被保存至相應的數據庫中， 同時向主控系統反饋補藥信息的完成。
（7）系統管理模塊
1）通信參數設置模塊
由于上位機主控系統與模擬HIS系統、下位機發藥系統、補藥系統、人工取 藥系統通過TCP/IP通信，與下位機進行串口通信。TCP/IP通信進行IP地址、端 口號的設置。在串口通信前，需要進行參數設置，在QT Creator的編譯環境下， 通過QtSerialPort與QSerialPortInfo的控件，設置的主要參數有端口號、波特率、 校驗位和停止位等，如圖 4.18 所示。
圖 4.18 通信參數設置模塊
Fig4.18 Communication parameter setting module 本模塊的主要代碼如下：
void MainWindow::saveSettings()
{ //加載本地配置文件，如果存在加載，不存在新建
QSettings settings("drug.ini",QSettings::IniFormat);
//通過配置文件，設置與不同模塊的通信設置 settings.setValue("his/ip",ui->m_hisIp->text()); settings.setValue("his/port",ui->m_hisPort->text()); settings.setValue("fetch/ip",ui->m_fetchIp->text()); settings.setValue("fetch/port",ui->m_fetchPort->text()); settings.setValue("supply/ip",ui->m_supplyIp->text()); settings.setValue("supply/port",ui->m_supplyPort->text()); settings.setValue("serial/BaudRate",ui->m_serialBaud->currentText()); settings.setValue("serial/Com",ui->m_serialPort->currentText()); settings.setValue("serial/Parity",ui->m_serialParity->currentIndex()); settings.setValue("serial/StopBits",ui->m_stopBits->currentText());
}
2)系統日志模塊
為了方便用戶更好地監控系統的通訊情況、系統運行狀態以及處方藥單處理 狀態，設計了如下圖所示的系統日志模塊。系統日志模塊主要分為三個模塊，在 每個模塊的最下面設置了三個按鈕，分別可以查看、清除和保存相應的日志模塊。 通訊模塊記錄了當前日期的與醫院HIS系統以及下位機之間的通訊情況，若系統 通訊異常，用戶人員可通過界面查看過往時間的異常情況，方便維護人員對系統 進行維護。異常日志模塊記錄了當前系統運行狀態以及過往日期的運行狀態。藥 單日志模塊記錄接收下位機反饋的發藥藥單和補藥藥單的處理狀態，方便醫護人 員及時查看。需要對各個日志模塊的歷史記錄清除時，可以點擊清除按鈕進行一 鍵清除操作。系統日志模塊的設計如圖 4.19 所示。
圖 4.19 系統日志模塊
Fig 4.19 System log module
4.3.3 人工發藥模塊
異型包裝藥需要提示人工進行取藥發藥動作，藥劑師登錄系統進入到主界面
如圖4.20所示。
fiC MainWindow — 口 X
取藥管理
1未取藥 T 1 取藥序列
21 藥物輪號
10004 藥物名稱 藥物數呈 取藥狀態
藥
2 24 10004 C 2 藥
3 25 10004 d 2 藥
4 26 10002 b 3 藥
5 27 10004 c 2 藥
6 28 10002 b 3 藥
7 29 10004 c 2 藥
8 31 10004 c 2 藥
9 32 10002 b 3 藥
10 33 10004 c 2 藥
確定
取消
刪除 11 34 10004 c 2 藥
圖 4.20 人工發藥模塊主界面
Fig 4.20 Main interface of the human development drug module
在圖 4.20 中，藥劑師可以根據未取藥序列依次人工取藥。以取藥序列“28” 為例，人工取藥操作結果如下圖 4.21 所示。
Bl MainWindow
取藥管理
圖 4.21 人工取藥
Fig 4.21 Manual dosing
本模塊的主要代碼如下：
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
//初始化網絡
initNetwork();
//初始化數據庫 initDB(); //初始化菜單 initMenu(); //初始化控件
initContorls();
4.3.4 補藥模塊
補藥模塊的主要功能是在快速發藥機數據庫和異型包裝藥數據庫缺藥時，與 智能藥房上位機系統通信獲取需要補藥的信息，主要包括待補充藥品的數量和種 類，補藥藥劑師可以根據補藥隊列的提示進行補藥，如果補藥動作完成，則要反 饋信息給主控系統，以便系統能及時更改數據庫中的相關信息。藥劑師也可以不 定期通過主動訪問藥品歷史記錄進行主動補藥的動作。
上位機軟件會根據數據庫中各種藥品數量的歷史數據記錄自動生成不同藥品 的數量下限值（提示補藥的數量下限值），此下限值會根據該藥品近期的使用情 況智能調節，近期使用量越大，下限值就會越高，相反，下限值會降低；同時上 位機軟件根據藥品數量下限值自動生成缺藥藥品的信息，當某儲藥槽的藥品數量 低于下限值時，下位機會將信息反饋給上位機信息管理與控制軟件系統，在上位 機信息管理與控制軟件系統的界面上會顯示需要補藥的儲藥槽編號以及需要補充 的藥品數量，方便藥房藥劑師管理和維護［50］。
補藥電腦客戶端是藥房工作人員與軟件系統進行交互的接口，在上位機軟件 系統發送補藥指令給補藥系統后，界面上會顯示需要補充的藥品種類、藥品數量 補藥編號等。補藥模塊主界面如圖 4.22 所示。
El補藥房 - □ x
補藥管理
補藥序列 藥物編號 藥物名稱 藥物數量 補藥時間
19 10003 d 1 2018/08/11 1... 須
210 10001 a 5 2018/08/11 1... 須
圖 4.22 補藥模塊主界面
Fig 4.22 Main interface of tonic module
4.4補藥控制系統硬件設計
4.4.1 補藥控制系統概述
補藥控制系統分為盒裝藥補藥和異型包裝補藥兩個部分。盒裝藥存放在快速 發藥機的儲藥槽里，異型包裝藥由于種類和數量較少，最主要的是包裝尺寸和風 格相差過大，因此存放在一個個藥架上，在藥架旁電腦旁運行著上位機信息管理 軟件的補藥模塊，界面上會顯示需要人工補藥的異型包裝藥，藥劑師根據提示需 人工補充藥品，這塊內容相對來說比較簡單，容易實現，本文就不進行贅述。
為了測試上位機信息管理系統的可靠性與完整性，本文將搭建一個簡易的下 位機執行系統的環境。下面將主要介紹盒裝藥補藥的工作過程及實現原理，其工 作原理如下：在儲藥槽內部均安裝的有檢測溫度和質量的傳感器，傳感器將采集 到的溫度和質量信息傳遞給STM32F103單片機，STM32F103單片機接收并處理 這些數據信息，并通過串口通信方式將信息傳輸到電腦端，電腦端的上位機信息 管理軟件系統接收這些數據，在對信息進行處理以后會自動將有效信息保存到本 地數據庫［51-53］。根據系統的工作過程及系統的具體需求分析，補藥控制系統通過 RS485 的通信方式接收上位機信息管理系統發來的指令信息，補藥控制系統功能 模塊組成如圖4.23所示，主要包括通信模塊，主控制器模塊，數據存儲模塊，液 晶 LCD 顯示模塊，稱重傳感器和溫度傳感器模塊。
圖 4.23 補藥控制系統功能模塊組成如圖
Fig 4.23 Composition diagram of functional module of tonic control system
4.4.2 主控制器模塊
（1）STM32F103ZET6 單片機介紹
主控模塊米用的是STM32F103型號的單片機，STM32F103是STM32系列的 增強型芯片，工作頻率為72MHz。支持CAN接口、USB2.0接口和SDIO接口［54］。 STM32F103ZET6 還具備以下優點：
1） 優異的實時性能。所有的引腳都可以作為中斷輸入。
2） 具有兩個看門狗電路。在系統突然出現意外時，可防止死機。
3） 功耗比較低。 STM32 各個外設都有自己的獨立時鐘開關，可以通過關閉相 應外設的時鐘來降低功耗。
4） 性價比高，成本低廉［55］。負擔 16 位機的費用可以使用 32 位機的性能，使 得 STM32F103ZET6 在 32 位機中備受歡迎；
Fig 4.24 STM32F103ZET6 single-chip microcomputer
（2）電源模塊設計
STM32F103VET6使用單電源供電，工作電壓范圍為2.0-3.6V，可以通過內部 的電壓調整給 Cortex-M3 內核提供 1.8V 的電壓。其電源電路如圖 4.25 所示，其中 AMS1117 是 3.3V 穩壓芯片。
圖 4.25 單片機電源電路圖
Fig 4.25MCU power circuit diagram
4.4.3 傳感器模塊
市場上各種各樣的傳感器很多，即使測量相同的物理量也可以選用不同類型 的傳感器。選用傳感器應該考慮的條件很多，有時不一定要求非要滿足所有要求， 主要應從以下幾個方面考慮：測量精度、反應速度、測量范圍、穩定性、抗干擾 性、可靠性、補償和校正功能等。
(1)壓力傳感器模塊
壓力傳感器中最常用的就是電阻應變式傳感器。電阻應變式傳感器具有價格 低廉、耐用性好、結構簡單、反應靈敏和適應極端天氣等特點［56］，電阻應變式傳 感器還可以測量多個物理量，因而電阻應變式傳感器應用范圍廣，雖說有各種各 樣的傳感器涌入市場，電阻應變式傳感器仍然占有一定的地位。綜合各方面考慮， 對于藥品質量信息的采集，本系統采用電阻應變式壓力傳感器。
(2)溫度傳感器模塊
對于儲藥槽溫度信息的采集，本系統采用DS18B20溫度傳感器。溫度測量模 塊采用DS18B20數字溫度傳感器，該傳感器是美國DALLAS公司生產的“一線總 線”接口的數字溫度傳感器，與傳統的測量溫度的傳感器相比，它結構簡單，其 測量溫度范圍為從零下55到零上125°C，測量精度為±0.5°C。為了使系統的抗干 擾性較強，DS18B20對測量的溫度直接以“一線總線”的數字方式傳輸［57］°DS18B20 傳感器對被測物的溫度讀取方法比較簡單，只需要數行代碼程序就能實現。該溫 度傳感器的工作電壓較低，通常在 4 V 左右。
DS18B20傳感器與單片機的連接電路如圖4.26所示，其中DS18B20的信號線 與單片機的PG11引腳連接。DS18B20傳感器實物圖如圖4.27所示。
圖 4.26 DS18B20 與單片機連接電路圖
Fig 4.26 Circuit diagram of the connection between DS18B20 and MCU
圖 4.27 DS18B20 實物圖
Fig 4.27 Physical picture of DS18B20
4.4.4 A/D 轉換模塊
STM32內部本身也帶有A/D轉換器，但是精度比較低，不滿足本系統對精度 的要求。所以選用HX711轉換芯片來達到高精度的要求。HX711芯片是24位高 精度的 A/D 轉換器芯片，是一款專為高精度電子稱而設計的芯片，具有兩路模擬 通道輸入，測量質量可精確到克［58］。稱重傳感器檢測被測重力，傳感器檢測到的 信號傳遞到HX711內部輸入多路選擇器，根據需求將信息輸入內部集成128倍增 益可編程放大器進行放大，然后將信號經過模擬數字轉換器（ADC）轉換成24位 的數字信號，STM32單片機讀取這些信號，并將信息顯示在液晶屏上。其電路參 考圖如圖4.28所示，其中HX711芯片的時鐘和數據管腳分別連接單片機的PB7、 PB6 引腳。
Fig 4.28 HX711 chip connection circuit diagram
4.4.5 LCD 液晶顯示模塊
為了使傳感器測量得到的信息供藥劑師查看，要選用合適的 LCD 液晶顯示屏。 本系統米用 3.5 寸屏薄膜晶體管液晶顯示器，即 TFT-LCD[59]。 TFT-LCD 是微電子 技術與液晶顯示技術巧妙結合的一種技術。 TFT-LCD 顯示屏具有較高的分辨率、 自帶觸摸屏、亮度高、 16 位真彩顯示、工藝簡單、成本低、且該模塊支持 65K 色 顯示，接口為 16 位的 80 并口等特點。在實際應用中，可以選擇更大的顯示屏。 TFT-LCD與其他液晶顯示不同的是，它的結構內部有獨特的薄膜晶體（TFT）材
料，在液晶顯示模塊處于非聯通的狀態時，可以避免串擾的麻煩，使顯示液晶屏 的靜態特性不受掃描線數的影響，因此 TFT-LCD 的圖像質量特別高。該液晶屏外 觀如圖 4.29 所示。屏幕主要用來顯示日期、藥品名稱、數量和藥箱溫度等信息。
此模塊的液晶顯示如圖 4.30 所示。
4.4.6 RS485 通訊模塊
本系統 RS485 模塊采用 SP3485 作為收發器，該芯片支持 3.3V 供電，最大傳 輸速度可達10Mbps，支持多達32個節點，并且有輸出短路保護。
單片機和上位機間采用 RS485 通信方式， RS485 接口是采用平衡驅動器和差 分接收器的傳輸方式，其特點是接口電平低，不易損壞芯片，傳輸速率高，傳輸 距離遠(能夠實現1200米的遠距離通信) ，支持節點多，抗干擾能力強等［60］。通 訊接口電路負責將數據上傳至上位機和接收上位機傳來的數據，通訊接口模塊電 路如圖 4.31 所示。
圖 4.31 RS485 通信模塊電路圖
Fig 4.31 RS485 communication module circuit diagram
4.5 本章小結
在 QT Creator 開發平臺下，使用其常用控件來實現智能藥房信息管理與控制 系統的功能模塊，包括通信模塊、數據庫模塊和控制模塊，以及交互式界面的建 立。通信模塊可以實現智能藥房信息管理系統內的不同電腦之間的通信，還可以 實現與下位機執行系統(STM32)的通信。數據庫模塊是在SQL Server 2008關系型 數據庫的基礎上進行數據庫建表。控制模塊是智能藥房信息管理系統的核心模塊， 包括主控模塊、接口模塊、人工發藥模塊和補藥模塊等，接口模塊主要是用來與 醫院信息管理系統對接，接收并判斷是否為有效電子處方。主要介紹了各模塊能 實現的功能及其界面設計。最后，對補藥控制系統的硬件系統進行設計，搭建了 簡易的下位機補藥執行系統，以供第五章測試系統使用。
第五章 系統測試
5.1軟件測試概述
隨著科學技術的快速發展，軟件的開發與使用在人類的社會生活中越來越多。 但再復雜的軟件也是由人主導開發設計的，往往越復雜龐大的軟件工程，出錯的 概率越大。軟件中出現的問題有時候會給使用者帶來很大的經濟損失，嚴重的甚 至會導致一個企業或公司的破產，因此，軟件測試的意義重大。測試的目的就是 在軟件投入使用之前，對軟件的功能進行全面地測試，查找是否存在一些在軟件 開發時開發者沒有注意到的問題或漏洞［61］。一般測試者都會設計一部分測試用例， 先后將這些用例用到程序中，檢驗程序的問題［62-63］。任何一個測試都要有測試計 劃、測試用例設計、測試執行以及測試結果的分析與評估［64-65］。成功的軟件測試 是能夠發現之前一直未能發現的問題，從而達到優化軟件的目的［66］。
從是否需要執行程序的角度，可將軟件測試分為靜態測試和動態測試［67］。靜 態測試就是開發人員不需要運行程序，而只是主要通過檢查軟件的代碼查看軟件 的錯誤，靜態測試能檢查出很多比較簡單的錯誤［68］。動態測試就需要測試人員設 計相應的測試用例運行程序來檢查程序中可能會出現的問題。從是否針對軟件系 統內部結構以及算法實現的角度，軟件測試可以分為黑盒測試和白盒測試［69］。
軟件測試的步驟如下：
(1)單元測試
軟件一般都是由若干個模塊組成的，在每一個模塊的代碼完成之后，分別對 每個模塊進行測試的過程稱為單元測試。單元測試側重于軟件代碼的邏輯性及軟 件代碼的規范性。
(2)集成測試
軟件的各個模塊在完成單元測試后，需要將這些模塊整合在一起測試，這個 過程稱為集成測試。集成測試能發現單元測試不能發現的問題和錯誤，這是因為 單個模塊可能不需要考慮到與其他模塊的相配情況，單個模塊可能都能滿足功能 需求，但把它們放在一起可能就會達不到預期的效果。
(3)確認測試
軟件的設計開發最終是為用戶開發、供用戶使用的。因此，是否滿足用戶需 求是判斷一個軟件好壞的關鍵。在軟件通過單元測試和集成測試后，需要測試軟 件是否完全能夠實現用戶的需求功能。
(4)系統測試
系統測試是將上位機軟件系統、下位機執行系統等綜合進行測試，其目的是 檢驗軟件系統是否滿足功能需求。
5.2 測試環境搭建
5.2.1 數據庫配置
( 1) SQL Server2008 配置
由于系統需要與數據庫交互，因此需要對 SQL Server2008 進行配置。選擇 SQL Server2008 配置工具，然后選擇外圍應用配置器，進入窗口模式。選擇服務和連接 的外圍應用配置器，將所有服務器的遠程連接設置為本地連接和遠程連接并且同 時使用 TCP/IP 和 namepipes。
( 2 )初始化文件設置
因為系統初始化需要讀取初始化文件Config.ini，所以需要對初始化文件進行 參數設置。將文件中的 SQL Server 字段內容修改為 ADOMainControl=Provider. Password=root;User ID=sa;Initial Catalog=MainControl。
其中 ADOMainControl 后面的字符串為系統 ADO 控件的連接屬性， Provider 為指定連接的提供者， Password 為連接的密碼， User ID 為登錄的用戶名， Initial Catalog 為連接的數據源名。
(3) ODBC 數據源配置，選擇 ODBC 程序,選擇添加新的數據源，添加 SQL server 驅動，為新的數據源進行參數的配置，通信，登錄設置等。
( 4)測試連接，保證 QT 程序可以 SQL server 成功通信。
利用數據源 ODBC 管理器對數據庫進行配置，這種方法是最常用的配置數據 庫的方法。其相關代碼如下：
db = QSqlDatabase::addDatabase("QODBC");
qDebug()<<"ODBC driver:"<<db.isValid();
db.setHostName("127.0.0.1");
QString dsn = QString::fromLocal8Bit("QODBC");主機名稱
db.setDatabaseName(dsn);數據庫名稱
db.setUserName("sa");賬號名稱
db.setPassword("116171");賬號密碼 對數據庫連接狀態進行檢查
if(!db.open())
{
qDebug()<<"open fail";
else
{
qDebug()<<"open success";
}
return db.open();
}
5.2.2 模擬環境搭建
(1)模擬HIS系統
在項目測試階段，沒有與具體的醫院HIS接口系統對接，但為了測試系統的 功能的完整性和軟件的流暢性，設計出了一個簡單的可以編輯電子處方的系統， 即模擬HIS系統，系統主界面如圖5.1所示。
E模擬HIS縈統
trara過ae錄
基本信息
圖 5.1 模擬 HIS 系統主界面
Fig 5.1 Simulate the main interface of HIS system
(2)模擬下位機發藥系統 模擬下位機的主要目的是實現與上位機(信息管理與控制系統)實現交互，
以數據傳輸方式向上位機反饋信息。模擬的下位機發藥系統與上位機系統的串口 通信采用了虛擬串口(Virtual Serial Port Driver )，簡稱VSPD,如圖5.2所示，將虛擬 COM1 與 COM1 相連接。
圖 5.2VSPD 串口模擬
Fig 5.2 VSPD serial port simulation
模擬下位機發藥系統主要完成發藥反饋、查詢反饋等，采用串口調試軟件
SSCOM 配合 VSPD 實現發藥反饋完成的結果如圖 5.3 所示。
圖 5.3 發藥反饋完成
Fig5.3 Drug delivery feedback completion
在圖5.3中，將表示發藥完成的字符串輸入并發送成功后，處方的處理狀態從 “待發送”狀態變為“已成功”狀態，表示此處方發藥動作已完成。
(3)模擬下位機補藥系統
為了測試系統的完整性，上位機與下位機補藥系統采用RS485進行通信，將 指令發送至下位機補藥系統。本文以STM32作為主控制器的簡易下位機補藥執行 系統，主控制器核心板如圖5.4所示，該控制器具有以太網接口和RS485接口， 該簡易執行機構能接收來自上位機主控系統的補藥藥單，能滿足系統補藥測試的 需求。
Fig 5.4 STM32 core board
5.3 測試流程
(1) 上位機主控系統主要功能模塊測試
1)處方收發模塊 當用戶輸入正確的賬號和密碼后，就能進入到如圖5.5所示的界面，可以監控
下位機執行系統的運行狀態和處方處理狀態。
圖 5.5 處方收發模塊主界面
Fig 5.5 Main interface of prescription transceiver module
在圖 5.5 中，主控系統在與下位機、補藥窗口、人工取藥窗口等完成通信后， 點擊開始發藥后，系統會接收來自模擬 HIS 系統的處方，并對處方進行處理，處 理后的結果如圖 5.6 所示。
圖 5.6 處方處理結果
Fig 5.6 Prescription treatment results
2）處方記錄模塊
處方記錄模塊主要記錄之前處理過的處方信息，如圖 5.7 所示。
圖 5.7 處方記錄模塊主界面
Fig 5.7 Main interface of prescription record module
3）本地數據模塊 本地數據模塊主要包括用戶信息管理、藥品信息管理、病人信息管理等功能 模塊。用戶信息管理模塊主要可以查看、添加、刪除用戶信息，如圖5.8所示，點 擊保存后為系統成功添加一名管理員。
（b）
圖 5.8 添加管理員
Fig 5.8 Adding an administrator
刪除用戶以用戶名為“add”為例，刪除用戶信息如圖5.9所示。
a）
（b）
圖 5.9 刪除用戶
Fig 5.9 Delete user
藥品信息管理模塊主要可以用來查看、添加、刪除藥品信息，功能與用戶信
息管理模塊相似，所不同的是存儲的數據不同。
(2) 有效處方處理測試流程
1)信息管理與控制系統的幾個模塊分別登錄并建立通信，如圖 5.10。
圖 5.10 建立通信
Fig 5.10 Establishing communication
2)模擬HIS系統編輯并發送處方信息給主控系統，電子處方進入到待處理處 方隊列，此時主控系統顯示處方狀態為“待發送”，經初步處理，處方中有些藥 品存量低于處方上藥品需求量，主控系統向補藥系統發送補藥請求，異型包裝藥 提示“人工手動發藥”，如圖 5.11所示。
圖 5.11 人工發藥
圖 5.11 Manual delivery drugs
3）主控系統在初步分析后，發送發藥指令給下位機，藥品充足的先進行發藥
動作，利用軟件模擬下位機完成發藥，如圖 5.12 所示。
圖 5.12 發藥操作
Fig 5.12 Dispensing operation
4）有些藥本地庫存不足，無法進行發藥動作，需將補藥信息顯示在液晶 LCD 顯示屏上，提示藥劑師補藥。藥劑師補藥操作完成后，補藥序列為空，如圖 5.13 所示，在補藥完成后，需將信息反饋給上位機主控系統，以便及時更新本地數據 庫。
圖 5.13 補藥操作
Fig 5.13 Tonic operation
5.4 測試結果分析
在分別對系統的單個功能模塊測試完成后，為了測試系統功能的完整性和可 靠性，本文共測試處方共 100 個，其中有效處方 90 個，無效處方個數 10 個，經 過多次的測試完成以后，將測試結果繪制如下表 5.1 所示。
表 5.1 模塊測試
Tab 5.1 Module tests
測試內容 測試方法 預期效果 實際結果
界面顯示是否正常是
藥品信息管理 等價類劃分法 否可以正常刪除、添 測試通過
加操作等
界面顯示是否正常，
用戶信息管理 邊界值分析法 是否可以正常刪除、 測試通過
添加操作等
處方收發模塊 錯誤推測法 是否可以正常接收并 處理處方 測試通過
通信模塊 因果圖法 界面顯示是否正常，
是否可以正常通信 測試通過
補藥管理模塊 使用各類測試用例 是否可以查看補藥隊
列等 測試通過
通過表 5.1 的模塊測試說明，該系統的是功能模塊均能完成既定的功能要求， 接下來就需要測試各模塊之間能否正常通信且正常工作。測試結果如下表 5.2 所示。
表 5.2 測試結果
Tab 5.2 Test results
用例類別 個數
使用測試用例總數 100
數據庫處方獲取個數 100
發藥測試用例的個數 100
補藥測試用例的個數 20
有效處方個數 90
無效處方個數 10
正確處理用例的個數 88
完成發藥提示的個數 88
完成補藥提示的個數 17
表 5.2 測試結果分析表明，數據庫的設計不存在問題，能把電子處方信息保存 至本地數據庫。上位機信息管理與控制系統完成發藥和補藥的成功率是很高的， 基本能完成發藥和補藥的動作。但仍然有少數處方分析成功率不是很高，經過分 析得知是上位機和下位機通信出現故障，猜測是其他設備產生磁場對串口通信的 影響。因此在后續的工作過程中要加強串口通信的抗干擾性能，使系統能穩定運 行。
系統在多次測試之后仍能正常接收并處理電子處方，完成發藥和補藥流程， 說明該系統各功能模塊之間能協調工作，達到了系統的設計要求。
5.5 本章小結
本章首先介紹了軟件測試的必要性、軟件測試的方法、軟件測試的步驟等基 本概念。其次搭建簡易的測試環境，包括模擬HIS系統、下位機執行系統等。模 擬 HIS 系統的功能就是代替醫院接口系統發送和編輯處方信息，采用具有以太網 通信和串口通信接功能的 STM32 作為主控制器搭建簡易下位機執行補藥系統，再 使用黑盒測試方法來檢驗整個信息管理與控制系統，根據測試結果的分析，找出 信息管理與控制系統中未發現的程序錯誤和漏洞，優化信息管理與控制系統的穩 定性和實用性，分析現有的問題，以供后續工作的開展。經測試，智能藥房信息 管理與控制系統能實現所有功能需求。
第六章 總結與展望
6.1工作總結
本文在 QT Creator 開發平臺下，使用 SQLServer2008 數據庫，對智能藥房上 位機信息管理與控制軟件系統進行了設計，為了測試系統的功能，首先搭建模擬 HIS 系統，其次采用串口調試軟件 SSCOM 配合 VSPD 模擬下位機發藥系統，最后 以 STM32 單片機為主控制器組成一個簡易的下位機補藥執行系統，并完成了上下 位機的通信設計。本文的工作總結如下：
（1） 引入數據流分析的方法對智能藥房信息管理與控制系統進行了需求分析， 從不同角度分析了智能藥房信息管理與控制軟件系統的需求，得到了具體的用戶 需求、功能需求等。
（2） 介紹了智能藥房信息管理與控制系統的總體設計方案，包括上位機信息 管理與控制系統和下位機執行系統。主要對上位機主控系統的功能模塊進行詳細 分析，給出了上位機主控系統的工作流程。還分析了各主要模塊的功能，最后對 下位機系統功能模塊作了簡單介紹。
（3） 完成了數據庫管理系統的設計與優化。從概念模型、邏輯模型、物理模 型循序漸進對系統進行了數據庫設計，主要完成了概念模型建模（E-R建模），最后 生成實際的數據庫表，并存儲在數據庫中。
（4） 主要對信息管理系統的功能模塊進行設計。主要包括通信模塊、數據庫 模塊、上位機控制模塊和下位機補藥控制模塊硬件設計。控制模塊是系統的最核 心模塊，包括有模擬 HIS 系統模塊、主控模塊、人工發藥模塊、補藥模塊等。通 信模塊首先對上位機各電腦之間通信的數據格式進行了設計，并實現了幾個模塊 的TCP/IP通信，其次設置串口通信，完成了上位機系統與下位機系統的串口通信。 控制系統的主要功能是完成處方接收處理、處方信息存儲、發藥和補藥。
（5） 系統測試。首先設計模擬 HIS 系統和下位機執行系統，其次利用黑盒測 試方法對信息管理與控制系統的基礎功能模塊進行測試，然后對系統接收和處理 處方的功能進行多次測試，最后對比預期效果與實際結果，驗證了系統的穩定性 與可靠性。
6.2 工作展望
由于時間有限，本系統雖能完成絕大部分的功能，但仍存在一些不足與需要 補充改善的地方，結合智能藥房的發展，未來可供繼續研究的一些方向如下：
（1）簡化功能模塊的設計，這樣不僅可以提高系統的運行速度和穩定性，還
利于軟件系統的維護和優化。
（2） 優化人機交互界面的設計。在界面的外觀上要繼續美化，設計更加友好 的界面；此外，為了減輕用戶認知負擔，需要保持界面的一致性以及圖標功能的 一致性。
（3） 優化數據庫的設計。本系統數據庫只是簡單模擬了少量的醫院數據，但 在醫院工作中，內部藥品存儲數量巨大，因此后續的工作中需要完善對數據的存 儲問題。
參考文獻
[1]J.Han,M.Kamber.DataMining:ConeePtsandTeehniques[M].MorganKaufinan，San Franeiseo,2000
[2]孟國強.醫院財務管理信息化研究[學位論文].西安:第四軍醫大學，2010
⑶張永明.醫院醫藥信息管理系統[J].廣東藥學，2002,12(5):53-54
[4]楊樟衛，胡晉紅，王卓等.臨床藥學信息服務系統計算機軟件設計和應用J].中國臨床藥 學雜志， 2003,12(4):240-243
[5]龐云麗，李薔，賀建國等.我院藥品信息咨詢系統的設計與應用J].藥學實踐雜志， 2001,19(3):181-182
[6]尹華，宋慶，易曉玲等.利用醫院局域網建立藥訊網站J].中國藥房，2005,16(9):669-671
[7]趙陶麗.藥房自動化是醫院藥房發展的必然趨勢J].首都醫藥，2009,16(24):31
[8]王冬梅，唐灝江.藥房自動化是醫院藥房發展的必然趨勢[J].甘肅醫藥,2012, 31(8):615-617
叨 李成群，王偉.自動化藥房的現狀和新進展J].機器人技術與應用.2008, 15(1): 1-5
[10]Girish S. Subramanyan, Deborah S. Yokoe, Sharon Sharnprapai, Edward Nardell, Eugene McCray, Richard Platt. Using Automated Pharmacy Records to Assess the Management of Tuberculosis[J]. Emerging Infectious Disease, 1999, 5(6): 788
[11]Bridget Coleman. Hospital pharmacy staff attitudes towards atomated dispensing before and afer implementation[J]. Hosptial Pharmacy, 2001, 11: 248
[12]Mathew P. Thomas. Medication Errors[J]. Clinical Pediatrics, 2003, 4: 287
[13]Chritopher J.Thomsen.A Real Life Look at Automated Pharmacy Workflow
Systems[J].National Association of Chain Drug Stores, 2005, 1, 29
[14]http://rxinsider.com/pharmacy_automation_dispensing_technology.htm
[15]郝華增，李展翅，吳平龍，劉晏，贠超，周萬勇.智能化藥房的研究J].包裝與食品機械， 2005(5)
[16]http://www.rowa.de/
[17]陳宜彬, 曾仁杰, 景利等. 自動發藥機及信息處理系統. 中國人民解放軍成都軍區總醫 院四川大學, 中國專利: CN1102264A, 1995-05-03
[18]李伯孝. 旋轉藥盤架. 中國專利: CN2362355, 2000-02-09
[19]http://www.robopharma.com/
[20]http://www.rowa.de/fileadmin/fnes/rowa/prospekte/TopSpeed_NL.pdf
[21]李成群，王偉，負超等.自動化藥房的現狀和新進展J].機器人技術與應用，2007,(5): 27-32
[22]楊修懷.醫院藥房自動化成套設備的現狀與發展前景[[J1 .健康大視野，2012,20(10)
[23]魏宇寧，侯永春，郭代紅，等.整包裝自動發藥機應用于門診藥房的實踐與體會J].中
國藥物應用與檢測，2008, 13(5): 16-17.
[24]Jiu Wang，Yong-Yong Xu，Dan-Hong Liu. Problems and Prospects of Hospital Information System in China[J]. Journal of US-China Medical Science,2007, 6(1):67-75.
[25]周渝霞，周破，顧鳳軍.自動化藥房與醫院信息系統的連接技術J].中國數字醫學，2009, 18(2):77-80.
[26]趙新先, 徐文, 周東斌等. 中藥電子調配方法及設備. 三九醫藥股份有限公司, 中國專利: CN1240747, 2000-01-12
[27]夏作新, 李海鷗, 劉紹周.微機自動控制發藥機. 航天工業部第三研究院第三十五研究所, 中國專利: CN 86105746, 1988-02-10
[28]陳宜彬, 曾仁杰, 景利等. 自動發藥機及信息處理系統. 中國人民解放軍成都軍區總醫 院四川大學, 中國專利: CN1102264A, 1995-05-03
[29]李伯孝. 旋轉藥盤架. 中國專利: CN2362355, 2000-02-09
[30]胡乃鋼. 醫院門診藥房自動投藥機, 中國專利: CN1371076, 2002-09-25
[31]寧華，閆建民，趙金環等.全自動口服藥品擺藥機在我院藥房的應用及體會[J].中國藥 房， 2008,19(13):991-992
[32]劉生杰，郭代紅，孫艷等.全自動針劑擺藥機的引進與應用[J].中國藥物應用與監測， 2009,6(1):42-44
[33]楊東，劉妙方，譚志堅等.住院/門診整合式藥房自動化系統的設計和解決方案J].臨床 醫學工程， 2009(11):10-12
[34]白嵐，凌秀琴.數據流圖在信息處理中的應用[J]。光電技術應用，2005,20(6):64-67
[35]馮宇石.軟件缺陷的積累放大效應和軟件階段評審[J].光電技術應用，2005,20(3):70-74
[36]張燁.全球信息化給中國帶來的機遇和挑戰[C].吉林:吉林省科技情報學會2010學術年會 論文集， 2010
[37]馮爽.關于數據流程圖畫法原則的研究[J].河北科技大學學報，2012,33(04):343-346.
[38]孫錯.自動中藥房上位機軟件系統的設計與實現[D].南京理工大學，2013.
[39]薩師煊，王珊編.數據庫系統概論[M].比京:高等教育岀版社，1991.
[40]胡大權.數據庫概念模型的分析與應用[J].計算機工程與應用，2002, 7(6):73-76
[41]張金昌.數據庫概念設計方法探討[J].交通與計算機，1988, 21(3): 15-23.
[42]陳亮.貴陽市委黨校學員管理系統的分析與設計[D].云南大學，2013.
[43]趙保龍.中藥顆粒自動化藥房系統設計[D].哈爾濱工業大學，2015.
[44]任泰明.TCP/IP網絡編程[M].人民郵電岀版社，2009
[45]歐立奇，劉洋，段韜.程序員面試寶典[M].電子工業岀版社，2013:297
[46]曹衛彬.C/C++串口通信典型應用實踐編程實踐[M].北京:電子工業岀版社，2009.
[47]李湘林.關系數據庫設計的實用方法及應用[J].網絡財富，2010 7(14): 98-103
[48]李合龍，左文明，焦青松.數據庫理論與應用[M].北京：清華大學岀版社，2011.
[49]雷景生，葉文裙，李永斌.數據庫原理及應用[M].北京:清華大學岀版社，2012.
[50]蔡金川，張超，樊麗.基于ZigBee和GPRS的智能家居設計以及傳感數據基于時間序列的聚 類分析[J]新型工業化,2017,7(3):25-32.
[51]李成,王鵬,丁天懷，等.RS-485總線的高速串行遠距離數據傳輸方法[J].清華大學學報:自然 科學版,2009,49 (5):684-687.
[52]趙錫鈞.基于RS485接口的單片機串行通信[J].計算機技術，2000,9(4):56-58.
[53]王鐵流，李宗方，陳東升.基于STM32的USB數據采集模塊的設計與實現[J]測控技術, 2009,28 (8):37-40.
[54]陳玉敏，謝瑋，孟憲民.基于STM32的溫度控制實驗設計[J].現代電子技術,2016,39 (12) :37 -40.
[55]STM32F103xxx User's Manual, STMicroelectronics, 2010.
[56]潘學軍.應變式非平衡電橋與電子秤J].四川師范大學學報(自然科學版),2000, 23 (1): 75-78.
[57]湯錯杰，栗燦，王迪，等.基于DS18B20的數字式溫度采集報警系統設計[J].傳感器與微系 統,2014,33(3):99-102.
[58]吳家平，沈建華.基于STM32微控制器的過采樣技術研究與實現[J].計算機技術與發展, 2010,1(2):209-212.
[59]湯莉莉，黃偉.基于STM32的FSMC接口驅動TFT彩屏設計[J].現代電子技 術,2013 ,3(20) :139-141.
[60]王鐵流，李宗方,陳東升.基于STM32的USB數據采集模塊的設計與實現[J].測控技 術,2009,28(8):37-40.
[61]Paul C J .軟件測試[M].北京:機械工業岀版社，2006.
[62]徐方.軟件測試技術[M].北京:機械工業岀版社，2007.
[63]Geoffey B.軟件質量的商業價格[J].IBM Developer Works,2005,3(9):12-17.
[64]滕瑋，錢萍.軟件測試技術與實踐[M].北京:機械工業岀版社，2012.
[65]秦曉.軟件測試[M].北京:科學岀版社，2008.
[66]單錦輝，姜瑛，孫萍等.軟件測試研究進展J].北京大學學報(自然科學版)，2005 41(1):134-145
[67]邱小玲.淺談軟件測試的方法[J].科技信息，2008,(17):421,428
[68]薛賽男,趙偉.軟件測試技術-計量測試技術的新領域計量技術.2003.5
[69]張新華，何永前.軟件測試方法概述[J].科技視界，2012,(4):35-37
下一篇：沒有了
相關標簽:
