3.
本章主要介紹 CAN 應用層通訊協定，並根據其架構與概念，設計出所需的 協定，以利系統之整合，且延續第二章的實驗結果，提出網路時脈同步方法，以 改善時脈漂移問題。
3-1 CAN 應用層通訊協定：CANopen [14]
3-1-1 CANopen 簡介
在CAN 原本的通訊規範中，僅包含 OSI 網路模型中的資料連結層和實體層 這兩個部份，其餘各個部份並未加以定義，因此，當使用者以 CAN 作為通訊媒 介時，便必須自行定義所使用的資料型態、高階網路行為等等規格，以OSI 模型 的角度來看，即是定義應用層(application layer)的通訊協定。然而，這卻造成系統 開發上的緩慢，且系統間缺乏共通性。因此，以CAN bus 為基礎的應用通訊協定 因應而生，其中最常見的為CANopen 和 DeviceNet，透過這些應用層協定，不同 系統間便建立了共通的通訊規範，如此一來，便可加速系統間的整合，而此處的 介紹則以CANopen 為主。
CANopen 最初同樣是由德國 Robert Bosch 所開發，在 1995 年轉由 CiA (CAN in Automation)處理發表，原先是為了機械控制所開發的網路協定，然而，近年來，
第四版的CANopen (CiA DS 301)已成為歐洲的標準規格(EN 50325-4)，使用範疇 跟著被推展到各類應用上，其主要優點在於，相較其他以 CAN 為基礎的通訊協 定除了對原先的CAN 加以修改，且採用較複雜的網路架構，以 DeviceNet 為例，
DeviceNet 修改了實體層規範，並加入了網路層(network layer)和傳輸層(transport layer)的概念，反觀 CANopen 的實現概念則較簡單而直接，並未對 CAN 原先的 規格加以修改，而是直接規劃出應用層協定，由結合前述的OSI 網路模型來看，
可得到如下圖3-1 所示，其中實體層與資料連結層如同前述的 CAN 網路架構，
empty
Application layer and communication profile CiA DS 301
Device profile CiA DS 401
Device profile CiA DS 404
Device profile CiA DSP 402
CAN
1. Physical layer 2. Data-link layer 3. Network layer 4. Transport layer 5. Session layer 6. Presentation layer 7. Application layer 8. User layer
CAN bus
empty
Application layer and communication profile CiA DS 301
Device profile CiA DS 401
Device profile CiA DS 404
Device profile CiA DSP 402
Application layer and communication profile CiA DS 301
Device profile CiA DS 401
Device profile CiA DS 404
Device profile CiA DSP 402 Device profile
CiA DS 401
Device profile CiA DS 404
Device profile CiA DSP 402
CAN
1. Physical layer 2. Data-link layer 3. Network layer 4. Transport layer 5. Session layer 6. Presentation layer 7. Application layer 8. User layer
1. Physical layer 2. Data-link layer 3. Network layer 4. Transport layer 5. Session layer 6. Presentation layer 7. Application layer 8. User layer
CAN bus CAN bus
圖3-1 CANopen OSI 網路模型
應用層(application layer)是上述的 CiA DS 301 為 CANopen 主要通訊協定，提供通 訊用物件，使用者層(user layer)則是 CANopen 依據不同應用場合，加以制定的物 件規範，而同一類型的物件集合則可稱為device profile，如 CiA DS 401 提供一般 I/O 的功能，而 CiA DS 301 則提供 CANopen 通訊物件，兩者皆屬於 CANopen 協
3-1-2 CANopen 通訊協定
在上節中，介紹了 CANopen 的 OSI 網路架構，是由網路特性加以區分，若 從物件功能的角度來看，則可以將CANopen 節點分為三個部份(如圖 3-2)：
(a) 通訊端(communication)
通訊端主要是透過底層網路架構提供網路通訊功能，達到網路傳輸與接 收訊息的目的，圖上的通訊物件可視為網路線上傳輸的訊息封包。
(b) 物件表(O.D., object dictionary)
物件表(以下簡稱 O.D.)主要是所有對通訊端和應用端物件能造成影響的 訊息封包集合，並將這些封包轉換到目的地，因此，O.D.就如同處在兩端的 介面，提供通訊端和應用端物件間的轉換機制，而圖中的每個項目(entry)即 是定義其對應關係。
(c) 應用端(application)
應用端則是負責與處理程序(process)互動，提供其所需的應用物件並將需
Entry 1 Entry 2
.. .
Entry n
Application
Communication Object
Dictionary
Application
Bus system Process
Comm.
Entry 1 Entry 2
.. .
Entry n
Application
Communication Object
Dictionary
Application
Bus system Process
圖3-2 CANopen 物件模型
由上述可知，CANopen 協定主要提供底層通訊物件和上層應用物件之間的轉 換機制(O.D.)，且對於應用物件加以規劃定義，而因應不同的物件類型，也衍生
出了各類的網路行為，底下就針對object dictionary、通訊模型和通訊物件1加以介 紹。
Object Dictionary (O.D.)
O.D.的功能在於提供物件的對應關係，實現方式類似一個預先規劃的表格，
紀錄所有使用的物件資訊，包含資料類型、通訊參數與物件定義等等。至於存取 O.D.內容的方式，則是透過 16 位元索引(index)和 8 位元的副索引(sub-index)，前 者可支援最多65536(2^16)個項目，後者則是為了存取複雜的資料型態(如：陣列) 所設計，而根據資料型態和使用目的，可分為如表3-1 中的各種類別。
0001h~001Fh 的靜態資料型態和 0020h~003F 的複合資料型態，為 CANopen 預設的資料類型，前者包含一般標準類型，如布林數、浮點數、字串等等，後者 則是根據這些基本型態所組成的複合型態，如整數(字串)陣列；0040~005F 同樣 提供標準資料類型，差異在於隨著製造商的設計而有所差異；0060~009F 的資料 類型，則隨著不同的應用場合而額外規範。以上部份為資料型態的定義。
至於通訊參數和物件定義，則由 1000~BFFF 的各個 profile 加以規範，其中 1000~1FFF 為通訊用參數設定用，即由前述之 CiA DS 301 所規範；2000~5FFF 為製造商自行定義之參數設定；6000~9FFFF 則為應用層使用的所有資料項目，
然而，不同device profile 使用在不同的應用場合，一個 device profile 便對應到一 群物件，而單一節點可能有多個應用目的，為此，CANopen 允許單一節點具有 8 個device profile，每個 profile 擁有 2048 個資料項目，所以，6000~67FF 為第一個 profile 所使用，6800~6FFF 為第二個 profile 所使用，以此類推。
1 此處的通訊物件係指應用端的通訊物件
表3-1 CANopen O.D.分類
Index( hex ) Object
0000 not used 0001~001F Static Data Types 0020~003F Complex Data Types
0040~005F Manufacturer Specific Complex Data Types 0060~007F Device Profile Specific Static Data Types 0080~009F Device Profile Specific Complex Data Types 00A0~0FFF Reserved for further use
1000~1FFF Communication Profile Area 2000~5FFF Manufacturer Specific Profile Area 6000~9FFF Standardised Device Profile Area A000~BFFF Standardised Interface Profile Area C000~FFFF Reserved for further use
以上的介紹以O.D.架構為主，至於其細部的各個項目，由於種類繁雜，
便不詳加介紹。
通訊模型(Communication Model)
CANopen 建立了應用層物件定義和其對應關係，基於這些規範而發展出各類 的通訊模型，本部份便以此為主，然而，網路與處理程序間的互動也與通訊模型 相關，因此，底下先就這部份說明，接著介紹通訊模型，以了解 CANopen 節點 的通訊形式。
根據 CANopen 所制定的規則中，可歸納出應用程序和網路應用層的溝通方 式可分為：
z 要求(request)
由應用程序發給應用層，以存取資料或要求網路服務。
z 指示(indication)
由應用層發給應用程序，表示應用層的事件觸發產生或是應用層由其他 處理程序接收到要求。
z 回覆(response)
由應用程序發出，以回覆前一個接收到的指示。
z 確認(confirmation)
由應用層發給應用程序，以回報前一個提出的要求，所得到的結果。
基 於 這 四 種 方 式 ， 則 可 將 CANopen 的通訊模型，歸納成以下三個類別：
Master/Slave、Client/Server 和 Producer/Consumer，底下就針對各個模型說明。
z Master/Slave
CANopen 架構下必定存在一 master，其餘節點則為 slave，後者的動作皆 由前者所控制，其通訊模型如圖 3-3 所示，(a)是不需經確認的方式，master 傳送資料給各個 slave 之後，slave 發出指示給應用程序且引發對應的處理機 制；(b)是必須經過確認的方式，master 傳送遙控傳輸要求(遙控欄框)，引發 slave 產生指示以及回覆，進而回傳資料到 master，並對 master 端的應用程序 回報確認結果。
(a) Unconfirmed Master/Slave model
(b) Confirmed Master/Slave model 圖3-3 Master/Slave 通訊模型
z Client/Server
Client/Server 的通訊方式類似需確認的 Master/Slave 通訊，差別為後者主
要用於讀取遠端節點的資料或狀態，而Client/Server 方式主要用於點對點之間 的大型資料寫入與讀取，因而較適用於非即時性(non-real-time)的資料傳輸，
其通訊模型如圖3-4 所示。
圖3-4 Client/Server 通訊模型
z Producer/Consumer
Producer/Consumer 的通訊方式，就如製造者與消費者的關係，單一個 producer 可對應零個或多個 consumer，其通訊方式如下圖 3-5，(a)是由 producer 主動送出資料後，而引發各個consumer 產生對應的機制，此方式稱之為 Push 模型；(b)則是由各個 consumer 透過遙控欄框，要求 producer 提供所需資料，
此方式稱之為Pull 模型。
(a) Push model
(b) Pull model
圖3-5 Producer/Consumer 通訊模型
通訊物件(Communication Object)
在通訊模型的介紹中，說明了以通訊物件發展出的三種通訊形式，然而，通 訊行為主要則是由通訊物件完成，CANopen 通訊物件是將 CAN 的訊息封包加以 分類，而每個訊息封包即為一個通訊物件，其分類方式則是將標準 CAN 格式中 的 11 位元識別碼，規劃為物件識別碼(COB-ID)，前 4 位元為功能類別(function code)，用以表示物件功能，後 7 位元為節點識別碼(Node-ID)，用以表示發送訊 息的節點，Node-ID 象徵著每個節點都有專屬的編號，因此，CANopen 網路中最 多可有128(27)個節點，而根據其功能分類，可得到如表 3-2，其中可分為一般資 料傳輸用以及系統管理用兩大類，PDO 和 SDO 主要用於資料傳輸和參數設定，
其餘各類物件則用於系統管理，在此，以前者的介紹為主。
表3-2 CANopen 通訊物件
Function code
(binary) COB-ID Communication object
0000 0 NMT Service
128(80h) SYNC Message
0001
129(81h) ~ 511(FFh) Emergency Messages
0010 256(100h) Time-Stamp Message
0011 385(181h) ~ 511(1FFh) Transmit PDO 1
0100
513(201h) ~ 639(27Fh)Receive PDO 1
0101
641(281h) ~ 767(2FFh)Transmit PDO 2
0110
769(301h) ~ 895(37Fh)Receive PDO 2
0111
897(381h) ~ 1023(3FFh)Transmit PDO 3
1000
1025(401h) ~ 1151(47Fh)Receive PDO 3
1001
1153(481h) ~ 1279(4FFh)Transmit PDO 4
1010
1281(501h) ~ 1407(57Fh)Receive PDO 4
1011
1409(581h) ~ 1535(5FFh)Transmit SDO
1100
1537(601h) ~ 1663(67Fh)Receive SDO
1110
1793(701h) ~ 1919(77Fh)NMT Error Control
圖3-6 同步與非同步傳輸方式
PDO (process data object)和 SDO (service data object)是為了資料傳輸之用，前 者主要用於即時性資料傳輸，後者則用於非即時性的參數傳遞，因此，所使用的 通訊模型也有所差異，以下則為個別說明。
z PDO
PDO 主要用於即時性資料傳遞，而其傳輸方式分為同步(synchronization) 傳輸與非同步(asynchronization)傳輸兩類，圖 3-6 為一範例，同步傳輸是基於 同步物件(SYNC object)(詳見 3-1-3 節)的發送，一旦接收到同步物件後，觸發 各個節點在預設的同步時間(synchronization window length)之內，發送同步 PDO，這樣的方式可達到節點同步的效果；而非同步性 PDO 則不需同步物件 觸發即可發送。
PDO 的類型可分為傳輸(TPDO)和接收(RPDO)兩類，TPDO 為實際用來 傳輸的物件，RPDO 則與欲接收的 TPDO 搭配，所以，對應的 TPDO 和 RPDO 具有相同的COB-ID。而由於 PDO 採用 Producer/Consumer 的通訊形式，因此，
傳 輸 TPDO 的節點稱為 PDO producer，接收 TPDO 的節點則為 PDO consumer，其通訊協定如圖 3-7 所示，其中 PDO 的傳輸資料長度和 CAN 的 資料長度相同(0~8bytes)，相對於 SDO，PDO 沒有額外的處理機制和網路負 載 ， 因 此 ， 較 適 用 於 即 時 性 資 料 的 傳 輸 。 而 寫 入 PDO 的 方 式 是 採 用 Producer/Consumer push 模型，讀取 PDO 則是採用 pull 模型。
(a) Write PDO 通訊協定
(b) Read PDO 通訊協定 圖3-7 PDO 通訊協定
z SDO
為了達到即時性傳輸，PDO 將其傳輸方式限制在一次傳輸之中，且資料 長度最多為8bytes，然而，在 O.D.的介紹中，曾提及 CANopen 所支援的資料 型態包含字串或陣列等複雜的資料型態，這些資料物件明顯無法透過PDO 的 傳輸方式完成，因此，SDO 的設計便是為了大型資料傳輸所設計，這樣的方 式必須將資料分為多筆訊息分批傳送，接著由接收端組合為完整資料，但這 樣一來，訊息之間可能因網路傳輸狀況不佳，使得接收端遲遲無法得到完整 資料，所以，SDO 並不適用於即時性資料傳遞，而是用於大型參數資料傳遞。
為了達到即時性傳輸，PDO 將其傳輸方式限制在一次傳輸之中，且資料 長度最多為8bytes，然而，在 O.D.的介紹中，曾提及 CANopen 所支援的資料 型態包含字串或陣列等複雜的資料型態，這些資料物件明顯無法透過PDO 的 傳輸方式完成，因此，SDO 的設計便是為了大型資料傳輸所設計，這樣的方 式必須將資料分為多筆訊息分批傳送，接著由接收端組合為完整資料，但這 樣一來，訊息之間可能因網路傳輸狀況不佳，使得接收端遲遲無法得到完整 資料，所以，SDO 並不適用於即時性資料傳遞，而是用於大型參數資料傳遞。