【正文】 件間的接口（后稱內(nèi)部接口）一般會有下面四種類型： a) 硬件子系統(tǒng)和硬件子系統(tǒng)之間的接口：一般包括物理連接、信號、低層的通信協(xié)議等等。是前面結(jié)構(gòu)組件、硬件組件、軟件組件的混合體或者是硬件組件和軟件組件的混合體，一般出現(xiàn)于分級進行系統(tǒng)設(shè)計的過程中。 XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 一般某單板上某處理器上運行的軟件或軟件中比較大的組件都屬于軟件子系統(tǒng)。硬件功能單板、電源板和背板都屬于某種硬件子系統(tǒng)。 軟件子系統(tǒng) 軟件子系統(tǒng)硬件子系統(tǒng) 硬件子系統(tǒng)結(jié)構(gòu)子系統(tǒng)①② ②③③④⑤ ⑤⑥ ⑥ 圖 構(gòu)成一個產(chǎn)品的組件，一般會有下面幾種類型： a) 結(jié)構(gòu)子系統(tǒng) 一般單個機架的結(jié)構(gòu)就是一個結(jié)構(gòu)子系統(tǒng)（包含風(fēng)扇，但不包含風(fēng)扇控制部分）。 在“接口說明”一章中，會具體說明每個接口詳細信息，在“設(shè)計原理”一章中，會具體說明得到這些個分解結(jié)果的 原因。特別是要說明本系統(tǒng)的組成結(jié)構(gòu)，即都有哪些組件（子系統(tǒng)或模塊）、組件間、組件和系統(tǒng)外都有哪些接口。 表 序號 子系統(tǒng)名稱 復(fù)用 /外購 理由 維護方式 備注 1 AAA 硬件子系統(tǒng) 復(fù)用 見《 XXX 論證說明》 節(jié) 被本項目使用后，將不再隨 XX模塊庫的變化而引起本項目變化（即分支不再合并） 2 BBBB 硬件子系統(tǒng) 外購 見《 XXX 論證說明》 節(jié) 3 CCC軟件子系統(tǒng) 復(fù)用 見《 XXX 論證說明》 節(jié) 本項目使用后，不再隨 YY項目的變化而引起本項目變化（即分支不再合并） XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 ===Example Begin==================================================== 例 復(fù)用和外購考慮 由于本系統(tǒng)的構(gòu)架上保持了基本維持了標(biāo)準(zhǔn)構(gòu)架（詳見“系統(tǒng)結(jié)構(gòu)的考慮”一節(jié)中的說明），在這種情況下，在設(shè)計時表 所列的各子系統(tǒng)有直接復(fù)用或外購。 一般來說，本節(jié)的內(nèi)容關(guān)注于本系統(tǒng)分解得到的各子系統(tǒng)的復(fù)用和外購問題，而不要涉及子系統(tǒng)內(nèi)部部件的復(fù)用和外購，各子系統(tǒng)內(nèi)部的復(fù)用和外購要求可以在各子系統(tǒng)的需求 說明書中加以描述。 c) 對 a)的組件的未來的維護方式。所以本節(jié)要描述的內(nèi)容，主要是具體說明： a) 本系統(tǒng)分解得到的哪些子系統(tǒng)不再重新開發(fā)，而是直接復(fù)用或外購得到。 其實最關(guān)鍵的就是這一句話，前面的有些多余。 IRMX 提供了多任務(wù)運行環(huán)境， OSS 在此基礎(chǔ)上構(gòu)成了一系列的應(yīng)用進程的二級調(diào)度以控制應(yīng)用進程的運行。 c) 選擇器失效檢測， 防止程序引用還未定義的內(nèi)存段。 13 a) 存儲區(qū)分段保護， 以防段訪問超過定義的大小。 e) 編程語言 /工具的選擇。 c) 通信協(xié)議 /中間件（ middleware）的選擇。 目前常見的底層軟件平臺的選擇可能包括： a) 系統(tǒng)內(nèi)的操作系統(tǒng)的選取。 在編寫關(guān)鍵技術(shù)的內(nèi)容時常見的問題是：對關(guān)鍵技術(shù)的解決描述得過于詳細，嚴(yán)重超越了本文的范圍，而導(dǎo)致對后續(xù)設(shè)計人員的工作產(chǎn)生了干擾。 b) 說明對這些技術(shù)難點采用或選擇的關(guān)鍵技術(shù)。在這種話務(wù)模型下面，一秒處理的呼叫數(shù)為 10 個，一次呼叫平均處理消息為 300 個，則系統(tǒng) 需要的 對于與話務(wù)相關(guān)消息能力應(yīng)該達到 10 * 300 = 3000 消息 /s。 建立的呼叫話務(wù)模型為： 平均保持時間： 120s/呼叫 MS 起呼比例： 70% MS 結(jié)束比例： 30% XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 g) 高性能與可配置的關(guān)系。如 RAM/ROM/HD/FD/FALSH 等的選擇與平衡。 d) 系統(tǒng)的內(nèi)部和外部網(wǎng)絡(luò)通信處理能力。如節(jié)點上使用單處理器還是多處理器，選用各種專用處理器還是統(tǒng)一選用通用處理器等等。常見的性能方面的考慮可能包括： a) 系統(tǒng)容量需求。接觸放電則作用于 TRM、 AEM、 CMM 的面板SMA 座和緊固螺釘。 8kV。 XXX 要求適應(yīng)的靜電放電等級為接觸放電177。要求采用的材料和安裝工藝設(shè)計達到搭接要求，以滿足靜電接觸放電的要求。而 XXX 的其余部份的散熱仍舊靠下進風(fēng)口進風(fēng)。而常規(guī)的下部進風(fēng)方式對靠前面板散熱器散熱效果不好。 XXXXXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。 圖 這樣，單個 BOSN 子系統(tǒng)的故障，不會導(dǎo)致 系統(tǒng)無法提供服務(wù)，甚至 MP、 COM 的單個故障也不會造成系統(tǒng)無法提供服務(wù)。 d) 熱設(shè)計、 EMC、結(jié)構(gòu)、安全性等方面的考慮。 c) 備份的策略選擇。一般常見的可靠性考慮的方面包括： a) 系統(tǒng)的 MTBF 的推算過程。 現(xiàn)有的 MP 子系統(tǒng)上提供了雙網(wǎng)卡，目前于 OMCR 的通信只占用了一個網(wǎng)卡，而另一個網(wǎng)卡未用，如果在 PUC 單元內(nèi)加一個內(nèi)置 HUB，則完全可能通過以太網(wǎng)通信來承載 MP和 PUC 單元間的信令。 d) 通信網(wǎng)絡(luò)上的通信協(xié)議的選擇。包括兩個方面，一個是帶寬的擴展性，一個是節(jié)點數(shù)量的擴XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播?？偩€型、星型、環(huán)型。用一個統(tǒng)一的通信網(wǎng)絡(luò)在系統(tǒng)復(fù)雜性、擴展性方面都有比較好的優(yōu)勢，但有時，性能、可靠性方面的要求可能需要在系統(tǒng)中同時建立兩個甚至三個通信網(wǎng)絡(luò)，分別承載不同類型的信息。本節(jié)就用于描述系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)設(shè)計方面的考慮。 圖 示例后略。 SCM 負責(zé)處理整個BSC 系統(tǒng)與 MSC、 SGSN 的信令交互；無線管理子系統(tǒng)負責(zé)處理 Abis 接口上的信令流程。由于 A 口 /Gb 口與 Abis 口 間的信令流程的劃分相對清晰，因此，考慮將 Abis 口的信令用多個處理器來分擔(dān)處理，而 A 口/Gb 口的信令用一個處理器統(tǒng)一處理。 根據(jù)需求，要求 BSC 帶的載頻達到 1024 個，如果仍象 XXX（ V1）那樣，將 A 口、Gb 口和 Abis 口的信令處理全集中在一個 MP 上進行是不可行的，勢必要進行分布式處理。 ===Example Begin==================================================== XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。因此對“以前這么作”作為理由來得到的系統(tǒng)構(gòu)架，要慎重處理，比如“以前這么作”的結(jié)果如何，有沒有缺點，是否成熟，是否和現(xiàn)在的需求一致等等。 本節(jié)在編寫上最容易犯的錯誤就是先入為主，不去考慮或不愿考慮其他的可能性，而只抓著 “延續(xù)以前的方案”不放，因為這樣寫起來比較省事，理由似乎也很充分：“高復(fù)用性”。 需要注意的是，如果已經(jīng)在其他文檔中（如“系統(tǒng)方案論證說明”）描述了所有的候選方案以及挑選的信息，則本節(jié)只需要描述最終選定方案的相關(guān)思路。當(dāng)然，需要說明為什么這些因素是關(guān)鍵的理由以及為什么其他因素相對不 關(guān)鍵的理由。 因此本節(jié)的內(nèi)容組織上，要從下面幾個方面來進行闡述： a) 識別可供選擇或集成的系統(tǒng)的構(gòu)架，形成幾種候選的框架方案。是多處理器集中式處理還是全分布式處理。 b) 參考某（些）系統(tǒng)的構(gòu)架模式。 系統(tǒng)構(gòu)架的考慮 作為一個高層設(shè)計，系統(tǒng)的整體構(gòu)架的確定是極其關(guān)鍵的，一般也是“設(shè)計原理”一章中的關(guān)鍵。由于關(guān)鍵設(shè)計驅(qū)動因素直接反映在后續(xù)小節(jié)的描述中，本節(jié)可裁減。 8 出相應(yīng) 的思考結(jié)果。 關(guān)鍵設(shè)計驅(qū)動因素 在系統(tǒng)設(shè)計過程，首先要對系統(tǒng)需求進行分析，并提取系統(tǒng)設(shè)計的關(guān)鍵性因素，即關(guān)鍵技術(shù)點，作為系統(tǒng)設(shè)計重點考慮的問題。特別注意，“系統(tǒng)結(jié)構(gòu)的考慮”這一節(jié)因為其重要性，是必寫內(nèi)容，不允許被刪除。但為了本模板的使用者方便，還是給出了一個分節(jié)方案，具體編寫上內(nèi)容上，這些小節(jié)本身彼此也還有互相重疊的部分。 在描述設(shè)計原理的過程中，為幫助讀者的理解，應(yīng)該提供足夠的示意圖表，比如模型圖、結(jié)構(gòu)圖、場景圖等等。 在本章的具體組織形式上，可以由作者根據(jù)自己思維的需要來分成不同的子節(jié) 這里強調(diào)一下本章和“構(gòu)架說明”一章描述內(nèi)容的區(qū)別：“設(shè)計原理”描述的是設(shè)計的“因”，而“構(gòu)架說 明”描述的是設(shè)計的“果”。 l) 性能相關(guān)的考慮（如系統(tǒng)容量需求等）。 j) 復(fù)用現(xiàn)有系統(tǒng)體系結(jié)構(gòu)或處理單元。 h) 系統(tǒng)硬件平臺選擇。 f) 系統(tǒng)內(nèi)的操作系統(tǒng)的選取。 d) 系統(tǒng)的關(guān)鍵處理部件的備份。 b) 系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)（總線）的選擇 。本章的描述程度，應(yīng)該達到能夠解答讀者的為什么要這樣設(shè)計的疑問。 5 設(shè)計原理 XXX 系統(tǒng)方案 〈 〉 機密 ▲ 本文中的所有信息均為 江蘇鴻信系統(tǒng)集成公司蘇州分公司 內(nèi)部信息，不得向外傳播。這里需要給出一張本系統(tǒng)和其他所有相關(guān)系統(tǒng)（可能包括整個系統(tǒng)外的實體）的關(guān)系圖，從圖中至少應(yīng)該能夠看出本系 統(tǒng)和哪些系統(tǒng)之間有關(guān)系，最好用不同的顏色來區(qū)分本系統(tǒng)和其他外部系統(tǒng)。一個簡單的概述，不需要非常詳細，只要能夠讓讀者大致了解本系統(tǒng)的主要功能就可以了。使讀者能夠了解本系統(tǒng)的大致需求概貌。 表 文件編號 文件名稱 版本號 說明 XXX XX 研制規(guī)范 上游文檔 XXX XX 術(shù)語 、 定義和縮略語 引用文檔 XXX XX 軟硬件配置說明 引用文檔 包含了本文的“構(gòu)架說明”部分的配置說明的內(nèi)容 XXX XX 系統(tǒng)接口說明書 引用文檔 包含了本文的“接口說明”部分的全部內(nèi)容 XXX XX 子系統(tǒng)需求說明書 引用文檔 包含了本文的“組件說明”部分該組件的全部內(nèi)容 3GPP General Packet Radio Service (GPRS)。 d) 在“說明”欄中必須包含文檔的分類信息，即該文檔是“上游文檔”和“引用文檔”中的哪一種。 3) 本文的“接口說明”部分單獨成文，而 成為本文的引用文檔。 6 用文檔一般會有： 1) 本文的“術(shù)語、定義和縮略語”部分可能引用的項目的 術(shù)語 、 定義和縮略語 文檔。 c) 引用文檔的原因是為了防止重復(fù)勞動，或者是因為某部分內(nèi)容單獨成文。 b) 上游文檔指的是緊挨本文的上游文檔。這些內(nèi)容應(yīng)該寫在本文最后一章的“參考文獻” 中。 表 縮略語 原文 中文含義 AAL2 ATM Adaptation Layer type 2 第二類 ATM適配層 Abstract Syntax Notation number One 抽象語法標(biāo)記法 Concrete Syntax Notation number One 具體語法標(biāo)記法 MSC Message Sequence Chart 消息流圖 MTBF Mean Time Between Failures 平均故障間隔時間 PDL Program Design Language 程序設(shè)計語言 SD System Design 系統(tǒng)設(shè)計 3 設(shè)計依據(jù) 本章詳細列出兩部分文檔，一部分是本文檔的直接上游文檔（如“產(chǎn)品需求說明書”），另一部分是本文中需要引用的文檔（如本系統(tǒng)內(nèi)的子系統(tǒng)間的接口文檔、數(shù)據(jù)字典文檔、 術(shù)語 /定義 /縮略語 文檔、有關(guān)的協(xié)議 /標(biāo)準(zhǔn)文件等）。 組件 Component 組成本系統(tǒng)的一些小的部件類型，可以是一些常規(guī)意義上的子系統(tǒng)，也可以是一些常規(guī)意義上的模塊。 構(gòu)架 Architecture 也叫體系結(jié)構(gòu)，但本文按照最近的譯文習(xí)慣，稱為構(gòu)架。 術(shù)語、定義 本文使用的專用術(shù)語、定義見表 。 5 對于只有本文自己使用的獨特的術(shù)語、定義和縮略語，則不應(yīng)該放到這份被很多文檔應(yīng)用的獨立文件中，而需要在本文中列表描述。特此說明。應(yīng)將每一類約定用一段或若干段進行描述，即應(yīng)避免在一段中描述所有這些內(nèi)容。 預(yù)期的讀者和閱讀建議 本文檔預(yù)期的讀者和閱讀建議見表 。 3 非功能協(xié)作 1 全局標(biāo)識 非功能協(xié)作 1 名稱 ................................... 24 非功能協(xié)作 2 全 局標(biāo)識 非功能協(xié)作 2 名稱 ...................................