safehome软件体系结构设计

合集下载

福科斯EAVS系列大型视频接警中心管理平台介绍

福科斯EAVS系列大型视频接警中心管理平台介绍（一）1 平台系统性能概述通过多年的技术沉淀和市场磨合，基于整个平台系统的目标定位和用户需求更加人性化特点，在开发过程中我们将贯彻可靠性、可扩展性、可运营性、安全性、人化性等设计理念，现向您隆重介绍这款我司已经在多个电信公司运营的系统平台功能特点。

该平台同样适用于公安局大型联网服务管理中心。

1.1高可靠性美安“家庭安全监控平台”智能接警管理运营平台适时处理报警控制主机传来的报警信号，并经计算机调集数据库信息，将案发时间、地点、警情类别、户主XX、、工作单位和现场平面图在电子地图上显现出来，打印机则都能打印，为了确保能及时正确处理报警信息，保证设备长时间不间断运行，控制中心采用了多线制与设备备份工作相结合的方式，使用总线传输报警信号，并同时开通设备，以保证在同一时间点发生两起以上警情同时报警，也能将信号毫无遗漏的显示与处理。

1.2高可用性1、实时自动分类显示报警信息，操作简单直观；2、强大的统计报表功能，综合条件查询和打印需要的数据报表非常方便，如用户资料、事件报告、系统日志和出警单等；多级地图功能，用户可自行绘制防区图，自由设置不同的报警热点图标，自由设置是否跟随报警信息弹出下一级用户地图，对报警点实现准确定位；3、直观的通讯监控：通过软件界面，可以实时直接监控计算机同接警卡是否通讯正常；4、用户信息迅速锁定：简易浏览用户信息，无须繁杂操作；5、支持多种文本（WORD、EXCEL、文本）输出，方便对资料的备份、编辑。

1.3高扩展性1、兼容目前流行的各种通讯协议，CSFK、Ademco Contact ID、Ademco4+2 express等等，确保了接警平台的超强可扩展性。

2、支持同时多串口通讯：可以同时兼容多台接收机报警。

3、超强的系统兼容性：可以根据实际需求，自定义不同的报警编码方案，最大程度满足前端不同的报警主机的要求。

4、由于本项目在短期内的需求变化不大，但随着类似业务的不断推进，在以后运营中可能会出现更多的变更需求，系统将不断发展完善，所以在设计时充分考虑到以后阶段的功能需求，设计良好的接口。

Safehome前景与范围文档

目录1项目前景 (4)1.1前景陈述 (4)1.2必要性与可行性分析 (6)必要性 (6)可行性 (6)1.3用户群与客户代表 (9)2用例、功能与范围 (10)2.1使用场景 (10)正常的使用场景 (10)特殊情况及异常现象 (10)2.2功能列表 (11)2.3范围 (13)1项目前景1.1前景陈述当今世界，物欲横流，正如眼前我们坚持的“五个重庆”即“宜居重庆”、“畅通重庆”、“森林重庆”、“平安重庆”和“健康重庆”发展目标，可以真实的看出和反映出人们越来越追求更舒适、更安逸、更便捷、更安全、更人性、更健康的方向发展。

随着大量采用电子技术的家用电器面市，住宅电子化出现，将家用电器、通信设备与安保防灾设备各自独立的功能综合为一体后，形成了住宅自动化概念。

由于通信与信息技术的发展，出现了对住宅中各种通信、家电、安保设备通过总线技术进行监视、控制与管理的商用系统，就这样Safe home这种智能的智能家居系列装置系统呼之欲出。

另外人们的生活也是不断提高和完善的，为了让生活的方式更加的简明安逸，以及适应各项技术水平及工具的电气化电子化，也有了一定的趋势将统一为一体的群体电器有一个较为集中的管理和超控，更便捷的方式完成各种生活所需，也就像构建我们数字化校园一样，把各种项目综合统一为一个平台减少各项操作的所浪费的时间，各个项目更好的配合。

这些都是社会发展到一定程度的必然趋势，我们的项目也是紧跟时代的步伐，不被时代所淘汰，顺应事物，顺应自然发展，以人为本，满足住户需求而发展，所以我们构建一个智能家居Safe home管理平台使之称为一个数字化家园。

基于中国社会当前对于智能家居方面各项工作的进展不是十分明显，依然缺乏大量的设计思考和实际的项目实践经验，而这一项目又势在必行，必然是未来社会上对于衣食住行中的住方面发展的一个趋势，所以对于这一领域的研究应该尽早并且深入的研究和实现，以便在智能公寓之风袭来之时，站在一定高度上来看待和对待这个项目，上帝不是也偏爱有准备的嘛！对于具有前瞻性的项目我们一定要抓住机遇，迎接挑战，进而在未来的发展和竞争中占据不可否认的和令人瞩目的地位。

safehome软件需求建模和分析

目录1.需求模型 (2)1.1场景建模 (2)1.1.1 用例列表 (2)1.2用例 (2)1.2.1 安装解除系统 (2)1.2.2 解除系统： (4)1.2.3 初始化检测 (5)1.2.4 检测火灾 (6)1.2.5 检测漏水 (7)1.2.6 检测煤气泄漏 (8)1.2.7 检测非法入侵 (10)1.2.8 监测 (11)1.2.9 下雨自动关窗 (12)1.3类模型 (13)1.3.1 System类模型： (13)1.3.2 Floorplan 类建模： (14)1.3.3 Sensor类建模： (15)1.4流模型： (15)1.4.1 SafeHome安全功能的环境层DFD (15)1.4.2 SafeHome安全功能的第一层DFD (16)1.4.3 精化消息和状态处理的第二层DFD (16)1.4.4 精化指令数据 (16)1.4.5 精化指令修改 (16)1.4.6 精华激活/解除系统 (17)1.5行为模型： (17)1.5.1system类的状态图： (18)1.5.2Floorplan类的状态图： (19)1.5.3Window/Door Sensor类的状态图： (19)1.5.4 somke sensor类的状态图： (20)1.5.5cosensor类的状态图： (20)1.6用例活动图： (21)1.6.1 安装系统活动图： (21)1.6.2 卸载系统活动图： (22)1.6.3 初始化检测活动图： (23)1.6.4 检测火灾活动图： (24)1.6.5 检测烟雾活动图： (25)1.6.6 检测漏水活动图： (26)1.6.7 检测非法入侵活动图： (27)1.6.8 监视活动图： (28)1.6.9 下雨关窗活动图： (29)1.7用例泳道图： (30)1.7.1 安装系统泳道图： (30)1.7.2 解除系统泳道图： (31)1.7.3 初始化检测泳道图： (32)1.7.4 火灾监视泳道图： (33)1.7.5 漏水监测泳道图： (34)1.7.6 煤气泄漏监测泳道图： (35)1.7.7 监视非法入侵泳道图： (36)1.7.8 监视泳道图： (37)1.7.9 下雨自动关窗泳道图： (38)1.需求模型1.1场景建模1.1.1用例列表1.2用例1.2.1安装解除系统安装系统：1.2.2解除系统：1.2.3初始化检测1.2.4检测火灾1.2.5检测漏水1.2.6检测煤气泄漏1.2.7检测非法入侵1.2.8监测1.2.9下雨自动关窗1.3类模型1.3.1System类模型：1.3.2 Floorplan 类建模：1.3.3 Sensor 类建模：1.4 流模型：1.4.1 SafeHome 安全功能的环境层DFD Door typestartCoordinates stopCoordinates nextDoordetermineType() draw()1.4.2SafeHome安全功能的第一层DFD1.4.3精化消息和状态处理的第二层DFD配置信息1.4.4精化指令数据1.4.6精华激活/解除系统1.5行为模型：1.5.1system类的状态图：门为关着1.5.3Window/Door Sensor类的状态图：1.5.4somke sensor类的状态图：1.5.5cosensor类的状态图：1.6用例活动图：1.6.1安装系统活动图：1.6.2卸载系统活动图：1.6.3初始化检测活动图：1.6.4检测火灾活动图：1.6.5检测烟雾活动图：1.6.6检测漏水活动图：1.6.7检测非法入侵活动图：1.6.8监视活动图：1.6.9下雨关窗活动图：1.7用例泳道图：1.7.1安装系统泳道图：1.7.2解除系统泳道图：1.7.3初始化检测泳道图：1.7.4火灾监视泳道图：1.7.5漏水监测泳道图：1.7.6煤气泄漏监测泳道图：1.7.7监视非法入侵泳道图：1.7.8监视泳道图：1.7.9下雨自动关窗泳道图：。

