PPDAQ軟體DIP開關設定與乙太網路控制

PPDAQ 軟體的網路功能與除錯模式仰賴 Netburner 的 DIP 開關設定。DIP 開關 3 控制乙太網路的啟用與停用，開關 4 則決定最大允許連線數，設定為 ON 時允許五個連線，OFF 時僅允許一個。IP 位址設定由開關 5 和 6 控制，影響 192.168.2.70 到 192.168.2.73 範圍內的 IP 分配。程式碼中使用位元運算和函式呼叫來設定 IP 位址，並根據開關狀態啟用或停用乙太網路功能。此外，當 DIP 開關 8 處於 ON 狀態且 USB 功能未啟用時，PPDAQ 軟體會進入特殊的除錯模式，提供開發者進行系統診斷和問題排查。每個建立的乙太網路連線都會產生一個獨立的命令處理任務，確保每個連線的命令都能得到及時處理，避免互相干擾，提升系統的穩定性和效率。

PPDAQ 軟體需求規格中的乙太網路與 DIP 開關設定

乙太網路 IP 位址的 DIP 開關控制

PPDAQ 軟體的乙太網路 IP 位址可透過 Netburner 上的 DIP 開關 5 和 6 進行設定。軟體會根據這兩個開關的狀態，將 IP 位址設為 192.168.2.70 至 192.168.2.73 之間的某個值。

程式碼範例：DIP 開關設定轉換為 IP 位址

void set_ethernet_ip_address(void) {
    uint8_t dip5_status = get_dip_switch_status(5);
    uint8_t dip6_status = get_dip_switch_status(6);
    uint32_t ip_address = (192 << 24) | (168 << 16) | (2 << 8) | (70 + (dip5_status << 1) + dip6_status);
    configure_ethernet_ip(ip_address);
}

內容解密：

1. get_dip_switch_status(n) 函式用於取得 DIP 開關 n 的狀態（ON 或 OFF）。
2. 根據 DIP 開關 5 和 6 的狀態計算 IP 位址的最後一個位元組。
3. configure_ethernet_ip(ip_address) 函式用於設定乙太網路 IP 位址。

乙太網路功能的啟用與停用

PPDAQ 軟體會根據 Netburner DIP 開關 3 的狀態來決定是否啟用乙太網路功能。

程式碼範例：乙太網路功能的啟用與停用

void configure_ethernet_operation(void) {
    if (get_dip_switch_status(3) == ON) {
        enable_ethernet();
    } else {
        disable_ethernet();
    }
}

內容解密：

1. get_dip_switch_status(3) 用於取得 DIP 開關 3 的狀態。
2. 若開關為 ON，則呼叫 enable_ethernet() 函式以啟用乙太網路功能。
3. 若開關為 OFF，則呼叫 disable_ethernet() 函式以停用乙太網路功能。

乙太網路連線數量的控制

DIP 開關 4 用於控制 PPDAQ 軟體允許的乙太網路連線數量。當開關為 ON 時，軟體允許最多五個連線；當開關為 OFF 時，則只允許一個連線。

程式碼範例：乙太網路連線數量的控制

void configure_max_ethernet_connections(void) {
    if (get_dip_switch_status(4) == ON) {
        set_max_connections(5);
    } else {
        set_max_connections(1);
    }
}

內容解密：

1. get_dip_switch_status(4) 用於取得 DIP 開關 4 的狀態。
2. 若開關為 ON，則呼叫 set_max_connections(5) 以允許最多五個乙太網路連線。
3. 若開關為 OFF，則呼叫 set_max_connections(1) 以限制只允許一個乙太網路連線。

除錯模式的啟用

當 DIP 開關 8 為 ON 且 USB 未啟用時，PPDAQ 軟體會進入特殊除錯模式。

程式碼範例：除錯模式的啟用

void check_debug_mode(void) {
    if (get_dip_switch_status(8) == ON && !is_usb_enabled()) {
        enter_debug_mode();
    } else {
        operate_normal_mode();
    }
}

內容解密：

1. get_dip_switch_status(8) 用於取得 DIP 開關 8 的狀態。
2. is_usb_enabled() 用於檢查 USB 是否已啟用。
3. 若 DIP 開關 8 為 ON 且 USB 未啟用，則呼叫 enter_debug_mode() 以進入除錯模式。
4. 否則，呼叫 operate_normal_mode() 以正常模式運作。

