系统方案设计模板

系统方案设计模板内容摘要：

统负荷的大部分。 由于 A 口 /Gb 口与 Abis 口 间的信令流程的划分相对清晰，因此，考虑将 Abis 口的信令用多个处理器来分担处理，而 A 口/Gb 口的信令用一个处理器统一处理。 也就是说，从信令处理角度上讲，可将 BSC 分为两类复合子系统： SCM（系统控制子系统）和 RMM（无线管理子系统）。 SCM 负责处理整个BSC 系统与 MSC、 SGSN 的信令交互；无线管理子系统负责处理 Abis 接口上的信令流程。 见示意图。 图 示例后略。 ====Example End==================================================== 内部通信网络的考虑 在一个分布式处理的系统中，其内部的通信网络的选择也是非常关键的一部分工作，其影响到系统整体的性能、扩展性、可靠性、成本、技术难度等等。 本节就用于描述系统内部通信网络设计方面的考虑。 一般的设计考虑包括下面几个方面： a) 通信网络数量的选择。 用一个统一的通信网络在系统复杂性、扩展性方面都有比较好的优势，但有时，性能、可靠性方面的要求可能需要在系统中同时建立两个甚至三个通信网络，分别承载不同类型的信息。 b) 通信网络的种类。 总线型、星型、环型。 c) 通信网络的可扩展性。 包括两个方面，一个是带宽的扩展性，一个是节点数量的扩XXX 系统方案 〈 〉 机密 ▲ 本文中的所有信息均为 江苏鸿信系统集成公司苏州分公司 内部信息，不得向外传播。 10 展性。 d) 通信网络上的通信协议的选择。 ===Example Begin==================================================== 例 内部通信网络的考虑 考虑 RMM 的 MP 子系统和 PUC 子系统间的信令流量比较大，如果通过现有的 HDLC进行传输，则每个通路需要 4 个以上的 64Kb 时隙，一方面因占用 HDLC 资源而导致系统提供的最大容量的下降，另一方面因为 HDLC 通路中间经过的子系统比较多，而 导致时隙接续的数据配置非常复杂，维护性降低。 现有的 MP 子系统上提供了双网卡，目前于 OMCR 的通信只占用了一个网卡，而另一个网卡未用，如果在 PUC 单元内加一个内置 HUB，则完全可能通过以太网通信来承载 MP和 PUC 单元间的信令。 ====Example End==================================================== 可靠性的考虑 本节主要描述的系统设计过程中的可靠性方面的考虑。 一般常见的可靠性考虑的方面包括： a) 系统的 MTBF 的推算过程。 b) 关键处理部件的备份 考虑。 c) 备份的策略选择。 热备份还是冷备份，故障时的自动恢复策略等等。 d) 热设计、 EMC、结构、安全性等方面的考虑。 ===Example Begin==================================================== 例 1 可靠性的考虑 交换网的热备份 MP 子系统对 BOSN 子系统的管理是 XXX 得以功能实现的基础， BOSN 子系统本身是热备用，对其的管理按如图 的连接进行。 图 这样，单个 BOSN 子系统的故障，不会导致 系统无法提供服务，甚至 MP、 COM 的单个故障也不会造成系统无法提供服务。 例 2 可靠性的考虑 结构设计 由于 XXX 子系统的热耗最大，对此硬件子系统的结构形式及通风要求作特别考虑。 XXXXXX 系统方案 〈 〉 机密 ▲ 本文中的所有信息均为 江苏鸿信系统集成公司苏州分公司 内部信息，不得向外传播。 11 中的 PA 子系统是最主要的热源，所处位置靠面板处。 而常规的下部进风方式对靠前面板散热器散热效果不好。 为解决这一问题，可以在 XXX 的前面板开一定进风口是增大进风口尺寸和进风通道畅通，对 XXX 中 PA 施行特殊冷却。 而 XXX 的其余部份的散热仍旧靠下进风口进风。 例 3 可靠性的考虑 防静电设计 XXX 机架上的所有模块都采用金属结构 件，当安装到机架上时，采用金属螺钉紧固于机架。 要求采用的材料和安装工艺设计达到搭接要求，以满足静电接触放电的要求。 同样，所有金属接头（主要是 SMA 座）的外壳应能良好接地。 XXX 要求适应的静电放电等级为接触放电177。 6kV；空气放电177。 8kV。 空气放电实验将作用于 PDM 的 24 个开关。 接触放电则作用于 TRM、 AEM、 CMM 的面板SMA 座和紧固螺钉。 ====Example End==================================================== 性能的考虑 本节描述在系统 设计过程中关于如何达到和提升系统性能方面的考虑。 常见的性能方面的考虑可能包括： a) 系统容量需求。 b) 系统的业务处理能力。 如节点上使用单处理器还是多处理器，选用各种专用处理器还是统一选用通用处理器等等。 c) 系统的密集计算能力。 d) 系统的内部和外部网络通信处理能力。 e) 系统的存储器方面的考虑。 如 RAM/ROM/HD/FD/FALSH 等的选择与平衡。 f) 性能与成本之间的平衡，即性价比。 g) 高性能与可配置的关系。 ===Example Begin==================================================== 例 性能的考虑 在《 XXX 研制规范》中要求系统单模块的最大处理能力为 1200 erl，这样要求主处理器每秒钟处理的消息数分析如下。 建立的呼叫话务模型为： 平均保持时间： 120s/呼叫 MS 起呼比例： 70% MS 结束比例： 30% XXX 系统方案 〈 〉 机密 ▲ 本文中的所有信息均为 江苏鸿信系统集成公司苏州分公司 内部信息，不得向外传播。 12 切换次数： 次 /呼叫 位置更新次数： 2 次 /呼叫 IMSI 去附着次数： 次 /呼叫 寻呼无应答： 63% 测量报告： 480ms/次 在一个呼叫期间：与呼叫相关的消息数约 50 个 (与 A 接口和 Abis 接口都相关 )， Abis接口对应 (测量报告 )消息数为 120/=250 个，总计 300 个。 在这种话务模型下面，一秒处理的呼叫数为 10 个，一次呼叫平均处理消息为 300 个，则系统 需要的 对于与话务相关消息能力应该达到 10 * 300 = 3000 消息 /s。 在这个基础上进行具体的设计，示例省略 ====Example End==================================================== 关键技术的考虑 本节针对设计系统时存在的关键技术加以论述 ，包括： a) 说明本系统中可能存在的技术难点。 b) 说明对这些技术难点采用或选择的关键技术。 c) 说明采用的关键技术如何影响本系统的设计，或者本系统的设计如何能适应这些关键技术。 在编写关键技术的内容时常见的问题是：对关键技术的解决描述得过于详细，严重超越了本文的范围，而导致对后续设计人员的工作产生了干扰。 软件平台的考虑 本节描述系统的底层软件平台的选择与考虑。 目前常见的底层软件平台的选择可能包括： a) 系统内的操作系统的选取。 b) 系统内的数据库的选取。 c) 通信协议 /中间件（ middleware）的选择。 d) 应用框架（ Application Framework）的选择。 e) 编程语言 /工具的选择。 ===Example Begin==================================================== 例 软件平台的考虑 IRMX 操作系统是基于 AT 总线的在保护模式下的多任务操作系统，在 486 下真正实现 32 位编程，它所支持的 Intel 386 和 486 处理器保护功能有： XXX 系统方案 〈 〉 机密 ▲ 本文中的所有信息均为 江苏鸿信系统集成公司苏州分公司 内部信息，不得向外传播。 13 a) 存储区分段保护， 以防段访问超过定义的大小。 b) 栈溢出检测， 以防失控的程序从堆栈中溢出并把重要的信息覆盖掉。 c) 选择器失效检测， 防止程序引用还未定义的内存段。 d) 存取权限保护。 IRMX 提供了多任务运行环境， OSS 在此基础上构成了一系列的应用进程的二级调度以控制应用进程的运行。 考虑 MP 上的底层软件大部分借用原有产品，且 IRMX 比较成熟，开发经验积累多，因而对 MP 上的开发不更换操作系统，仍用 IRMX。 其实最关键的就是这一句话，前面的有些多余。 ====Example End==================================================== 复用和外购考虑 实际上，关于 本系统的宏观复用方面的对系统结构的影响应该已经在“系统结构的考虑”一节中详细描述了。 所以本节要描述的内容，主要是具体说明： a) 本系统分解得到的哪些子系统不再重新开发，而是直接复用或外购得到。 b) 得到 a)的复用或外购决策的理由（一般在论证说明文档中加以论证说明）。 c) 对 a)的组件的未来的维护方式。 d) 本系统分解得到的哪些子系统将作为标准组件来开发（共将来的复用）。 一般来说，本节的内容关注于本系统分解得到的各子系统的复用和外购问题，而不要涉及子系统内部部件的复用和外购，各子系统内部的复用和外购要求可以在各子系统的需求 说明书中加以描述。 由于公司模块化工作的要求，本节必写，如果本节没有内容需要写，可以写“无”。 ===Example Begin==================================================== 例 复用和外购考虑 由于本系统的构架上保持了基本维持了标准构架（详见“系统结构的考虑”一节中的说明），在这种情况下，在设计时表 所列的各子系统有直接复用或外购。 考虑到将来的复用需要，本系统计划将表 所列的各子系统模块化，以供将来其他项目或产品复用。 表 序号 子系统名称 复用 /外购 理由 维护方式 备注 1 AAA 硬件子系统 复用 见《 XXX 论证说明》 节 被本项目使用后，将不再随 XX模块库的变化而引起本项目变化（即分支不再合并） 2 BBBB 硬件子系统 外购 见《 XXX 论证说明》 节 3 CCC软件子系统 复用 见《 XXX 论证说明》 节 本项目使用后，不再随 YY项目的变化而引起本项目变化（即分支不再合并） XXX 系统方案 〈 〉 机密 ▲ 本文中的所有信息均为 江苏鸿信系统集成公司苏州分公司 内部信息，不得向外传播。 14 表 序号 子系统名称 提交模块名称 检索关键词 理由 1 XXXX 硬件子系统 XXXX 单板 …… …… 2 YYYY 软件子系统 YYYY 软件系统 …… …… ====Example End==================================================== 6 构架说明 本章需要清晰地描述本系统的构架的总体概貌。 特别是要说明本系统的组成结构，即都有哪些组件（子系统或模块）、组件间、组件和系统外都有哪些接口。 本章的目的，是使读者对系统的组成有个总体上清晰了解。 在“接口说明”一章中，会具体说明每个接口详细信息，在“设计原理”一章中，会具体说明得到这些个分解结果的 原因。 下面根据图 的示意图来说明子系统和接口的各种种类。 软件子系统 软件子系统硬件子系统 硬件子系统结构子系统①② ②③③④⑤ ⑤⑥ ⑥ 图 构成一个产品的组件，一般会有下面几种类型： a) 结构子系统 一般单个机架的结构就是一个结构子系统（包含风扇，但不包含风扇控制部分）。 b) 硬件子系统 硬件子系统通常为单板级，一般在系统方案中将硬件功能直接划分到硬件单板。 硬件功能单板、电源板和背板都属于某种硬件子系统。 c) 软件子系统。 一般某单板上某处理器上运行的软件或软件中比较大的组件都属于软件子系统。 d) 软件模块 一般比较小的软件组件，可以不需要继续细化可以直接。