智能家庭安全系统架构设计

智能家庭安全系统架构设计随着科技的日益发展，家庭智能化已经成为了一个趋势。

越来越多的人开始将家庭进行智能化改造，从家电到安全系统，都开始采用智能技术。

其中，智能家庭安全系统的发展应用，已经为生活带来了很大的便利和安全保护。

那么，智能家庭安全系统架构设计中到底需要考虑哪些因素呢？一、安全系统架构的重要性智能家庭安全系统是指应用智能化技术，进行安全保护管控的一体化系统，在最大程度上保障家庭安全。

能够为家庭和住户提供全面的防护和安全监控，为快节奏的生活带来了更多的安全保障，可以让住户避免日常生活中的各种安全隐患。

而怎么达到这样的目的？安全系统架构是其中非常重要的一个方面。

可以将50%的家庭安全风险避免在设计中解决。

因此，架构的能力和职责，是成功实现智能家庭安全保护的关键。

二、智能家庭安全系统架构设计原则1.一致性原则。

安全性系统必须是按照一定的标准进行构建和实现，且能够在相应的技术和管控能力上遵循统一的标准和规范。

2.可扩展性原则。

在整个系统设计过程中，必须要考虑后期的可扩展性需求。

尤其是在技术更新频繁、快速演进的现在，需要设计出基于不同技术和不同应用环境下的可扩展的系统。

3.灵活性原则。

需要能够以用户需求为出发点，实现更多的个性化设置，满足住户的个性化需求。

4.安全性原则。

整个系统设计必须以安全为基点，充分考虑在智能家庭设备和传感器之间的安全保护控制，并防范黑客攻击等网络威胁。

三、智能家庭安全系统的主要架构设计模式1.信息采集智能家庭安全系统首先是一个信息采集的系统。

通过社区情报和家庭内外联网设备统计，每一个设备的状态，来全面采集住户家庭的全貌。

智能设备技术和传感器技术的发展、轻薄化带来的巨大的技术优势将支撑信息采集的推进。

2.信息处理智能家庭安全系统被认为是一个数据驱动的系统，因此该系统需要具备很好的数据管理和处理能力。

它懈怠数万，懈怠亿万数据点及其相应属性，能“智能化”分析、比较、搜索等，以便有效地使用和单一处理。

软件工程课程设计报告-SafeHome项目报告

SafeHome 项目报告组员：郑帅林郑晓东施凯凯夏跃谈小龙高凯峰撰写人：全体组员完成日期：2011 年 6 月1 日，需求分析1．引言1.1 编写目的1.2 编写背景1.3 参考资料2. 任务概述2.1 任务目标2.2 系统及用户特点3．假定和约束4．需求规定4.1 软件功能说明4.2 对功能的一般性规定4.3 对性能的一般性规定4.4 故障处理要求4.5 其他专门要求5 ．运行环境规定5.1 设备1. 引言1.1目的编写本文档，目的在于明确用户的需求。

通过对用户需求的分析，以精确的软件架构设计，为需求建模和测试提供依据。

在小组内合理分工，使小组的每一个成员能够明白项目最终的项目特点。

\.2冃^景我们的研究表明，住宅管理系统市场以每年40%的速度增长。

我们推向市场的首个SafeHome功能将是住宅安全功能，因为多数人都熟悉“报警系统”，所以这将更容易销售。

住宅安全检测功能应该为各种不希望出现的“情况”提供保护，如非法入侵、火灾、漏水、一氧化碳浓度超标等等。

该功能将使用无线传感器监视各种情况的发生，其最主要的特色是用户远程监控住宅的情况同时户主可以编程控制住宅监控系统。

系统具有一定程度的智能性，系统可以在异常情况时自动通过拨打设定的电话信息联系监控部门1.32. 任务概述2.1目标通过设计软件工程的学习方法，主要使用visual C++技术，以Acess为数据库开发程序。

全中文软件界面，操作简便明了；系统数据库初始数据的设置可支持表单格式数据输入；支持电子地图显示，能够在小区总平面图和住户房型图上实时反映系统的报警状态，可声光指示报警点地址，记录报警时间、警情类别、处警情况等；报警时能自动弹出报警对话框，具有报警语音提示和报警确认功能；具有多种记录存储：报警记录、报警确认记录、布防记录、撤防记录、系统日志记录等；并可按住户、报警类型、报警时间、布、撤防记录、家居报警等进行分类查询等。

2.2 系统（或用户）的特点本软件主要有2 个参与者，房主（用户），配置管理人员（类似房主，但扮演不同角色）。

安全智能家居系统设计与实现

安全智能家居系统设计与实现随着科技的不断发展，智能家居已经成为人们生活中不可或缺的一部分。

而在这个领域中，安全智能家居系统的开发和实现显得尤为重要。

本文将从设计和实现两个方面来探讨安全智能家居系统的相关内容。

一、设计1. 安全智能家居的需求分析在设计安全智能家居系统之前，首先需要对用户的需求进行分析。