命令處理任務的建立

對於每個乙太網路連線，PPDAQ 軟體會建立一個新的處理程式來處理命令。

程式碼範例：命令處理任務的建立

void handle_ethernet_connection(int connection_id) {
    create_command_processing_task(connection_id);
}

內容解密：

1. create_command_processing_task(connection_id) 用於為每個連線建立一個新的命令處理任務。
2. 每個任務負責處理來自特定連線的命令。

更新可追溯性矩陣與需求資訊

系統需求規格（SyRS）與軟體需求規格（SRS）通常會在可追溯性矩陣（RTM）中新增四到六個欄位，分別為：描述、SyRS標籤（如果有SyRS）、分配、SRS標籤以及測試/驗證型別。描述欄位提供對需求的簡要說明，例如DAQ_SRS_700_000中的「PPDAQ標準軟體平台」。

SyRS與SRS標籤欄位

SyRS和SRS標籤欄位包含實際的SyRS（如果存在）和SRS標籤識別碼。通常會根據SyRS（主鍵）和SRS（次鍵）對RTM中的行進行排序，除非沒有SyRS標籤，此時只需按SRS標籤排序。

分配欄位

分配欄位指定需求是硬體（H）、軟體（S）、其他（O）還是這些的組合。通常，只有SyRS需求具有純硬體分配；畢竟，SRS需求是軟體需求。然而，如果SRS需求涵蓋了系統的軟硬體方面，則可能具有HS分配。其他類別是一種概括，用於涵蓋不符合硬體或軟體類別的需求（例如手動流程）。

如果沒有SyRS，或者所有需求分配都是軟體分配，則可以省略分配欄位，以減少RTM的大小和複雜度。

驗證型別欄位

RTM中的驗證型別欄位指定了如何驗證系統中的需求。可能的條目包括：透過測試（T）；透過審查（R）；透過檢查（I；用於硬體設計的「透過審查」變體）；透過設計（D；通常適用於硬體，而非軟體）；透過分析（A）；其他（O）；以及無測試或無法測試（N）。

顯然，具有T驗證方法的需求將具有相關的測試，以驗證需求。這通常意味著將有對應的測試案例和執行它的測試程式。

程式碼範例：驗證需求

def verify_requirement(requirement, verification_type):
    if verification_type == 'T':
        # 執行測試程式
        return run_test(requirement)
    elif verification_type == 'R':
        # 進行程式碼審查
        return review_code(requirement)
    else:
        # 其他驗證方法
        return other_verification(requirement, verification_type)

def run_test(requirement):
    # 實作測試邏輯
    print(f"執行測試：{requirement}")
    return True

def review_code(requirement):
    # 實作程式碼審查邏輯
    print(f"審查程式碼：{requirement}")
    return True

def other_verification(requirement, verification_type):
    # 實作其他驗證邏輯
    print(f"其他驗證方法：{verification_type}，針對需求：{requirement}")
    return True

# 使用範例
requirement = "DAQ_SRS_700_000"
verification_type = "R"
result = verify_requirement(requirement, verification_type)
print(f"驗證結果：{result}")

內容解密：

1. verify_requirement函式：此函式根據驗證型別呼叫不同的驗證方法。它接受兩個引數：requirement和verification_type，並根據verification_type的值決定呼叫哪個具體的驗證函式。
2. run_test函式：此函式模擬執行測試的過程。它接受一個requirement引數，並傳回測試結果。在實際應用中，這裡應該替換為真實的測試邏輯。
3. review_code函式：此函式模擬程式碼審查的過程。它接受一個requirement引數，並傳回審查結果。在實際應用中，這裡應該替換為真實的程式碼審查邏輯。
4. other_verification函式：此函式處理除了測試和程式碼審查之外的其他驗證方法。它接受requirement和verification_type兩個引數，並傳回驗證結果。在實際應用中，這裡應該根據具體的驗證型別實作相應的邏輯。

需求驗證方法的選擇

對於某些需求，可能很難、不可行或危險地進行測試。在這些情況下，透過仔細審查程式碼來驗證其是否會正確執行可能更容易。對於這樣的需求，驗證方法將是R，即透過審查。

