【正文】 州分公司 內(nèi)部信息，不得向外傳播。 b) 系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)（總線）的選擇 。 f) 系統(tǒng)內(nèi)的操作系統(tǒng)的選取。 j) 復(fù)用現(xiàn)有系統(tǒng)體系結(jié)構(gòu)或處理單元。 在本章的具體組織形式上，可以由作者根據(jù)自己思維的需要來分成不同的子節(jié) 這里強(qiáng)調(diào)一下本章和“構(gòu)架說明”一章描述內(nèi)容的區(qū)別：“設(shè)計(jì)原理”描述的是設(shè)計(jì)的“因”，而“構(gòu)架說 明”描述的是設(shè)計(jì)的“果”。但為了本模板的使用者方便，還是給出了一個(gè)分節(jié)方案，具體編寫上內(nèi)容上，這些小節(jié)本身彼此也還有互相重疊的部分。 關(guān)鍵設(shè)計(jì)驅(qū)動因素 在系統(tǒng)設(shè)計(jì)過程，首先要對系統(tǒng)需求進(jìn)行分析，并提取系統(tǒng)設(shè)計(jì)的關(guān)鍵性因素，即關(guān)鍵技術(shù)點(diǎn)，作為系統(tǒng)設(shè)計(jì)重點(diǎn)考慮的問題。由于關(guān)鍵設(shè)計(jì)驅(qū)動因素直接反映在后續(xù)小節(jié)的描述中，本節(jié)可裁減。 b) 參考某（些）系統(tǒng)的構(gòu)架模式。 因此本節(jié)的內(nèi)容組織上，要從下面幾個(gè)方面來進(jìn)行闡述： a) 識別可供選擇或集成的系統(tǒng)的構(gòu)架，形成幾種候選的框架方案。 需要注意的是，如果已經(jīng)在其他文檔中（如“系統(tǒng)方案論證說明”）描述了所有的候選方案以及挑選的信息，則本節(jié)只需要描述最終選定方案的相關(guān)思路。因此對“以前這么作”作為理由來得到的系統(tǒng)構(gòu)架，要慎重處理，比如“以前這么作”的結(jié)果如何，有沒有缺點(diǎn)，是否成熟，是否和現(xiàn)在的需求一致等等。 根據(jù)需求，要求 BSC 帶的載頻達(dá)到 1024 個(gè)，如果仍象 XXX（ V1）那樣，將 A 口、Gb 口和 Abis 口的信令處理全集中在一個(gè) MP 上進(jìn)行是不可行的，勢必要進(jìn)行分布式處理。 SCM 負(fù)責(zé)處理整個(gè)BSC 系統(tǒng)與 MSC、 SGSN 的信令交互；無線管理子系統(tǒng)負(fù)責(zé)處理 Abis 接口上的信令流程。本節(jié)就用于描述系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)設(shè)計(jì)方面的考慮?？偩€型、星型、環(huán)型。 d) 通信網(wǎng)絡(luò)上的通信協(xié)議的選擇。一般常見的可靠性考慮的方面包括： a) 系統(tǒng)的 MTBF 的推算過程。 d) 熱設(shè)計(jì)、 EMC、結(jié)構(gòu)、安全性等方面的考慮。 XXXXXX 系統(tǒng)方案 〈 〉 機(jī)密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。而 XXX 的其余部份的散熱仍舊靠下進(jìn)風(fēng)口進(jìn)風(fēng)。 XXX 要求適應(yīng)的靜電放電等級為接觸放電177。接觸放電則作用于 TRM、 AEM、 CMM 的面板SMA 座和緊固螺釘。如節(jié)點(diǎn)上使用單處理器還是多處理器，選用各種專用處理器還是統(tǒng)一選用通用處理器等等。如 RAM/ROM/HD/FD/FALSH 等的選擇與平衡。 建立的呼叫話務(wù)模型為： 平均保持時(shí)間： 120s/呼叫 MS 起呼比例： 70% MS 結(jié)束比例： 30% XXX 系統(tǒng)方案 〈 〉 機(jī)密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 b) 說明對這些技術(shù)難點(diǎn)采用或選擇的關(guān)鍵技術(shù)。 目前常見的底層軟件平臺的選擇可能包括： a) 系統(tǒng)內(nèi)的操作系統(tǒng)的選取。 e) 編程語言 /工具的選擇。 c) 選擇器失效檢測， 防止程序引用還未定義的內(nèi)存段。 其實(shí)最關(guān)鍵的就是這一句話，前面的有些多余。 c) 對 a)的組件的未來的維護(hù)方式。 ===Example Begin==================================================== 例 復(fù)用和外購考慮 由于本系統(tǒng)的構(gòu)架上保持了基本維持了標(biāo)準(zhǔn)構(gòu)架（詳見“系統(tǒng)結(jié)構(gòu)的考慮”一節(jié)中的說明），在這種情況下，在設(shè)計(jì)時(shí)表 所列的各子系統(tǒng)有直接復(fù)用或外購。特別是要說明本系統(tǒng)的組成結(jié)構(gòu)，即都有哪些組件（子系統(tǒng)或模塊）、組件間、組件和系統(tǒng)外都有哪些接口。 軟件子系統(tǒng) 軟件子系統(tǒng)硬件子系統(tǒng) 硬件子系統(tǒng)結(jié)構(gòu)子系統(tǒng)①② ②③③④⑤ ⑤⑥ ⑥ 圖 構(gòu)成一個(gè)產(chǎn)品的組件，一般會有下面幾種類型： a) 結(jié)構(gòu)子系統(tǒng) 一般單個(gè)機(jī)架的結(jié)構(gòu)就是一個(gè)結(jié)構(gòu)子系統(tǒng)（包含風(fēng)扇，但不包含風(fēng)扇控制部分）。 一般某單板上某處理器上運(yùn)行的軟件或軟件中比較大的組件都屬于軟件子系統(tǒng)。是前面結(jié)構(gòu)組件、硬件組件、軟件組件的混合體或者是硬件組件和軟件組件的混合體，一般出現(xiàn)于分級進(jìn)行系統(tǒng)設(shè)計(jì)的過程中。 c) 硬件子系統(tǒng)和結(jié)構(gòu) 子系統(tǒng)之間的接口：一般包括接地、安裝、風(fēng)扇控制等等。 b) 軟件組件和系統(tǒng)外部的接口：類似軟件組件和軟件組件之間的接口，一般包括高層的通信協(xié)議、消息等等。圖中要清楚說明系統(tǒng)被劃分成哪些種類的組件，最好能在圖中描述清楚這些組件間存在哪些接口、這些子系統(tǒng)和系統(tǒng)外存在哪些接口，如果由于圖中接口比較復(fù)雜，無法表明所有接口，可以借助接口的屬性接口說明表予以說明。表格中對每個(gè)接口列出接口組全局標(biāo)識、類型（和本系統(tǒng)外部的接口還是本系統(tǒng)內(nèi)的 組件間接口）、接口連接的組件、功能概述等信息。 e) 配置說明。 系統(tǒng)構(gòu)架 配置說明 部署說明 ===Example Begin==================================================== 例 構(gòu)架說明 系統(tǒng)構(gòu)架 說明：本行在實(shí)際文檔中應(yīng)該是一個(gè)二級標(biāo)題，但因會影響本模板目錄生成的美觀問題沒有設(shè)置成二級標(biāo)題。 表 子系統(tǒng)標(biāo)識 子系統(tǒng)名稱 子系統(tǒng)類型 子系統(tǒng)功能說明 SCU 系統(tǒng)控制子系統(tǒng) 復(fù)合子系統(tǒng) 完成對 A接口地面電路設(shè)備的直接管理和 7 號信令的處理，提供系統(tǒng) 的時(shí)鐘信號，維護(hù)和監(jiān)控除STR 和 PWA外的各子系統(tǒng)。 AIU A接口子系統(tǒng) 復(fù)合子系統(tǒng) 完成 A口的接口物理功能。 17 子系統(tǒng)標(biāo)識 子系統(tǒng)名稱 子系統(tǒng)類型 子系統(tǒng)功能說明 PWA 一次電源子系統(tǒng) 硬 件子系統(tǒng) 提供系統(tǒng)中其他子系統(tǒng)的 48VDC 電源 STR 整機(jī)結(jié)構(gòu)子系統(tǒng) 結(jié)構(gòu)子系統(tǒng) 提供整機(jī)的機(jī)架 各接口的說明見表 。 示例省略 配置說明 設(shè) XXX 的載頻總數(shù)為 Ntrx。 表 層 6 BBIU1 BBIU2 層 5 BCTL(RMU1) BCTL(RMU2) 層 4 BCTL(SCU) BATC3 層 3 BNET BATC4 層 2 BATC1 層 1 BATC2 機(jī)架 1 機(jī)架 2 當(dāng) 480Ntrx≤ 720 時(shí)，要三個(gè)機(jī)架完成，在上面的基礎(chǔ)上，增加四層框，見表 。 另外說明一點(diǎn)，與其他章節(jié)不一樣的是，本節(jié)在描述中的“組件”，是指具體實(shí)例化的（ instantiated）組件，而其他章節(jié)中的“組件”，往往指的是組件的類型（ type）。類似的，對協(xié)作進(jìn)行命名時(shí)，應(yīng)該完全保持保持上游需求的名稱，不要再另起新的名稱。關(guān)于功能協(xié)作的含義，用個(gè)小例子來幫助說明，假設(shè)上游功能要求中有個(gè)“建立無線連接”功能，上游的描述中并不關(guān)心本系統(tǒng)是如何實(shí)現(xiàn)的，因此描述光說 BTS 發(fā)送過來 I(EST REQ)消息，正常情況下本系統(tǒng)（指 BSC 系統(tǒng)）給予建立成功響應(yīng)： I(EST CONF)。 XXX 系統(tǒng)方案 〈 〉 機(jī)密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。在描述中需要注意： a) 在上游功能要求的說明中，往往包含了正常過程、可選過程和異常過程三類，因此在進(jìn)行本節(jié)描述時(shí)，也要對應(yīng)分別加以細(xì)化描述，不要遺漏某些過程。 d) 正常過程、可選過程和異常過程之間的分支和跳轉(zhuǎn)關(guān)系必須描述清楚，描述要求是： 1) 在每個(gè)可選過程名稱中，需要用“（ XXX）”形式指明是從正常過程或可選過程的哪個(gè)步驟中分支出來的。 e) 如果要引用某個(gè)完整的功能協(xié)作（如用于透明收或發(fā)消息的協(xié)作），則在引用的地方用“（ XXXX）”的形式指明 ，括號中為該協(xié)作的標(biāo)識 f) 在文檔的其他部分，如果要引用某個(gè)可選過程或異常過程，則需要同時(shí)描述協(xié)作編號和過程編號，它們之間用“ .”分隔。 h) “特殊要求”字段除了可以描述針對本功能協(xié)作的非功能需求外，還可以用于本協(xié)作中的某些步驟中補(bǔ)充說明或注解，但在相應(yīng)步驟中應(yīng)該明確用 “（見特殊要求Sxxxx）”的形式標(biāo)識出參見關(guān)系。 ===Example Begin==================================================== 例 1 功能協(xié)作的 use case 文本形式 系統(tǒng) BWA 在分解成 OMC 子系統(tǒng)、 AU軟件子系統(tǒng)、 SU 軟件子系統(tǒng)、 FPGA 子系統(tǒng)、 AU硬件子系統(tǒng)、 SU 硬件子系統(tǒng)六個(gè)子系統(tǒng)后，對“設(shè)置以太網(wǎng)橋接”功能需求的協(xié)作說明 SDBWAC01 設(shè)置以太網(wǎng)橋接 功能描述 ： 打開或關(guān)閉系統(tǒng)的以太網(wǎng)橋接功能。用例開始。 22 b) 向相連的 FPGA 子系統(tǒng)發(fā)送 OPEN_BRIDGE 消息（ SDBWAC40）。然后向相連的 AU 軟件子系統(tǒng)或或相連的 SU 軟件子系統(tǒng)發(fā)送 CONFIG_BRIDGE_OK 消息（ SDBWAC40， SDBWAC60）。 N002070 AU 軟件子系統(tǒng)在 N02020 步 5s 后 ： a) 如果沒有收到某 SU 子系統(tǒng)的任何響應(yīng)消息，則標(biāo)記該 SU 設(shè)置不確定標(biāo)記。 N0030 OMC 子系統(tǒng)在 N02010 步之后的 7s 內(nèi)收到 AU 軟件子系統(tǒng)的 CONFIG BRIDGE ACKNOWLEDGE 消息，則根據(jù)消息中的內(nèi)容采取下述處理： a) AU 設(shè)置標(biāo)記成功，則標(biāo)記 AU 以太網(wǎng)橋接狀態(tài)為用戶期望的狀態(tài)。 c) 向用戶反饋 a)和 b)的信息。 b) 向相連的 FPGA 子系統(tǒng)發(fā)送 CLOSE_BRIDGE 消息（ SDBWAC40）。 A0030 FPGA 子系統(tǒng)收到 CLOSE_BRIDGE 消息，則關(guān)閉以太網(wǎng)橋接功能。 異常過程 ： E1 超時(shí)沒有收到應(yīng)答（ ） E0010 如果 OMC 子系統(tǒng)在 N02010 步 之后的 7s 內(nèi)沒有收到 AU 軟件子系統(tǒng)的CONFIG BRIDGE ACKNOWLEDGE 消息，則： a) 標(biāo)記 AU 和所有 SU 的以太網(wǎng)橋接狀態(tài)為不確定。 特殊要求： 無。 非功能協(xié)作 非功能協(xié)作 1全局標(biāo)識 非功能協(xié)作 1名稱 本節(jié)用于描述證明分解得到的各組件通過相互合作能夠完全滿足所需的系統(tǒng)的非功能需求的相關(guān)信息。 c) 對本系統(tǒng)的“標(biāo)準(zhǔn)化需求”類的非功能需求，要么被延續(xù)到組成本系統(tǒng)的某個(gè)組件的“模塊化要求”中，要么已經(jīng)成為本系統(tǒng)在設(shè)計(jì)時(shí)考慮的一個(gè)因素，應(yīng)該在“設(shè)計(jì)原理”一章中提及，此處就可以參見之。 在描述中，需要注意本節(jié)組織形式（格式）上，應(yīng)該基本保持和上游功能要求的組織形式一致。 e) 對本系統(tǒng)的“成本 /重量需求”類的非功能需求，要 求明確分解到組成本系統(tǒng)的各組件的“成本 /重量需求”上。 下面是一些編寫非功能需求的協(xié)作說明的方法： a) 對本系統(tǒng)的“性能需求”類的非功能需求，要求明確分解到組成本系統(tǒng)的各組件的“性能需求”上。 24 功能協(xié)作 2全局標(biāo)識 功能協(xié)作 2名稱 格式同上，不再復(fù)述。 以上 b)必須在 a)之后執(zhí)行。 A0040 SU 軟件子系統(tǒng)在發(fā)送 CLOSE_BRIDGE 之后的 3s 時(shí)間內(nèi)收到了 FPGA 的CONFIG_BRIDGE_OK 消息，則向相連的 AU 軟件子系統(tǒng)發(fā)送 CONFIG ETHERNET BRIDGE OK 消息（ SDBWAC50）。 A0020 SU 軟件子系統(tǒng)收到 CONFIG ETHERNET BRIDGE 消息，向相連的 FPGA 子XXX 系統(tǒng)方案 〈 〉 機(jī)密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 N0040 用例結(jié)束。 b) 某 SU 設(shè)置標(biāo)記成功，則標(biāo)記該 SU 以太網(wǎng)橋接狀態(tài)為用戶期望的狀態(tài)。 c) 發(fā)送 CONFIG BRIDGE ACKNOWLEDGE 消息給 OMC 子系統(tǒng)（ SDBWAC30），消息中包含了所有 AU 和 SU 的設(shè)置標(biāo)記。 N002060 AU 軟件子系統(tǒng)在 N02020 步之后的 5s 內(nèi)對收到的消息采取下述的處理： d) 收到某 SU 子系統(tǒng)的 CONFIG ETHERNET BRIDGE OK 消息，則標(biāo)記該 SU 設(shè)置成功標(biāo)記。 N002030 SU 軟件子系統(tǒng)收到 CONFIG ETHERNET BRIDGE 消息， SU 軟件子系統(tǒng)向相連的 FPGA 子系統(tǒng)發(fā)送 OPEN_BRIDGE 消息（ SDBWAC60）。 N002020 AU 軟件子系統(tǒng)收到 CONFIG BRIDGE 消息，消息中指示打開以太網(wǎng)橋接功能，則： a) 向于自己相連的的每個(gè) SU軟件子系統(tǒng)分別發(fā)送 CONFIG ETHERNET BRIDGE消息（ SDBWAC50），消息中包含了 CONFIG BRIDGE 消息中需要設(shè)置的狀態(tài)。 后置條件 ： R0010 AU 和各