这包括用户对安全性的要求、对家庭环境的认知以及对智能家居系统的使用习惯等方面。

只有深入了解用户的需求，才能够开发出更符合用户需求的安全智能家居系统。

2. 系统架构设计在设计安全智能家居系统的架构时，需要考虑到安全性、便捷性、可靠性和可扩展性。

这些因素有利于系统的使用和维护，也能够增加系统的发展空间。

例如，一个好的架构设计应该能够支持对家庭环境的实时监控和数据采集，而且还能够通过云端存储、定时备份等方式来保障数据的安全性和完整性。

3. 硬件及软件实现方案安全智能家居系统是由硬件和软件共同组成的。

在硬件方面，需要选择高质量的设备来实现系统的各种功能，如智能摄像头、智能门锁、传感器等。

在软件方面，需要根据系统的需求开发出相应的应用程序，用来控制和监测各种硬件设备。

二、实现1. 控制中心的搭建与配置控制中心是安全智能家居系统的核心部分，用于对各种硬件设备的控制、数据的处理和传输等。

在搭建控制中心时，需要考虑系统的可扩展性和稳定性，同时还需定期更新和维护相关的软件和硬件设备。

2. 硬件设备的接入与调试在接入和调试硬件设备时，需要考虑到安装位置、设备之间的联动关系、以及防范设备受损等方面。

需要保证硬件设备的稳定运行，并进行必要的保养和维修。

3. 应用程序的开发与测试应用程序是联系控制中心和硬件设备的桥梁，需要开发具有良好用户体验的应用程序。

在开发过程中，需要注意固件的稳定性和兼容性，并通过测试来确保应用程序的质量和安全性。

结语：通过设计和实现，安全智能家居系统能够为人们提供更加便捷和安全的生活环境。

未来，随着技术的不断进步和人们对生活质量的不断追求，安全智能家居系统将会在更多的领域得到应用和发展。

智能家庭安全系统的设计与实现

智能家庭安全系统的设计与实现随着科技快速发展，智能家居系统逐渐走进了人们的生活中。

与此同时，智能家庭安全系统也开始被人们广泛关注和使用。

智能家庭安全系统不仅可以保护家庭安全，还可以提高生活的舒适度和智能化程度。

本文将探讨智能家庭安全系统的设计与实现。

1.基本功能智能家庭安全系统的基本功能包括监控、报警、防护等。

其中，监控是最基本的功能之一。

智能家居系统应该安装在家庭内部，例如摄像头、电子锁等。

这些设备可以通过网络与用户的手机相连接，实时监控家庭的环境并向用户提供相应的信息反馈。

在发生异常事件时，智能家庭安全系统会第一时间向用户发送警报信息并迅速防范。

2.系统架构智能家庭安全系统的系统架构包括硬件层、软件层、接口层等。

硬件层主要包括各种传感器、摄像头、电子锁等设备。

系统软件层主要包括数据采集、处理、存储等功能，用于实现系统的核心功能。

最后，接口层是系统架构的重要组成部分，包括与用户的手机等设备存储、通信等功能的接口。

3.技术实现实现智能家庭安全系统需要掌握多种技术。

其中，需要重点掌握的技术包括数据采集、处理、传输、存储等方面。

数据采集方面，需要使用传感器等设备对环境进行实时监控，收集各种数据。

数据处理方面，需要使用机器学习、数据挖掘等技术对采集的数据进行分析处理，同时进行规律的建模和预测分析。

数据传输方面，需要使用互联网等信息通信技术将数据传输到用户的手机等设备上。

数据存储方面，需要使用数据库等技术进行数据存储。

4.安全性智能家庭安全系统是一种保障家庭安全的系统，因此安全性也是系统设计的一个重要方面。

安全性需求包括身份认证、访问控制、数据加密等。

首先，身份认证是确保系统中用户的身份合法的必要手段。

通常采用的身份认证方式包括密码、刷脸等。

其次，访问控制是为了保护系统资源、防止非法访问而设置的一套规则。

最后，数据加密是将数据信息进行加密，并防止数据被非法窃取的一种有效手段。

综上所述，智能家庭安全系统的设计与实现需要掌握多种技术，包括数据采集、处理、传输、存储等方面。

体系结构设计

体系结构设计
• 原型（类似于类）是表示系统行为元素的一种抽象。这个原型集提供了一个抽象集，如果要对系统结构化，就必须要对这些原型进行结构化建模，但原型本身并不提供足够的实施细节。因此，设计人员通过定义和细化实施每个原型的软件构件来指定系统的结构。这个过程不停地迭代，直到获得一个完善的体系结构。
1.1 系统环境的表示
• 在体系结构设计层，软件体系结构设计师用体系结构环境图（Architectural Context Diagram，ACD）对软件与其外围实体的交互方式进行建模。图16-7 给出了体系结构环境图的一般结构。
上级系统使用于
使用参与者
目标系统
使用同级
依赖于
下级系统
图16-7 体系结构环境图
1.2 定义原型
• 很多情况下，可以通过检验作为需求模型一部分的分析类来获得原型。继续关于SafeHome住宅安全功能的讨论，可能会定义下面的原型：
– 结点。表示住宅安全功能的输入和输出元素的内聚集合，例如，结点可能由如下元素构成： 1）各种传感器；2）多种警报（输出）指示器。
– 探测器。对所有为目标系统提供信息的传感设备的抽象。 – 指示器。表示所有指示警报条件发生的报警机械装置（例如，警报汽笛、闪灯、响铃）的
控制器结点
通信
探测器
指示器
图16-9 SafeHome安全功能原型的UML关系
1.3 将体系结构精化为构件
• 在将软件体系结构精化为构件时，系统的结构就开始显现了。但是，如何选择这些构件呢？为了回答这个问题，先从需求模型所描述的类开始。这些分析类表示软件体系结构中必需处理的应用（业务）领域的实体。因此，应用领域是构件导出和精化的一个源泉。另一个源泉是基础设施域。体系结构必须提供很多基础设施构件，使应用构件能够运作，但是这些基础设施构件与应用领域没有业务联系。例如，内存管理构件、通信构件、数据库构件和任务管理构件经常集成到软件体系结构中。

4.结构化分析