透過分析（A）的驗證方法意味著在某處提供正式（數學）的證明，證明軟體滿足正式需求。這是一個比透過審查更嚴格的過程，也是本文範圍之外的主題。然而，這種驗證方法對於某些可能導致災難性事件（如死亡）的需求可能是必要的。

需求驗證流程

此圖示展示了根據不同的驗證型別選擇合適的驗證方法的流程。

圖示解密：

• 開始：流程的起點。
• 驗證型別：決定使用哪種驗證方法的判斷點。
• 執行測試、進行程式碼審查、進行正式分析：根據驗證型別的不同，執行的具體驗證動作。
• 測試結果、審查結果、分析結果：各個驗證動作的結果。
• 結束：流程的終點，表示驗證過程已經完成。

軟體需求檔案與設計描述檔案的關聯與應用

軟體需求規格（SRS）檔案與軟體設計描述（SDD）檔案在軟體開發過程中扮演著至關重要的角色。兩者之間的關係密切，且透過可追溯性矩陣（RTM）進行繫結，確保需求與設計的一致性。

SRS 與 SDD 的關係

SRS 檔案定義了軟體系統的功能和非功能需求，而 SDD 檔案則提供了軟體設計的詳細描述，包括演算法、資料結構和低階流程控制。兩者之間的關係如圖 11-1 所示。

設計關注點與相關利益者

每個 SRS 中的需求最終都與 SDD 中的設計關注點相關聯。設計關注點是指系統設計中引起利益相關者興趣的任何事項。利益相關者包括任何對系統設計有影響力的人員。需求與設計關注點之間的對映關係如圖 11-2 所示。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title PPDAQ軟體DIP開關設定與乙太網路控制

package "網路架構" {
    package "應用層" {
        component [HTTP/HTTPS] as http
        component [WebSocket] as ws
        component [gRPC] as grpc
    }

    package "傳輸層" {
        component [TCP] as tcp
        component [UDP] as udp
        component [TLS/SSL] as tls
    }

    package "網路層" {
        component [IP] as ip
        component [ICMP] as icmp
        component [路由協議] as routing
    }

    package "鏈路層" {
        component [Ethernet] as eth
        component [WiFi] as wifi
        component [ARP] as arp
    }
}

http --> tcp
ws --> tcp
grpc --> tcp
tcp --> tls : 加密
tls --> ip
udp --> ip
ip --> routing
routing --> eth
routing --> wifi
eth --> arp

@enduml

此圖示說明瞭 SRS、SDD 以及需求、設計關注點和利益相關者之間的關係。

圖示解說：

• SRS 檔案透過可追溯性矩陣與 SDD 檔案繫結，確保需求的完整追蹤。
• 每個需求都會引出一個或多個設計關注點。
• 利益相關者對設計關注點有著重要的影響力。

IEEE Std 1016-2009 的概念模型

IEEE Std 1016-2009 為 SDD 檔案提供了指導方針，採用了統一建模語言（UML）作為軟體建模語言。該標準在 1998 年的基礎上進行了更新，以涵蓋物件導向分析和設計。

關鍵變更：

• 舊版（IEEE Std 1016-1998）根據結構化程式設計概念，已顯過時。
• 新版（IEEE Std 1016-2009）納入了物件導向設計，並保留了部分舊版的功能。

SDD 檔案的內容與結構

SDD 檔案提供了軟體設計的低階實作細節，包括演算法、資料結構和流程控制。雖然沒有直接涉及實際程式碼，但為軟體實作提供了詳細的指導。

軟體需求驗證方法：審查與測試

在軟體開發過程中，驗證需求的正確性和完整性是至關重要的。驗證方法主要分為兩類別：審查和測試。

審查驗證的需求

某些需求由於其特性或系統限制，無法透過測試進行驗證，因此需要透過審查來確認。以下是一些需要審查驗證的需求範例：

DAQ_SRS_700_000 與 DAQ_SRS_700_000.01

這兩個需求涉及軟體在特定平台（如 Netburner 和 μC/OS）上的執行。雖然可以透過在目標平台上執行軟體來驗證，但審查 make/build 檔案是一種更為實際和有效的方法。

DAQ_SRS_702_001 與 DAQ_SRS_702_002