专专
学学
选选选
1
选课
学学
年年
学学 (b)
选学
学学
功能建模语言：功能建模语言：DFD(Data Flow Diagram)
computer based system
结构化分析
input
output
external entity
外部实体:数据的产生者/ 外部实体:数据的产生者/消费者
process
处理(泡泡) 处理(泡泡)：数据变换者（将输入变为输出）
data flow
数据流：流经系统的数据，或为输入，或为输出数据存储：非即时使用的数据
data store
DFD图构造过程图构造过程
结构化分析
（1）建模第0层DFD 建模第0 将软件/系统描述为一个泡泡，将外部实体描述为一个方框，将软件/系统描述为一个泡泡，将外部实体描述为一个方框，从方框到泡泡的箭头描述实体产生系统所使用的信息，从泡从方框到泡泡的箭头描述实体产生系统所使用的信息，泡到方框的箭头描述实体使用系统产生的信息。泡到方框的箭头描述实体使用系统产生的信息。（2）将第0层DFD扩展为第1层DFD 将第0 DFD扩展为第1 扩展为第将第0 DFD的一个泡泡精化为第的一个泡泡精化为第1 DFD。在第1 DFD中将第0层DFD的一个泡泡精化为第1层DFD。在第1层DFD中，泡泡对应的是软件/系统的主要处理（或功能），），箭头对应各泡泡对应的是软件/系统的主要处理（或功能），箭头对应各处理间的数据流。处理间的数据流。 DFD图细化为子图细化为子DFD （3）DFD图细化为子DFD 精化过程持续进行，精化过程持续进行，直到每一个泡泡都执行一个简单的操作也就是说，直至每个泡泡所代表的处理都执行一个功能，，也就是说，直至每个泡泡所代表的处理都执行一个功能，并且该功能可以很容易地被实现。并且该功能可以很容易地被实现。 PSPEC描述最底层的所有处理（4）用PSPEC描述最底层的所有处理 PSPEC的内容可以包括叙述性正文、处理算法的程序设计语言 PSPEC的内容可以包括叙述性正文、的内容可以包括叙述性正文描述、数学方程、图或图表。描述、数学方程、表、图或图表。 PSPEC:处理规格说明（Process SPECification） PSPEC:处理规格说明（ SPECification）处理规格说明

SafeHome软件工程概要设计

实验报告（ 2012/ 2013学年第二学期）课程名称软件工程实验名称safehome 系统概要设计说明书实验时间2013 年 5 月12 日指导单位南京邮电大学计算机学院指导教师刘志鹏学生姓名班级学号实验小组成员学院(系) 通达学院专业计算机通信目录1 功能模块分析 (3)2 引言 (3)2.1 原始需求 (4)2.2 开发目的 (4)2.3 项目背景 (4)2.4 开发环境 (4)2.5 参考资料 (4)3 总体设计 (4)3.1 处理流程 (4)3.2 总体结构和模块外部设计 (6)3.2.1 总体结构 (6)3.2.2 外部模块设计 (11)3.3 功能分配 (12)3.4 接口设计 (12)3.4.1 外部接口 (12)3.4.2 内部接口 (15)4 数据结构设计 (15)4.1 逻辑结构设计 (15)4.2 物理结构设计 (17)4.3 数据结构与程序的关系 (17)5 运行设计 (18)5.1 运行模块的组合 (18)5.2 运行控制 (19)5.3 运行时间 (19)6 出错处理 (19)6.1 出错输出信息 (19)6.2 出错处理对策 (19)1. 功能模块分析序号模块名称功能简述住宅安全功能烟火监测，水位监测，行人运动，Internet网上修改等住宅监视功能通过摄像头对住宅监视、记录监视、Internet查看住宅管理功能用具、家电控制，度假/外出模式通信管理功能自动应答机功能，电子邮件，个人电话本，PDA连接2.引言2.1原始需求1)对safehome（住宅安全）系统进行设计建模，形成概要设计说明书，可以包括部署图、体系结构模型图、safehome部分系统的OCL描述等，以及相关的文字说明。

2)行为模型：某分析类的状态图、某功能的顺序图。

2.2开发目的根据《需求规格说明书》，在仔细考虑讨论之后，我们又进一步对《SafeHome》软件的功能划分、数据结构、软件总体结构、数据库有了进一步的认识。

安全汽车软件架构及安全汽车软件架构扩展点评汽车主机厂借鉴资料

Contract number: ITEA2 – 10039Contract number: Eurostars 6095 Safe-ESafe Automotive soFtware architEcture (SAFE) &Safe Automotive soFtware architEcture –Extension (SAFE-E)WP3.2.1 System and software models enhancementDeliverable D3.2.1.b:Final proposal for extension of meta-model for softwareand system modelingDue date of deliverable: 28/02/2013Actual submission date: 04/03/2013Organization name of lead contractor for this deliverable: AVLEditor : Elvira BiendlContributors : WT3.2.1 ParticipantsReviewer : Philippe Cuenot, Christoph Ainhauser; Markus Ortel, Hans-Leo Ross, Stefan VogetSafe-ERevision chart and history log1Table of contents (3)2List of figures (4)3Executive Summary (5)4Introduction (6)4.1Abbreviation, Special Terms, Akronyms (7)4.2Scope of the document (8)5System Package Specification (9)5.1Architectural Overview (9)5.1.1Hazard (10)5.1.2System (11)5.1.3Requirements (13)5.2Vehicle Level (14)5.2.1Item Definition (14)5.3Item Level (15)5.3.1Item Structure (15)5.3.2Safety Concept (17)5.4System Level (22)5.4.1System Design (22)6Implementation of the SAFE meta model (24)6.1Description of the SAFE meta-model (24)7Further Topics and Outlook (25)7.1.1Further Topics addressed to Package Requirement (25)7.1.2Further Topics on Item Level (28)7.1.3Further Topics on System Level (33)7.1.4Further topics on software level (40)7.1.5Further topics on hardware level (43)7.1.6Safety Validation (44)7.1.7Process Activities (44)8SAFE References (46)9Acknowledgments (47)Figure 1: SAFE meta-model (5)Figure 2: Scope of this Document (8)Figure 3: Architectural Overview (9)Figure 4: Interfaces to Hazard packages (10)Figure 5: Item Architecture overview (11)Figure 6: Interfaces to Requirements packages (13)Figure 7: Item Definition (14)Figure 8: Item Structure (15)Figure 9: Item Architecture (16)Figure 10: Safety Concept (17)Figure 11: Functional Safety Concept (18)Figure 12: Safety Measures (19)Figure 13: Safety Mechanism Structure (21)Figure 14: System Design (22)Figure 15: System-Array (23)Figure 16: SAFE meta-model (24)Figure 17: Outlook - Safety Requirements (27)Figure 18: Outlook - Item Environment (28)Figure 19: Outlook - Safety Element out of Context (SEooC) (29)Figure 20 : Outlook – Warning- and Degradation Concept (30)Figure 21: Outlook - Safety Measures (31)Figure 22: Outlook - Architectural Elements (32)Figure 23: Outlook - Decomposition (34)Figure 24: Outlook - Decomposition Function + Safety Mechanism (35)Figure 25: Outlook - Hardware Software Interface Specification (36)Figure 26: Outlook - Failure Propagation on system level (37)Figure 27: Outlook - Safety relevant failures (38)Figure 28: Outlook - Safety Analyses (39)Figure 29: Outlook - Interface to Software Package (40)Figure 30: Outlook - SW-System Architecture (41)Figure 31: Validation of external measures (44)The automotive industry uses more and more electronically controlled equipment in passenger cars that covers safety critical functionality. This leads to an increase of systematic failures and random hardware failures. Many of those failures are able to cause harm to people. These safety relevant failures shall be reduced to a level of unreasonable risk.ISO 26262 contains a guidance to avoid or mitigate the risks caused by safety relevant failures by providing appropriate requirements and processes.Currently the automotive industry is applying the requirements and processes specified in the ISO 26262 to provide new systems that are able to avoid the increasing risks or at least mitigate them to an appropriate level.The objective of this project is to analyze existing models like EAST ADL, SysML or AUTOSAR with the requirements given in the ISO 26262. The result of this analysis shall provide input for creation of a model that can be used to describe safety relevant systems in accordance with the requirements given in the ISO 26262.The solution that is described in this document is a draft version and shall be used as a starting point for discussion with other users of EAST ADL, AUTOSAR and ISO 26262 to find an effective solution that is easy to use in future development projects.Figure 1: SAFE meta-modelUp to now the automotive industry is already doing systematic failure analysis. But now theISO 26262 defines the need to avoid unreasonable risk. Therefore this kind of analysis is getting more important for future automotive development projects.The increasing use of electronically controlled equipment in the car leads to a changed behavior of the driver. Actions of the driver are guided by electronically controlled features, e.g. adaptive cruise control, electronic stability control, etc. All these features are able to help the driver to handle critical traffic situations. In a time of increasing number of cars on the road and increasing diversion for the driver during driving on the road, the driver trusts more and more in the new features of the car. All these topics lead to a changing of the common level of unreasonable risk.Based on the fact that unreasonable risk depends on a certain context according to valid societal moral concepts the automotive industry recognizes the challenge to handle the environmental context during development. The actual level of unreasonable risk in the target market of the vehicle in development is a new topic that shall be established in the already existing development process landscape.4.1 Abbreviation, Special Terms, AkronymsThe following table describes the special terms used in this document.4.2 Scope of the documentFigure 2: Scope of this DocumentThis document is created based on the requirements allocated to work task WT3.2.1. The allocation of the requirements is documented in the referenced deliverables D2.1.b [5]. Based on these requirements the specification of SAFE meta-model package system was created. It describes how to model a safety relevant item according to ISO 26262 by using already existing models like EAST-ADL and AUTOSAR.This chapter contains the specification of elements that are needed to fulfill the requirements allocated to WT3.2.1. The system package contains∙description of the different architectural level of an item∙Safety measures and safety mechanisms to avoid, mitigate, detect or control safety relevant failures∙Safety Architecture as a base for safety related analyses.The SAFE meta-model shall provide a solution that contains all relevant information about the safety relevant item in a consistent way. This can be reached by maintaining traceability between the safety goal analyzed in the Hazard Analysis and Risk Assessment and the technical solution described in the safety requirement documentation.5.1 Architectural OverviewThe following chapters describe the architecture of the SAFE meta-model packages that have interfaces to the system package.Figure 3: Architectural Overview5.1.1 HazardFigure 4: Interfaces to Hazard packagesThe safety goals are derived from hazardous events analyzed in the Hazard Analysis and Risk Assessment. Hazardous event is a combination of a hazard with an operational situation. The hazard analysis and risk assessment shall be executed based on the item definition. Further details according to Hazard Analysis and Risk Assessment are described in D3.1.1.b [6].The safety goals shall be∙described as functional safety requirements (see 5.1.3) and∙allocated to architectural elements (see 5.3.1.1) of the item.Safety Analyses shall be executed to identify safety relevant failures.A technical solution shall be defined to∙detect or control random hardware failures that have the potential to lead to a violation of the allocated safety goal and/or∙avoid or mitigate systematic failures that have the potential to lead to a violation of the allocated safety goal.5.1.2 SystemFigure 5: Item Architecture overviewThis package contains all needed artifacts to model a safety-related system in accordance to the requirements of the ISO 26262.The ISO 26262 is defined for safety-related systems that include E/E-systems that are installed in a series production passenger car with a maximum gross vehicle mass up to 3500 kg. Therefore the item is defined as a sub-system of a vehicle.Safety Analyses shall be done on different levels of the item architecture. Therefore the SAFE meta-model provides different architectural levels.Vehicle Level:The vehicle level is defined as the top level of the architecture. It describes the context of the item as well as the architectural splitting up to different items.Item Level:The item level describes the functionality of the item as well as the architectural splitting up to different systems.System Level:The system level describes the architectural elements of the system. A system contains at least one sensor, one controller and one actuator. The architectural splitting up of each sensor, controller, actuator to components is also part of this level. Another part of this level is the allocation of the different elements to software and hardware components. The architectural description of the interfaces between the Components is also part of this level.Software Level:The software level contains the architectural splitting up of each software component to software Units. The architectural description of the interfaces between the Software Units is also part of this level.Hardware Level:The hardware level contains the architectural splitting up of each hardware component to Hardware Parts. The architectural description of the interfaces between the Hardware Parts is also part of this level.5.1.3 RequirementsFigure 6: Interfaces to Requirements packagesSafety Requirements shall be categorized into different groups:∙Functional Safety Requirement∙Technical Safety Requirement∙ConstraintConstraints describe for example architectural assumptions or design constrains given from the higher level architecture.Further details to constraints see chapter 7.1.1.1. Detailed description of safety requirements see D3.1.2.b [7]5.2 Vehicle Level5.2.1 Item DefinitionAn Item is a system or array of systems to implement a function at the vehicle level that is able to cause harm to people inside or outside the vehicle.It shall be possible to describe interfaces, interactions and dependencies to other items. TheISO 26262 is focused on E/E-technologies, therefore the technology used to realize an item shall be categorized into E/E technologies and other technologies.Figure 7: Item DefinitionThe item as well as all external measures that are used as an argument for avoiding a violation of a safety goal shall be developed in accordance with ISO 26262.It shall be ensured that the specified external measures are implemented. The evidence of that shall be part of the safety validation. Further details related to this topic see chapter 7.1.6.5.2.1.1 Other technologiesIf items contain elements realized by other technologies, the implementation of those elements shall be ensured through measures outside the scope of ISO 26262. No ASIL shall be allocated to the elements allocated to other technologies.5.2.1.2 External MeasuresExternal Measures are safety measures implemented with E/E-technologies. They are applied in a5.3 Item Level5.3.1 Item StructureFigure 8: Item StructureThe item structure is used to generate the architectural overview of the item. The SAFE meta-model shall be able to refer to external models to implement systems that are part of the item.The Item can consist of one or more Systems. The following figure contains references to the system model given in EAST-ADL. Each system shall be represented by one EAST-ADL SystemModel. The item is represented by an EAST-ADL VehicleFeature.The safety-relevant System shall contain at least one sensor, one actuator and one controller. The SAFE meta-model describes them as Components. The Component level contains three different component types.FunctionComponentNon-system level element that is logically and technically separable described on a functional abstraction level.DesignComponentNon-system level element that is logically and technically separable described on a system design abstraction level.ImplementationComponentNon-system level element that is logically and technically separable. The Implementation Component is comprised of∙one or more than one hardware parts or∙one or more than one software units.5.3.1.1 Architectural elementsFigure 9: Item ArchitectureThe SAFE meta-model shall contain architectural elements.It shall be possible to∙add a preliminary description to the preliminary architectural elements∙allocate functional safety requirements to preliminary architectural elements∙create architectural elements as well as preliminary architectural elements∙allocate other technologies to an architectural element∙allocate external measures to an architectural elementFor further details to this topic see chapter 7.1.2.7.5.3.2 Safety ConceptFigure 10: Safety ConceptThe SafetyConcept shall be defined as a Top Level Element in the SAFE meta-model. One or more TechnicalSafetyConcepts can be derived by the FunctionalSafetyConcept.5.3.2.1 Functional Safety ConceptFigure 11: Functional Safety ConceptThe FunctionalSafetyConcept describes the safety measures that are needed to avoid violation of safety goals. It shall contain assumptions about necessary driver actions if needed to comply with at least one of the specified safety goals. It shall be available to start derivation of Technical Safety Requirements.The allocation and distribution of FunctionComponents that are used to realize SafetyMeasures shall also be part of the FunctionalSafetyConcept.If it is not possible to reach the safe state within the defined fault tolerance time interval a warning and degradation concept shall be specified for this case. For further details to this topic see chapter 7.1.2.4.5.3.2.2 Safety MeasuresFigure 12: Safety MeasuresThe ISO 26262 describes different kinds of safety measures:∙an activity to avoid or control systematic failures∙ a technical solution to detect or control random hardware failures∙ a technical solution to mitigate the harmful effects of random hardware failuresSafety measures can also contain requirements according to production, operation, service and decommissioning instructions, if they are needed to satisfy at least one allocated safety goal. Safety Measures are specified to satisfy the derived Safety Goals. They are described by functional safety requirement and are part of the Functional Safety Concept.During the derivation of functional safety requirements the preliminary architectural assumptions shall be taken into account.5.3.2.3 Technical Safety ConceptThe Technical Safety Concept is derived by the Functional Safety Concept. It contains the refinement of the functional safety requirements and the allocation to the architectural elements. The Technical Safety Concept shall contain requirements according to production, operation, service and decommissioning like∙Assembly instructions∙Safety-related special characteristics∙Requirements for insurance of proper identification of safety-relevant systems or system elements (e.g. labels)∙Verification methods/measures for production∙Service Requirements for diagnostic data or service notes∙Decommissioning requirementsif they are needed to fulfill at least one of the safety goals allocated to the item.The Technical Safety Concept refines the technical solution described in the Functional Safety Concept. The traceability shall be given from the safety goal, derived on vehicle level to the safety mechanisms specified in the Technical Safety Concept. The allocation of the safety mechanisms to hardware parts or software units shall be described in the Technical Safety Concept.Interfaces between safety relevant software units and safety relevant hardware parts that are needed to realize safety mechanisms shall be specified in the Hardware Software Interface Specification. Further details to this topic see chapter 7.1.3.3.5.3.2.4 Safety MechanismsFigure 13: Safety Mechanism StructureA safety mechanism is a technical solution implemented by E/E functions to detect faults or control failures that are able to lead to a violation of a safety goal. Safety mechanisms are derived by safety measures defined to avoid or control systematic failures or to detect random hardware failures. They are described by Technical Safety Requirements.The safety mechanism shall be allocated to the corresponding architectural element in the item architecture. That means software safety mechanisms shall be allocated to those software unit where they are implemented. Hardware safety mechanisms shall be allocated to the hardware parts that realize the mechanisms.Further details to the topic safety mechanisms see chapter 7.1.2.6.5.4 System LevelThe System Level contains the description and the architecture of the safety relevant system components.5.4.1 System DesignFigure 14: System DesignThe System Design shall contain the specification and the architecture of the safety relevant functionality. Technical Safety requirements contained in the Technical Safety Concept shall be allocated to the architectural elements in the item architecture on system level. Each architectural element inherits the highest ASIL of all allocated technical safety requirements. This classification shall be done automatically.If one of the architectural elements is divided into Sub-Elements the classification of the ASIL of the Sub-Elements shall be done by regarding the criteria for coexistence defined in ISO 26262 part 9 Chapter 6. If any of the defined criteria for coexistence is met, it shall be documented. For further details to this topic see chapter 7.1.3.6The target value for single-point fault metric and latent-point fault metric for the architectural element of the item architecture on system level shall be specified in the System Design. For further details to this topic see chapter 7.1.5.15.4.1.1 System ArrayFigure 15: System-ArrayIn the case that the item contains more than one system the item architecture on system level shall contain the architectural elements of all systems that are part of the item.Preliminary architectural assumptions that are already available during creation of the item architecture of the item shall be considered.Architectural Elements that are not finally verified or validated are called preliminary architectural elements.Figure 16: SAFE meta-modelThe SAFE meta-model is defined to create a traceable view of a safety relevant item in the meaning of ISO 26262. The starting point of this meta-model is the definition of the item which is the element under development called SAFE-Object.The SAFE-Object shall contain all SAFE-Elements that are able to influence the safety relevant behavior of the item under development.6.1 Description of the SAFE meta-modelThe description of all the artifacts contained in the SAFE meta-model is part of D3.5.b [11]This document contains a detailed explanation of the artifacts used in the SAFE meta-model.This chapter contains topics that will be discussed in further improvement steps of the SAFE meta-model. They address requirements that are allocated to the system and software package described in this document.Many of the topics addressed in this chapter provide input to other work tasks that are also part of the SAFE-project. Work task 6 for example will provide a series of guidelines for the use of the methods and tools developed in the preceding phases of the SAFE project.7.1.1 Further Topics addressed to Package RequirementThe following topics are part of the next iteration step of the requirement package.7.1.1.1 Categories of Safety RequirementsAs described in chapter 5.1.3 safety requirements contain functional and technical safety requirements. But there shall also be a solution for modeling of∙Quantitative requirements∙Constraints∙Requirements addressed to production process∙Requirements addressed to process activitiesQuantitative RequirementsA quantitative requirement is used to specify for example the random hardware failure target value of components or the target value for the diagnostic coverage of a safety mechanism. ConstraintsSafety relevant systems also contain constraints for example from higher architectural levels or given from the already existing design (e.g. environmental conditions, functional constraints, design constraints…).Requirements addressed to production processViolation of a safety goal can also be caused by topics addressed to the production process. In this case safety measures shall be defined to avoid this violation of a safety goal.Process RequirementsAs described in chapter 5.3.2.2 safety measures consist of activities and technical solutions. The technical solution is described by technical safety requirements, but the actual specification of the SAFE meta-model does not contain a category for requirements that describe activities that are needed to avoid safety goal violation.7.1.1.2 Safety requirement documentsThe actual specification contains parts of the safety requirement documentation: ∙Functional Safety Concept (see chapter 5.3.2.1)∙Technical Safety Concept (see chapter 5.3.2.3)∙System Design (see chapter 5.4.1)These three documents are defined as safety relevant work products in the ISO 26262. They shall contain safety requirements of the item. But there are further requirement documents needed to describe the safety relevant item throughout all its levels:∙Hardware Software Interface Specification∙Hardware Safety Requirement Specification∙Software Safety Requirement Specification.These requirement documents are also defined in ISO 26262 as safety relevant work products. The next improvement step of the SAFE meta-model shall provide a solution for modeling these three documents.7.1.1.3 Consistency of safety requirement documentsThe safety requirements that are specified in the safety requirement documents shall be consistent throughout the entire safety lifecycle. A consistency check of the safety requirements is defined as a process activity (see chapter 7.1.7)General characteristics of a safety requirement that are needed to execute a consistency check: ∙unambiguous and comprehensible∙atomic∙internally consistent∙feasible∙verifiable∙unique identifier remaining unchanged during the entire safety lifecycle7.1.1.4 Maturity of safety requirementsDuring the safety lifecycle the safety requirement can have a different level of maturity. To ensure an effective development process the maturity of the safety requirement shall be visible for the user. The maturity of the safety requirement can be shown by its status (e.g. new, accepted, rejected, clarify…)7.1.1.5 Usage of Safety RequirementsFigure 17: Outlook - Safety RequirementsTechnical Safety Requirements shall be specified in accordance with the following information that is already defined in System/Item scope:∙System/Item-Interfaces (part of the Functional Safety Concept external interfaces of the item such as communication and user interfaces∙environmental conditions or functional constraints∙system configuration requirementsAll System/Item scope specific information that is used to derive technical safety requirements shall be allocated to get the bidirectional traceability of source information and derived requirements.Technical Safety Requirements shall be allocated to the preliminary System/Item-Architecture that is part of the Functional Safety Concept. The preliminary architectural assumptions shall be considered by deriving the Technical safety requirements from the functional safety requirements.7.1.1.6 Verification of safety requirementsVerification of Technical Safety Requirements shall be done by appropriate analysis.Technical Safety Requirements shall be∙compliant to the requirements defined in the Functional Safety Concept∙consistent to the requirements defined in the Functional Safety Concept∙compliant to the preliminary architectural design∙consistent to the preliminary architectural design7.1.2 Further Topics on Item LevelThe following topics are part of the next iteration step of the system package.7.1.2.1 EnvironmentFigure 18: Outlook - Item EnvironmentThe environment of the item under development contains all elements that can influence the behavior of the item. In case of ISO 26262 the environment contains all elements that can lead to harm of people inside and outside of the vehicle that contains the item under development.All interactions of the item to its environment shall be specified that have the potential to influence the safety relevant funcitonality.If a vehicle contains more than one item, the model shall also contain the interactions between the items and the interfaces between each item and the environment.7.1.2.2 Development CategoryIt shall be possible to specify the category of the item under development in the first development phase. There are two different categories defined in the ISO 26262:∙new∙modificationNew:This development category shall be selected for items that are developed completely new. Modification:This development category shall be used if an already existing safety relevant item shall be modified for a new use case.The development category shall be selected once for an item development.7.1.2.3 Safety Element out of Context (SEooC)Figure 19: Outlook - Safety Element out of Context (SEooC)A safety element out of context (SEooC) is a system or an element of a system that is not developed for a particular vehicle. The safety element out of context shall be developed based on assumptions, that describe the context of the element for that it is developed. This could enable the development of generic elements.7.1.2.4 Warning- and Degradation ConceptFigure 20 : Outlook – Warning- and Degradation ConceptThe warning- and degradation concept is the specification of how to alert the driver of potentially reduced functionality and of how to provide this reduced functionality to reach a safe state.It is valid for the time interval that is needed to bring the system to the safe state with the defined restrictions of the system behavior. The warning and degradation concept shall be part of the functional safety concept if needed.The warning- and degradation concept shall contain:∙the transition to a safe state∙recovering from a safe state.∙fault detection and failure mitigation by switching to a safe state∙driver warning in order to reduce the risk exposure time to an acceptable interval7.1.2.5 Safety MeasureFigure 21: Outlook - Safety MeasuresAs described in chapter 5.3.2.2 safety measures contain technical solutions and activities. Activities shall be planned to avoid or mitigate systematic failures. Further details see chapter 7.1.7 7.1.2.6 Safety MechanismSafety mechanisms are described in chapter 5.3.2.4. The following topics shall be discussed during the next iteration step of SAFE meta-model.Category:Safety Mechanisms can be used to achieve different targets. These targets shall be defined for each safety mechanism by selecting on of the following categories:∙for detection, indication and control of faults caused inside the system/Item.∙for detection, indication and control of faults caused by external devices that have influence in the system/Item’s behavior.∙to enable and achieve or maintain the defined safe state∙to implement the warn- and degradation conceptContent:Safety mechanisms that are specified for achieving or maintaining the safe state shall have the following attributes:∙Transition to safe state∙Fault tolerant time interval∙Emergency operation interval, if the safe state cannot be reached immediately∙Measures to maintain the safe stateSafety mechanisms shall specify the behavioral description to achieve or maintain the safe state. Therefore it shall contain∙fault tolerance time∙operation modes∙emergency operation intervals∙functional redundancies∙safe state。

结构化分析与设计测试题

结构化分析与设计单元测试一、填空题1．数据字典是软件需求分析阶段的最重要的工具之一，其最基本的功能是（）。

2．软件的面向数据流的设计方法，利用其定义的映射方法可以把数据流图变换成软件结构：在映射中，一般将数据流分为（）和事务流两种。

3．组成数据流图的四个主要成分是数据的源点/终点，（）、（）和（）。

4．数据流图和数据字典共同构成了系统的（）模型，是需求规格说明书的主要组成部分。

5. 数据字典的内容包括六项：（）、（）、（）、（）、（）、（）。

6. 结构化设计方法中，要把数据流图转换成软件结构，若某个加工将它的输入流分离成许多发散的数据流，形成许多加工路径，并根据输入的值选择其中一个路径来执行，这种特征的DFD称为（）数据流图。

二、判断题1. 对于DFD图的划分，主要依赖设计人员的经验，一切都应根据设计人员的经验确定。

2．逻辑输入数据流是离物理输入端最远，且沿同一输入路径输入的数据流。

3．数据流图从数据传递和加工的角度，以图形的方式描述数据流从输入到输出的传输变换过程。

三、选择题1. 关于数据流图正确的描述是（）。

A．数据流图是结构化系统分析的主要工具。

B．在数据流图中，*号标识相邻的数据流只取其一。

C．加工是以数据结构或数据内容作为加工对象的。

D．数据流图的主图中必须包括全部四种基本元素。

2．程序流程图（框图）中的箭头代表( )。

A.数据流B.控制流C.调用关系D.组成关系3．从心理学角度看，对数据流程图的数据处理泡进行分解，一次分解为多少个泡为宜。

（）A. 3±1B. 7±2C. 15±1D. 18±24.按软件生命周期方法设计软件的过程中，画数据流图属于下面哪个阶段的工作（）A. 需求分析B. 概要设计C. 详细设计D. 软件维护四、简答题1.什么是结构化分析？“结构化”体现在哪里？2.为什么数据流图要分层？3.变换分析设计与事务分析设计有什么区别？简述其设计步骤。

运用SAFE软件进行板类构件进行设计

1. 在“分析”的“设置”选项中检查最大网格尺寸的设置 2. 在“参数-选项”中检查“自动融合”的偏差 3. 是否有软件锁； 4. 检查来源于线性弯矩的点荷载的个数 5. 对齐构件的点和边 6. 用输出“F2K”文件清理板中额外的单元
设计中常见问题
开始剪力模型、从其他软件转入文件、荷载输入单位不对应；荷载方向不正确忘记检查.log文件；忘记检查.out文件,检验模型的输入输出平衡性；混淆薄板和厚板的区分：
变形图
板内力图及板带划分参考
板带划分参考
板内力图
板带划分
板带划分参考
板带划分
注意检查设计组合是否正确！！
SAFE中设计弯矩取值注意
板带弯矩图
SAFE 文件菜单
填写正确的文件名称、路径
然后按此按钮
应用EXCEL形成弯矩包络图
弯矩包络图
填写正确的文件名称、路径
指定属性的优先次序刚度/实际尺寸刚度实际尺寸符号及方向的规定线平面内弯矩赋值板带的划分 SAFE中设计弯矩取值注意中设计弯矩取值注意常见运行错误信息设计中常见问题
指定属性的优先次序
o o
指定属性的优先权是给最后画的单元优先次序
洞口>柱子>柱帽>板
o o
o
板中洞口具有第一优先权复杂板在修改板属性后保存，重新打开用三维视图检查，以保证正确。注意属性板块和加荷附加板块的区别。
1.
2. 3. 4.
厚板考虑了剪切变形，当板跨长与厚度比大于8至10时应使用薄板。
检查记录表
检查记录是必须的
谢谢大家
检查
运行
取内力
配筋
图纸
SAFE 菜单

safehome系统概要设计说明书

SafeHome概要设计说明书文档名称：概要设计说明书项目名称：Safehome管理系统项目负责人：程凯项目规划：程凯资料搜集：龚梅鑫，蒋启明，袁湘莉，程凯报告制作：蒋启明，龚梅鑫，袁湘莉，程凯完成日期：2011年4月18日星期一开发单位：南京邮电大学通达学院班8组目录1引言 (3)1．2背景 (3)1．3定义 (3)1．4参考资料 (4)2总体设计 ................................................ 错误！未定义书签。

2．1需求规定........................................................................................ 错误！未定义书签。

2．2运行环境........................................................................................ 错误！未定义书签。

2．3基本设计概念和处理流程 (4)2．4结构................................................................................................ 错误！未定义书签。

2．5功能需求与程序的关系 (8)3 接口设计 (8)3．1系统接口 (8)3．2外部接口 (9)3．3内部接口 (9)4运行设计 (9)4．2运行逻辑组合 (9)4．2运行时间 (9)5系统数据结构设计 (9)5．1逻辑结构设计要点 (9)5．2物理结构设计要点 (10)6系统出错处理设计 (10)6．1出错信息 (10)6．2补救措施 (10)1引言1．1编写目的之前《需求规格说明书》已经完成并提交。

对于SafeHome系统我们进入第二阶段设计————概要设计。

编写这份概要设计报告的目的在于对整个系统的总体设计进行一个大概的描述和设计。

SAFE 架构指南

SAFE 架构指南网络位置：安全数据中心2018 年 4 月3 5 8 9 141625 2628目录概述业务流程威胁安全功能架构安全数据中心 15受攻击面人员 16设备 17网络 18应用 21多站点数据中心 24总结附录建议设计 26建议组件概述安全数据中心是一个网络位置 (PIN)，公司在该位置集中管理数据并提供业务服务。

数据中心包含成百上千个根据应用、区域和其他方法划分的物理和虚拟服务器。

本指南介绍数据中心的业务流程以及用于保护数据中心的安全方法。

安全数据中心是 SAFE 网络中的六个位置之一。

SAFE 是一种整体方法，以安全 PIN 对物理基础设施进行建模，并且以安全域代表网络的各个运营方面。

安全数据中心架构指南包含以下内容：•数据中心的业务流程• 数据中心面临的威胁和相关安全功能• 业务流程安全架构• 设计示例和部件清单图 1 SAFE 的关键之处。

SAFE 提供了将网络安全简化为基础设施的网络安全位置 (PIN) 和安全域的关键之处，以提供操作指南。

业务流程安全数据中心为公司用户提供业务服务。

它是将公司业务流程联系在一起的中心目的地和中转区域。

• 在内部，分支机构、园区和远程位置的员工需要访问应用、协作服务（语音、视频和邮件）和互联网。

系统在数据中心内以及数据中心之间进行东西向通信。

• 服务提供商和合作伙伴等第三方需要远程访问应用和设备。

• 客户访客流量在途中转移到互联网边缘。

图 3 数据中心业务使用案例采用颜色编码来定义其流向。

职能控制措施职能控制措施是来源于业务流程技术方面的常见安全考虑因素。

安全应用应用需要足够的安全控制措施来实施保护。

安全访问服务器和设备安全访问网络。

安全的东西向流量数据在内部、外部安全移动或安全移动至第三方资源。

安全远程访问为公司网络外部的员工和第三方合作伙伴提供安全远程访问。

安全通信邮件、语音和视频通信连接到公司控制之外的潜在威胁，并且必须加以保护。

图 4 数据中心业务流程根据其所呈现的风险映射到职能控制措施。