這些需求涉及 RS-232 通訊任務的啟動和優先順序設定。透過審查程式碼，可以確認是否啟動了新的任務以及其優先順序是否正確，而無需修改程式碼進行測試。

程式碼審查範例

void start_rs232_task() {
    // 建立新的任務來處理 RS-232 通訊
    xTaskCreate(rs232_task, "RS232Task", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL);
}

void rs232_task(void *pvParameter) {
    // RS-232 通訊處理邏輯
    for (;;) {
        // 處理 RS-232 資料
    }
}

程式碼解說：

1. start_rs232_task 函式：此函式負責建立新的任務來處理 RS-232 通訊。使用 xTaskCreate 函式來建立任務，並設定其優先順序為 tskIDLE_PRIORITY。
2. rs232_task 函式：此函式包含 RS-232 通訊的處理邏輯。無限迴圈用於持續監聽和處理 RS-232 資料。
3. 任務優先順序：透過審查程式碼，可以確認任務的優先順序是否正確設定。

測試驗證的需求

未在審查驗證清單中的其他需求將透過測試案例和測試程式進行驗證。這包括大多數功能性需求，透過實際執行測試來確認軟體是否符合規格要求。

軟體設計描述檔案化的重要性與實踐

軟體設計描述（Software Design Description, SDD）是軟體開發過程中至關重要的一環，它不僅關係到軟體的最終品質，也直接影響到開發團隊的協作效率與溝通成本。IEEE Std 1016-2009為SDD提供了一套標準化的指導原則，幫助開發者建立一個結構清晰、內容完備的設計檔案。

需求與設計關注點的對映關係

在軟體設計過程中，需求與設計關注點之間的對映關係是至關重要的。根據IEEE的概念模型，每個需求都可能引發零個或多個設計關注點，而每個設計關注點則至少對應一個或多個設計利益相關者。這種對映關係確保了設計的完整性和一致性。

對映關係的實踐意義

1. 需求的合理性驗證：如果一個需求沒有引發任何設計關注點，那麼這個需求可能是冗餘或無效的。
2. 複合需求的拆分：如果一個需求對應多個設計關注點，那麼它可能是一個複合需求，需要進一步拆分成原子需求，以提高需求的清晰度和可管理性。
3. 利益相關者的多維度關注：不同的利益相關者可能會關注相同的設計關注點，這種多對多的關係反映了軟體設計的複雜性和多樣性。

設計視角與設計元素

設計視角（Design Viewpoint）是SDD中的一個核心概念，它將一組相關的設計關注點進行邏輯上的分組。每個設計視角都定義了一系列的設計元素，例如類別圖、序列圖、狀態圖等，用於描述軟體的不同方面。

設計視角的定義與實踐

1. 視角名稱與關聯的設計關注點：清晰地定義每個視角的名稱和它所關注的設計問題。
2. 設計元素的定義：列出該視角所使用的設計元素，包括實體、屬性、關係和約束等。
3. 分析與評估標準：提供根據該視角進行設計分析的方法和評估設計的標準。

關鍵設計元素及其屬性

在SDD中，設計元素是構成軟體設計的基本單位。它們包括但不限於：

• 設計實體：描述軟體系統中的主要元件，如系統、子系統、類別等。
• 屬性：每個設計實體都具有名稱、型別、目的和作者等屬性。
• 關係：描述不同設計實體之間的關聯，如關聯、聚合、依賴等。
• 約束：對設計元素的限制或規則，用於確保設計的一致性和正確性。

程式碼範例與解析

以下是一個簡單的UML類別圖範例，用於描述一個簡單的資料擷取系統（DAQ）的設計：

public class DAQSystem {
    private List<DAQCommand> commands;

    public void executeCommand(DAQCommand command) {
        // 執行DAQ命令的邏輯
    }
}

public interface DAQCommand {
    void execute();
}

// 具體命令類別
public class InitializeDAQ implements DAQCommand {
    @Override
    public void execute() {
        // 初始化DAQ系統的邏輯
    }
}

內容解密：

1. DAQSystem類別：代表整個DAQ系統，包含了一個commands列表，用於儲存和管理不同的DAQ命令。
2. DAQCommand介面：定義了所有DAQ命令需要實作的介面，確保了命令執行的統一性。
3. InitializeDAQ類別：實作了DAQCommand介面，代表了一個具體的初始化DAQ命令。