求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
第一部分:SEBoK介绍
SEBoK 简介
系统工程导论
SEBoK 用户和用途
第二部分:系统工程基础
系统基础
系统方法在工程系统中的应用
系统科学
系统思维
用模型表示系统
第三部分:系统工程与管理
系统工程 STEM 概述
基于模型的系统工程 (MBSE)
生命周期过程简介
生命周期模型
概念定义
系统定义
系统实现
系统实施
系统集成
系统验证-1
系统验证-2
系统部署和使用
系统部署
系统操作
系统维护
Logistics
系统工程管理
技术规划
评估和控制
决策管理
风险管理
配置管理
信息管理
质量管理
度量管理
业务和任务分析
业务和任务分析
系统工程标准
相关标准
系统工程标准的应用
系统工程标准的校准与比较
服务的生命周期管理
第四部分:系统工程的应用
产品系统工程
服务系统工程
企业系统工程
Systems_of_Systems(SOS)
医疗系统工程
第五部分:启用系统工程
支持业务和企业执行系统工程
支持团队执行系统工程
支持个人执行系统工程
第六部分:系统工程相关领域
系统工程和环境工程
系统工程和工业工程
系统工程与地理空间/大地测量工程
系统工程和项目管理
系统工程和软件工程
系统工程与质量属性
第七部分:系统工程实施实例
系统工程实施示例:信息系统
系统工程实施示例:防御系统
系统工程实施示例:交通系统
系统工程实施示例:医疗系统
系统工程实施示例:空间系统
系统工程实施示例:管理系统
系统工程实施 : 矩阵示例
第八部分:新兴的知识
新兴的主题
 
 
目录
系统工程与质量属性
译者:火龙果Alice
1010 次浏览
5次  

每个系统都有一组属性,这些属性在很大程度上是系统作为一个整体的功能,而不仅仅是它的组成部分。安全、可靠、安全、抗电磁干扰、可用性和弹性等特性有几十种。这个知识领域(KA)描述了许多最重要的这类属性,以及它们是如何实现的。讨论这些属性的词汇并不标准。或者,它们被称为质量属性、非功能需求、能力和专长。在这个KA中,专业工程术语指的是一个系统所有质量属性的集合工程。

质量属性通常是相互依赖的,而不是交互的;例如,让一个系统更安全可能会让它更难使用,但也更安全。提高系统可靠性通常需要使用更昂贵的部件和添加冗余组件。因此,更高的可靠性通常意味着更高的成本来交付一个系统——这是另一个系统特性。然而,更高的可靠性可能意味着更低的维护成本——这是另一个系统特性。系统工程师通常会就系统属性做出许多决定并采取许多行动;例如,指定哪些属性对一个特定的系统是重要的,说明这些属性将如何测量,权衡冲突的属性,并验证一个系统具有指定的属性。Barry Boehm(2016)作为系统工程研究中心一个项目的负责人,引入了一种本体来描述系统质量属性,作为一种实现它们之间更智能权衡的方式,并理解这些交易对成本的影响。另外,请参阅关于质量管理的文章,以获得关于如何管理这些决策和行动的更多信息。

许多人认为专业工程是SE本身的一个分支领域;例如,他们认为安全工程、安全性工程、弹性工程等是SE的一部分。其他人则认为它们本身是独立的领域,与SE密切相关。无论哪种方式,他们的精通对系统工程师来说都是很重要的。这个KA包括几个专业工程领域的专题文章。一些文章将把本文的主题作为SE本身的子领域;其他人会将其视为一个密切相关但独立的领域。这种差异既反映了对这个问题的不同意见,也反映了SEBoK的文章是由各种各样的作者撰写的这一事实。

主题

SEBoK的每个部分被划分为知识领域(KAs),这是具有相关主题的信息分组。KAs又被划分为不同的主题。这个KA包含了以下主题的文章,按字母顺序显示:

  • 人力系统集成
  • 可制造性、可生产性
  • 系统承受能力
  • 系统硬件保证
  • 系统可靠性、可用性和可维护性
  • 系统的弹性
  • 系统抗电磁干扰
  • 系统安全

随着时间的推移,这个KA将扩展到添加关于其他质量属性的专题文章。

专业要求

系统工程团队必须确保关于质量属性的需求(也称为专业需求)根据它们对生命周期成本、开发进度、技术性能和操作效用的影响得到适当的审查。例如,安全要求可能会影响操作人员的工作站,电磁干扰要求可能会影响子系统之间接口的信号,体积要求可能会阻止使用某些材料来减轻子系统的重量。

专业工程一体化

将专业工程整合到一个项目或计划中是,或者应该是系统工程管理的一个主要目标。(Endler 2016, Kossiakoff et al. 2020)通过适当实施程序,系统工程过程的严谨性确保了专业领域在技术决策过程关键节点的参与。特别强调集成是必须的,因为给定的设计实际上可以在不考虑这些专业规程的情况下完成,当操作环境中出现未经检查的情况时,可能会导致系统无效或失败。

例如,人为因素的考虑可以有助于减少工作量,从而降低飞机驾驶舱、空中交通控制台或核反应堆站的操作人员的错误率。同样,在具有挑战性的物理环境中,如海洋中部或外层空间,或在安全关键环境中,如医院重症监护室或城市中心的交通控制系统,平均修复时间功能可以显著提高系统的整体可用性。专业工程需求通常表现为对整个系统设计空间的约束。系统工程的作用是平衡这些约束与其他功能,以协调总体系统性能。最终目标是生产一个系统,以可负担的价格为客户提供效用和有效性。

如图1所示,系统工程在集成传统领域、专业领域和定义系统设计的独特系统产品需求方面起着领导作用。这个集成过程的关系表示为三个过滤器之间的交互。

第一个过滤器是一个概念分析,利用传统的设计考虑(结构、电子、空气动力学、机械、热力学等)。第二个筛选器使用专业领域来评估概念方法,如安全性、可负担性、质量保证、人为因素、可靠性和可维护性、可生产性、包装、测试、物流和其他,以进一步的需求开发。通过这两个过程的设计方案要经过第三个筛选,包括设施设计、设备设计、程序数据、计算机程序和人员,以制定设计选择和进一步详细开发的最终要求。

图1。专业工程集成过程(USAF 2000)。由美国空军发布。

 

人力系统集成

人力系统集成(HSI)是“在系统、子系统、设备和设施的设计、开发、测试、生产、使用和处置过程中规划、使能、协调和优化所有与人有关的考虑的管理和技术领域”。”(SAE 2019)。

虽然全球工业都在使用HSI,但HSI是由美国国防部(DoD)发起的,是采办“总系统方法”的一部分。HSI的目标是“优化系统的总体性能(硬件、软件和人)、操作效率和适用性、生存能力、安全性和可承受性”。”(国防部2003年。)这篇文章本身关注的是国防部内部的HSI,尽管它的大部分适用于世界各地的其他政府和商业组织。

HSI活动必须在“系统开发的早期(在涉众需求生成期间)”开始,并持续地通过开发过程来实现最终系统解决方案的最大利益和大量生命周期成本节约。”(INCOSE 2015)。

人类健康指数通常包含以下七个领域作为综合考虑因素(尽管一些组织可能使用略有不同的集合):人力、人员、培训、人因工程、安全和职业健康、部队保护和生存能力以及宜居性。

概览

从历史上看,没有足够的系统工程资源用于确保人类与系统其他部分的适当集成。大多数项目都以技术为中心,通过培训来解决人的问题。技术系统难以使用和维护,导致大量人力和培训成本,降低了系统性能,增加了灾难性损失的风险,以及其他影响。

美国陆军在1986年通过人力和人员整合(MANPRINT)计划率先解决这一问题。MANPRINT强调,在整个系统采购过程中,将HSI域作为系统工程工作的标准部分加以考虑。此后,该方法被更广泛的国防部、其他军队和世界各地的文职政府机构采用。(波尔最早2003)。一些组织,特别是英国国防部,使用了“人为因素整合”(HFI)这个术语。

HSI应用系统工程过程、工具和技术,以确保在所有系统开发活动中,人为因素被给予适当的权重。HSI不应与人因工程(HFE)混淆;HFE是HSI的一个领域,主要研究人机界面的设计。HSI是关于技术、组织和人员的相互融合。

系统描述

人机交互不仅仅是人的因素、人机交互或系统工程。它是一组技术和管理流程,涉及多个领域的考虑和集成。此外,HSI还涉及复杂性分析和组织设计与管理。不同的组织以不同的方式表示HSI域,因为域的数量和名称与现有的组织结构一致。Booher(2003)首先提出了美国陆军最初的七个领域,即人力、人员、训练、人为因素工程、士兵生存能力、系统安全和健康危害。其他国家可能有不同数量的域名,名称略有不同,但是,域名的所有技术工作都是存在的。例如,英国国防标准(00-251)包括七个类似的领域:人力、人员、健康危害、培训、人为因素工程、社会/组织和系统安全。国防部指令(2017年国防部)中使用的7个领域,告诉如何操作国防部采办系统,如下:

1.人力决定运营、维护、培训及支援系统所需的人力及合约支援的最有效及具成本效益的组合。人力描述了为了操作、维护、支持和为系统提供培训而执行一项任务、多个任务或任务所需的人员数量和混合。人力因素是那些定义人力需求的变量。这些变量包括工作任务、操作/维护率、相关工作量和操作条件(如操作员受伤风险)(DAU 2010)。

2.人员:根据现有的人员清单或分配到任务的人员,决定和选择适当的认知、身体和社会能力,以培训、操作、维护和维持系统。人事因素是指恰当地完成工作任务所需的人的能力(即认知能力、身体能力和感官能力)、知识、技能、能力和经验水平。人员因素用于开发系统操作人员、维护人员、培训人员和支持人员的职业专长(DAU 2010)。人员的选择和分配对一个系统的成功至关重要,这取决于各种与工作相关的需求所建立的需求。

3.培训:开发高效、经济的选择方案,提高用户能力和维护技能,对操作人员和维护人员进行个人、集体和联合培训。培训是个人或集体通过发展他们的认知、身体、感觉和团队动态能力来获得或增强预先确定的工作相关知识、技能和能力的学习过程。“培训/教学系统”整合了培训概念和策略,以及后勤支持的要素,以满足操作、维护和支持系统所需的人员绩效水平。它包括用于提供学习体验的“工具”,如基于计算机的交互式课件、模拟器、实际设备(包括在实际设备上嵌入的培训能力)、工作绩效辅助工具和交互式电子技术手册(DAU 2010)。

4.人为因素工程:将人的特性整合到系统定义、设计、开发和评估中,以在操作条件下优化人的系统性能。人因工程(HFE)主要涉及设计与用户群体(DAU 2010)的物理、认知和感觉能力相一致的人机界面。它的重点是确保系统设计与人类用户兼容。HFE考虑所需的人工任务,以及操作、控制、维护和支持设备、系统或设施的用户人员的感官、知觉、心理和身体属性。HFE的目标是在预期的生命周期成本水平内优化人-系统性能。HFE领域的考虑范围很广,包括工作区域的设计和布局、用户设备界面、自动化和决策辅助设备的使用,以及正常、非正常和紧急情况。

5.安全与职业健康: 在确定系统设计特性时考虑环境、安全和职业健康,以提高工作绩效,并将操作人员和维护人员患病、残疾、受伤和死亡的风险降至最低。安全考虑的是系统的设计特点和操作特点,以最大限度地减少造成伤害性事故的人为或机器错误或故障的可能性(DAU 2010)。安全还包括与系统的操作、维护和存储相关的管理程序和控制。职业健康因素是指那些系统设计特征,旨在将受伤、急性或慢性疾病或残疾的风险降到最低,并/或降低操作、维护或支持系统的人员的工作绩效。普遍存在的问题包括噪音、化学安全、大气危害(包括与密闭空间进入和缺氧有关的危害)、振动、电离和非电离辐射,以及可能造成慢性疾病和不适的人为因素问题,如重复性运动疾病。许多职业健康问题,特别是噪音和化学品管理,与环境影响重叠。人为因素强调造成慢性疾病和不适风险与职业健康因素重叠(DAU 2010)。

6.力量保护和生存能力: 冲击系统设计(例如,出口,生存能力),以保护个人和单位免受直接威胁事件和事故,包括化学,生物和核威胁。部队保护和生存能力是HSI领域,在暴露于敌对情况或环境期间和之后促进系统操作和人员安全。部队保护是指为减轻针对人员(包括家庭成员)、资源、设施和关键信息的敌对行动而采取的所有预防性措施。生存能力是指系统和/或配备系统的人员能够避免或承受人为的敌对环境,而不会对其完成指定任务的能力造成破坏。生存能力因素包括降低自相残杀风险、检测和被攻击概率的系统设计特征,使人员能够承受人为的敌对环境,而不放弃任务或目标,或遭受急性慢性病、残疾或死亡。生存能力属性是那些有助于载人系统生存能力的属性(DAU 2010)。

7.宜居性 : 建立和执行对个人和单位的物理环境、人员服务和生活条件的要求,以防止或减轻对业绩、生活质量和士气产生不利影响的风险条件,或降低招聘或保留的质量。宜居因素是指维持使用者的士气、安全、健康和舒适所必需的生活和工作条件。它们直接有助于提高人员效率和完成任务,并常常排除征聘和保留问题。例如照明、空间、通风和卫生;噪音和温度控制(即采暖和空调);宗教、医疗和食品服务的可用性;还有靠泊,洗澡和个人卫生。可居住性包括满足人员需要的系统、设施(临时的和永久的)和服务的特征。宜居性因素是指能够使人员的士气、安全、健康和舒适程度足以维持最大程度的人员效能、支持任务表现并避免人员留用问题的生活和工作条件(DAU 2010)。

纪律管理

在承包商项目组织中,人力系统集成商通常是高级工程人员中的一员,向系统工程主管或总工程师报告。

HSI 活动记录在系统工程管理计划 (SEMP) 中。 较大的项目可能有一个独立的 HSI 计划 (HSIP),与 SEMP 兼容并被 SEMP 引用。 HSI 活动根据项目和项目生命周期的需求量身定制(NASA 2016)。

大多数项目在客户和承包商之间实施一个联合 HSI 工作组。 这使得共享优先事项、知识和努力成为可能,以使每个小组都能实现其目标。

领域关系

互动

互动包括:

  • SE:HSI 是系统工程工作的一个组成部分,集成商在所考虑的系统的整个生命周期内参与所有相关的系统工程活动。
  • HSI 领域专家:领域专家与人力系统集成商合作以实现 HSI 目标,尽管这可能是也可能不是直接报告关系。
  • 承包商和客户可能各有一个人工系统集成商和各种领域专家; 每个角色都应在适当的范围内与其对应人员进行协作。
  • HSI 领域专家可以根据项目的需要作为完全参与者或顾问参与集成产品团队 (IPT)/设计团队。
  • HSI 与可靠性、可用性和可维护性 (RAM) 有许多共同之处。 集成商和/或领域专家可以酌情与 RAM 专家合作。
  • 集成商和/或领域专家应与测试和评估团队合作,以确保 HSI 在测试和评估活动中得到体现。
  • HSI 与物流和可支持性有许多共同点,集成商和/或领域专家可以酌情与该团队合作。

依赖项

HSI 取决于足够的工作范围和项目的授权。 适当的计划和领导支持是一个关键的推动因素。

纪律标准

注意:这些是与 HSI 实践相关的标准,而不是每个 HSI 领域都有自己的标准和实践。

  • 美国国家航空航天局 (NASA)。 2015. 人体系统集成从业者指南。 美国国家航空航天局/SP-2015-3709。 休斯顿:约翰逊航天中心。
  • SAE 国际。 2019. 人力系统集成的标准实践。 SAE6906。 宾夕法尼亚州沃伦代尔:SAE International。
  • 英国国防部。 2016. 国防标准 00-251:防御系统的人为因素集成。 Glasglow:国防设备和支持。
  • 美国军队。 2015. 条例 602-2:系统采集过程中的人力系统集成。 华盛顿:陆军部总部。
  • 美国国防部。 2011. 数据项描述:人体系统集成计划。 DI-HFAC-81743A。
  • 美国海军。 2017. Opnav 指令 5310.23A:海军人员人力系统集成。 华盛顿:海军作战部长办公室:海军部。

人事注意事项

HSI 由人力系统集成商执行。 集成商是系统工程团队的一部分,负责进行与人员和组织考虑相关的系统工程,并协调 HSI 领域专家的工作。

HSI 使用与系统工程相同的技术和方法,并额外考虑系统的非材料方面。 因此,集成商必须精通 SE 流程,并对每个领域都有实际的了解。 集成商不需要是任何领域的专家。

人力系统集成商的职责包括:

  • 为 SEMP 提供输入和/或创建与 SEMP 和项目生命周期兼容的 HSI 计划 (HSIP)(NASA 系统工程手册 2016)
  • 根据项目和系统生命周期的需要调整 HSI 工作的范围
  • 确保在所有计划和工程活动中适当考虑 HSI 领域
  • 协助领域人员规划领域活动
  • 促进领域任务的执行和领域之间的协作
  • 在领域之间进行权衡以优化 HSI 目标的实现
  • 从性能、可持续性和成本的角度优化领域对采购计划的影响
  • 整合领域活动的结果,并从整体 HSI 的角度将它们呈现给采办计划的其余部分
  • 促进 HSI 范围内的领域之间以及 HSI 与程序的其余部分之间的交互
  • 跟踪、状态和评估在计划执行过程中出现的 HSI 风险、问题和机会

指标

人类系统有效性测量

有效性度量 (MOE) 是与任务目标完成情况相对应的度量。 MOE 测量具有代表性的任务环境中的系统性能,包括具有代表性的用户。 有效性通常是通过硬件、软件和人工组件的组合来实现的,因此通常没有特定于 HSI 的 MOE。

MOE 可以分解为性能度量 (MOP) 和适用性度量 (MOS)。 可能存在 HSI 特定的 MOP 和 MOS。 例如,防空雷达的 MOE 可能是正检测概率,MOP 代表雷达的有效分辨率,MOP 代表操作员识别目标的能力。 确保识别相关的 MOP 和 MOS 并将其纳入建模、模拟、测试和评估工作是人力系统集成商的责任。 集成商和领域专家可以酌情为这些努力做出贡献。

楷模

恒指过程模型

HSI 与通用系统工程共享通用系统工程模型; 例如 SE Vee 过程模型。 此外,存在许多特定于 HSI 的模型和过程。 一个特别好的资源是 Ehrhart 和 Sage 的“A User-Centered Systems Engineering Framework”(在 Booher 2003 中)。

人类绩效和领域模型

对于认知、行为、人体测量学、力量、疲劳、注意力、态势感知等,存在多种人类表现模型。此外,每个 HSI 领域都存在多种模型。 集成商应该对可用的模型类型和适当的应用有很好的了解。 在使用基于模型的系统工程的项目中,系统模型应该包括人。 集成商应确保足够的保真度以满足项目的需要。 在设计过程中以及在产品的整个生命周期中,都应该鼓励在环仿真。

可制造性、可生产性

可制造性和可生产性是工程专业。 必须对用于构建系统的机器和流程进行架构和设计。 制造和生产的系统工程方法是必要的,因为制造设备和流程的成本有时会超过正在建造的系统(Maier 和 Rechtin 2009)。 可制造性和可生产性可能是竞争系统解决方案概念之间的区别,因此必须在研究早期以及最终设计解决方案的成熟期间加以考虑。

概述

正在构建的系统可能旨在成为一种或多次复制。 每种情况的制造系统都不同,并且与正在构建的系统类型相关。 例如,单板计算机的制造与汽车的制造大不相同。 生产涉及重复构建设计的系统。 多个生产周期需要考虑生产机器的维护和停机时间。

制造和生产工程涉及专门为系统构建量身定制的类似系统工程过程。 可制造性和可生产性是决定制造和生产难易程度的系统的关键属性。 虽然可制造性只是易于制造,但可生产性还包括生产任务的其他方面,包括包装和运输。 这两个属性都可以通过结合考虑整个系统生命周期的适当设计决策来改进(Blanchard 和 Fabrycky 2010)。

系统负担能力

根据 MITRE (2014),负担能力是“为所需投资提供资金的能力”。 “如果能够在(可能的)可用预算范围内部署足够数量的解决方案以满足任务需求,那么解决方案是负担得起的。” INCOSE (2015) 提供了更深入的定义。 如果系统性能、成本和进度约束在系统生命周期内得到平衡,同时任务需求与战略投资和组织需求相一致,那么系统就可以负担得起。 可负担性设计是将可负担性视为设计特征或约束的实践。

日益增加的竞争压力和资源稀缺要求系统工程 (SE) 提高可负担性。 最近的几项举措已将可负担性作为他们的首要技术优先事项。 他们还呼吁高度重视技术研究——即提高系统自主性和提高人类绩效——这些技术有望降低劳动力成本,提供更高效的设备以降低供应成本,并创建可延长使用寿命的适应性系统具有成本效益。

然而,成本和进度估算的方法并没有显着改变以应对这些新的挑战和机遇。 有一个明确的需求:

  • 分析成本、进度、有效性和弹性之间权衡的新方法;
  • 调整优先事项和可交付成果以满足预算和时间表的新方法;
  • 更实惠的系统开发过程。

所有这一切都必须在技术、竞争、运营理念和劳动力特征迅速变化的背景下完成。

概述

从历史上看,成本和进度估算已与技术 SE 权衡分析和决策审查脱钩。 大多数模型和工具都侧重于评估成本进度绩效或技术绩效,而不是两者之间的权衡。 同时,组织及其系统工程师通常关注可负担性,以最大限度地降低购置成本。 然后,他们被吸引到最简单的优先方法中,从而取得早期成功,但代价是被困在增加技术债务和生命周期成本的脆弱、昂贵的更改架构中。

有两个迹象表明,系统工程需要改变,即INCOSE SE 手册 现在将可负担性作为评估需求的标准之一(INCOSE 2015),并且 SE 有一种趋势,即更加关注可维护性、灵活性、和进化(Blanchard、Verma 和 Peterson 1995)。

粗心的人有陷阱。 自治系统会经历几种危险的故障模式,包括:

  • 正反馈导致的系统不稳定性 ——智能体感知到一个参数达到了控制极限,并在另一个方向上给系统一个强大的推动力,导致系统迅速接近另一个控制极限,导致智能体(或另一个)给出它在原来的方向上更强大的推动力,依此类推
  • 自我修改自主代理, 在多次自我修改后失败——这些故障很难调试,因为代理的状态一直在变化
  • 自主代理在人类操作员对系统控制决策的常识推理方面表现不佳 ,因此往往会得出错误的结论并做出关于控制系统的错误决策
  • 多个代理在控制系统方面做出相互矛盾的决定 ,并且缺乏理解矛盾或协商解决方案的能力

围绕其最常见的变化源(Parnas 1979)对系统架构进行模块化是可负担性的关键 SE 原则。 这是因为当需要更改时,它们的副作用包含在单个系统元素中,而不是波及整个系统。

这种方法需要三个进一步的改进:

  • 重新关注系统需求,不仅关注当前需求的快照,还关注最可能的需求变化来源或演变需求;
  • 监控和获取有关最常见的变化来源的知识,以更好地识别进化需求;
  • 评估系统提议的架构,以评估它支持演进需求的程度,以及初始快照需求。

这种方法可以扩展到产生几个新的实践。 系统工程师可以

  • 确定产品系列或产品线之间的共性和可变性,并开发用于创建(和发展)通用元素的架构,并使用 用于插入可变元素的插件兼容接口;(Boehm、Lane 和 Madachy 2010)
  • 推断以输入、输出和假设为特征的面向服务的系统元素的原则,这些元素可以很容易地组合成没有预期变化源的系统;
  • 开发智能或自主系统类别,其许多传感器可识别所需的变化,其自主代理可在微秒内确定和影响这些变化,或者比人类更快,不仅减少反应时间,而且减少操作所需的人力系统,从而提高可负担性。

人事注意事项

自治系统需要人的监督,参与的人需要更好的趋势分析和趋势可视化方法(尤其是不希望出现的趋势)。

对于自主系统,还需要将重点从生命周期成本扩展到总拥有成本,其中包括失败的成本,包括销售、利润、任务效率或人类生活质量的损失。这进一步需要根据所考虑的系统增加的价值来评估可承受性。原则上,这涉及评估系统在多个作战场景中的任务效能和弹性方面的总体拥有成本。然而,确定适当的场景及其相对重要性并不容易,尤其是对于多任务系统。通常,最好的方法是混合场景评估和一般系统属性评估,如成本、进度、性能等。

对于这些系统属性,对于给定属性,不同的成功关键利益相关者将具有不同的偏好或效用函数。这使得在候选系统解决方案之间进行相互满意的选择成为一个困难的挑战,涉及解决利益相关者之间的多准则决策分析(MCDA)问题(Boehm和Jain,2006)。这是一个众所周知的问题,有几个悖论,比如阿罗的不可能定理描述了无法保证几个利益相关者之间的相互最优解决方案,以及利益相关者偏好聚合中的几个悖论,其中不同的投票程序产生不同的获胜解决方案。尽管如此,利益相关者群体仍需要做出决策,各种谈判支持系统使人们能够更好地了解彼此的效用函数,并达成双方满意的决策,在这些决策中,没有人能得到他们想要的一切,但每个人至少都和他们在当前系统中一样富裕。

另请参阅系统分析,了解技术设计领域的成本和可承受性。

系统硬件保证

本文描述了硬件保证的原则,特别是与系统工程相关的原则。它是SE和质量属性知识领域的一部分。

概述

系统硬件保证 是一组系统安全工程活动(有关更多信息,请参阅 系统安全 ),用于量化和提高电子设备在其整个生命周期中按预期运行且仅按预期运行的信心,并管理已识别的风险。 术语硬件 指电子元件,有时也称为集成电路或芯片。 作为设计、制造和后期制造、包装、测试等多阶段过程的产品,它们必须在广泛的环境下正常运行。 硬件组件——单独和集成到子组件、子系统和系统中——具有弱点和漏洞,可以利用。 弱点是设计、架构、代码或实现中的缺陷、错误或错误。 漏洞是在使用环境中可利用的弱点(Martin 2014)。

硬件保证旨在最大限度地降低与硬件相关的风险,这些风险可能导致对功能的对抗性利用和颠覆、假冒产品和技术优势的丧失。 挑战包括硬件架构、集成电路、操作系统和应用软件的复杂性和复杂性不断提高,再加上供应链风险、新攻击面的出现以及某些组件和技术对全球资源的依赖。

在确定问题和适用的缓解措施后,硬件保障提供了一系列可能的活动和流程。 在组件级别,硬件保证侧重于硬件本身以及用于设计和制造它的供应链; 在子组件、子系统和系统级别,硬件保证包含与组件集成的软件和固件。

为了应对复杂的硬件架构、对硬件的对抗性攻击日益复杂以及供应链的全球化,增强对硬件信任的工程努力已经增加。 这些因素引起了人们对安全性、机密性、完整性和可用性以及硬件的来源和真实性的严重关注。 系统的“信任根”(NIST 2020)通常包含在硬件组件的流程、步骤和层中,并贯穿整个系统工程开发周期。 系统硬件保证侧重于硬件组件及其与软件和固件的互连,以在组件和系统的整个生命周期内降低硬件正常功能或其他损害的风险。

硬件组件的生命周期问题

硬件保证应应用于组件生命周期的各个阶段,从硬件架构和设计,到制造和测试,并最终将其包含在更大的系统中。 然后,对硬件保障的需求在其整个运行生命周期中持续存在,包括维护和处置。

随着半导体技术提高电子元件的复杂性,它增加了对“烘烤”保证的需求。 在架构、设计和制造过程中产生的风险在运营阶段难以解决。 与芯片之间的互连相关的风险也是一个问题。 因此,必须在生命周期中尽早改进硬件保障状态,从而减少与在系统生命周期后期“修复”组件相关的成本和进度影响。

典型硬件生命周期的概念概述(图 1)说明了组件生命周期的各个阶段,以及它们在其中运行的子系统和系统。 在每个阶段,多方和进程都会贡献大量变量和相应的攻击面。 因此,存在损害硬件以及它们运行的​​子组件和系统的可能性; 因此,应在识别风险时应用相应的缓解措施。

图 1. 组件生命周期。 (SEBoK 原创)

硬件组件的价值和降低风险的相关成本在生命周期的每个阶段都会增加。 因此,尽早识别和缓解漏洞非常重要。 以后发现和修复缺陷需要更长的时间,从而增加了用“纠正”设计替换硬件的复杂性,这会产生系统集成问题。 除了节省成本外,早期纠正和缓解还可避免创建运营系统的延迟。 在整个生命周期中定期重新评估与硬件组件相关的风险至关重要,尤其是在操作条件发生变化时。

鉴于遗留硬件和设计及其相关供应链,系统维护期间的硬件保证是一项新挑战。 在长期存在的高可靠性系统中,硬件保障问题因组件过时和采购减少而加剧,从而增加了与假冒和从灰色市场收购相关的担忧。

按预期发挥作用且仅按预期发挥作用

详尽的测试可以检查系统功能是否符合规范和期望; 但是,检查意外功能是有问题的。 消费者有一个合理的期望,即购买的产品将按照宣传的方式运行并正常运行(在特定条件下安全可靠)——但消费者很少考虑产品中是否内置了附加功能。 例如,具有网络会议功能的笔记本电脑附带一个网络摄像头,该摄像头在启用时会正常工作,但如果网络摄像头在关闭时也能正常工作,从而违反隐私预期怎么办? 鉴于最先进的半导体组件可能有数十亿个晶体管,“隐藏”功能可能会被对手利用。

需要设计阶段的硬件规格和信息来验证组件是否正常运行以支持系统或任务。 如果工程师创建的规范支持沿系统开发过程流动的保证,则可以通过公认的验证和确认过程为系统和任务验证“按预期运行”的概念。 “仅按预期发挥功能”也是捕获要求和规范以确保产品的设计和开发没有额外功能的结果。 例如,现场可编程门阵列 (FPGA) 包含高度可配置的可编程逻辑; 然而,可编程电路可能容易被利用。

给定硬件组件的规格,可以使用专门的工具和流程以高度的信心确定组件的性能是否符合规格。 正在进行研究工作以开发可靠的方法来验证组件不具有威胁保证或原始设计中未指定的功能。 尽管工具和流程可以测试已知弱点、操作漏洞和与预期性能的偏差,但目前无法确定或预测所有可能的异常行为状态。

数据和信息可用于验证组件的功能,应从包括设计人员、开发人员和用户社区成员在内的多个来源收集。 设计人员和开发人员可以深入了解组件的预期功能,并在部署之前提供用于验证其功能性能的测试。 将组件设计和开发信息与广泛的现场数据(包括第三方评估)合并,有助于确保组件正在执行指定的功能并且没有观察到意外的功能。

硬件风险

现代系统依赖于复杂的微电子技术,但硬件的进步如果不注意相关风险,可能会暴露关键系统、它们的信息以及依赖它们的人。 “硬件正在迅速发展,因此从根本上创造了新的攻击面,其中许多永远不会完全安全”。 (Oberg 2020)因此,必须通过动态风险概况对风险进行建模,并在整个概况中深入缓解风险。 硬件保障需要可扩展的缓解措施和策略,它们可以并且确实随着威胁的发展而发展。 硬件保证方法寻求量化和提高信心,使可能成为造成风险的漏洞的弱点得到缓解。

大多数硬件组件都是由拥有全球供应链的跨国公司进行商业设计、制造和插入到更大的组件中的。 了解复杂的全球供应链的来源和参与者对于评估与组件相关的风险至关重要。

源自无意或有意特征的操作风险根据特征的来源进行区分。 与商品、产品或物品相关的三个基本操作风险领域是:不符合质量标准、恶意污染商品和假冒硬件。 假冒产品通常作为合法产品提供,但事实并非如此。 它们可能是翻新的或仿制的物品,看起来像是原件、重新标记的产品、过度生产的结果或被合法生产商拒绝的不合格生产部件。 假冒风险和不合标准的质量为恶意软件插入提供了途径,并对整体系统性能和可用性产生了潜在影响。

未能遵循包括安全和安保标准在内的质量标准,尤其是在设计方面,可能会导致无意中引入的特性或缺陷。 这些可能是由于错误、遗漏或不了解未来用户如何出于恶意目的操纵功能而发生的。 为特定目的而有意引入的功能也可能使硬件在其生命周期的某个时刻容易受到间谍活动或对硬件的控制。

量化和提高可信度

硬件保障的量化是一项关键的技术挑战,因为设计者、制造商和供应链以及敌对意图之间的复杂相互作用,以及定义与硬件功能相关的“安全性”的挑战。 量化对于在项目预算和时间范围内识别和管理硬件风险是必要的。 它可以确定所需的硬件保证级别以及在整个硬件生命周期中是否可以实现量化。

当前量化硬件保证的方法改编自质量和可靠性工程领域,这些领域使用故障模式和影响分析 (FMEA) 等方法。 (SAE 2021) FMEA 是半定量的,并结合了概率硬件故障数据和专家的输入。 将 FMEA 用于量化硬件保证会受到阻碍,因为它依赖于为可能受金钱、恶意等动机的人类行为分配概率。在量化和加权用于生成风险矩阵和分数的因素时,专家意见通常会有所不同。 作为回应,最近的努力正试图开发减少主观性的定量方法。

博弈论分析(博弈论)是创建智能和理性决策者之间冲突与合作的数学模型。 (Myerson 1991) 模型包括动态、 与静态交互相反,攻击者和防御者之间的交互可以量化与对手、硬件开发人员和制造过程之间的潜在交互相关的风险。 (Eames and Johnson 2017)模型的创建迫使人们明确定义攻击场景并输入硬件开发和制造过程的详细知识。 该模型的输出可能包括基于对攻击者和防御者的成本效益约束对最有可能发生的攻击进行的排名。 (Graf 2017)结果可以使决策者能够就硬件保障做出定量权衡决策。

SAE AS6171 标准中介绍了另一种量化方法,该方法导致用于检测假冒/可疑微电子产品的置信区间。 (SAE 2016)信心基于了解与假冒相关的缺陷类型,以及检测这些缺陷的不同测试的有效性。 同样,可以开发硬件保证标准,通过针对已知漏洞目录进行测试来量化置信区间,例如 MITRE 常见漏洞和暴露 (CVE) 列表中记录的漏洞。 (MITRE 2020)

分布式账本技术 (DLT) 是新兴技术的一个例子,它可以采用标准化方法来量化硬件保证属性,例如数据完整性、不变性和可追溯性。 DLT 可与制造数据(例如尺寸测量、参数测试、过程监控和缺陷映射)结合使用,以利用组件出处和可追溯性数据提高防篡改能力。 DLT 还支持跨组织数据融合的新场景,为新类别的硬件完整性检查打开了大门。

管理风险

用于子系统和系统的特定组件的选择应该是在其预期使用环境中的性能风险和成本效益权衡评估的结果。 风险管理和缓解计划的目标是选择具有最佳整体运营风险降低和最低成本影响的缓解措施。 所需的硬件保证级别因组件使用的关键程度和使用它的系统而异。

在系统的典型开发生命周期(架构、设计、代码和实现)中,各种类型的问题都可能对所提供的硬件组件的操作功能构成风险。 这些风险包括无意(无意)的弱点或缺陷,以及出于财务动机或旨在更改功能的恶意组件可能无意或有意注入供应链的假冒产品。

在硬件保证的背景下管理风险旨在降低造成可被利用的攻击面的弱点的风险,同时提高实施抵抗利用的信心。 理想情况下,风险管理可以降低风险并将保证最大化到可接受的水平。 通常,风险是在后果的可能性以及缓解措施的成本和有效性的背景下考虑的。 然而,在硬件生命周期和组件供应链中不断发现新的对运营产生影响的风险。 同时,通常通过软件或固件来利用硬件弱点。 因此,为了最大限度地保证并最大限度地减少对运营产生影响的风险,必须考虑对所有组成部分进行深度缓解。 这凸显了动态风险概况的必要性。

制造后缓解的一个示例涉及在现场操作期间识别的新硬件风险。 动态风险概况可用于表征问题并识别可能的资源来解决可疑的组件功能。 此配置文件还可用于跟踪和解决其整个生命周期的风险,包括与过时相关的风险。 减轻这种硬件生命周期风险的一种方法是使用现有的可编程逻辑。

与软件补丁和更新一样,硬件上的新攻击面可能会通过所应用的缓解措施暴露出来,而且它们可能需要很长时间才能发现。 在上面的示例中,更新了可编程逻辑以提供新的配置来保护硬件。 在这种情况下,必须将硬件重新配置的访问权限限制在授权方,以防止未经授权的更新故意或意外引入弱点。 虽然可编程逻辑可能已经缓解了特定的攻击面或弱点类型,但需要额外的缓解措施来更彻底地降低风险。 这是深度缓解——多种缓解措施相互叠加。

在整个供应链中,关键信息可能会在不经意间暴露出来。 此类信息的暴露直接导致新攻击面的创建和利用。 因此,还必须评估供应链基础设施的弱点,并确保硬件组件的开发、使用和维护。 动态风险概况提供了一个框架,可以在整个硬件和系统生命周期中平衡风险和成本背景下的缓解措施。

系统弹性

弹性在 SE 领域是一个相对较新的术语,仅在 2006 年出现并在 2010 年普及。最近将“弹性”应用于工程系统导致对其含义的混淆和替代定义的扩散。 (一位专家声称,已经出现了超过 100 种独特的弹性定义。)虽然定义的细节将继续讨论和辩论,但这里的信息应该提供对弹性的含义和实现的工作理解,对于系统工程师来说已经足够了来有效地解决它。

概述

定义

根据牛津英语历史原则词典(OED 1973),复原力是“反弹或弹回的行为”。 该定义最直接适合材料变形后恢复原状的情况。 对于人造或 工程系统, 弹性 的定义 可以扩展为包括 在面对 中断时保持 能力的能力 . 美国国土安全部将弹性定义为“系统、基础设施、政府、企业和公民抵抗、吸收、恢复或适应可能造成伤害、破坏或丧失国家意义的不利事件的能力”。 (DHS 2017)一些从业者将弹性定义为仅包括遇到逆境后的系统反应,有时称为反应视角。 INCOSE 弹性系统工作组 (RSWG) 推荐了一个定义,其中包括在遭遇逆境之前采取的行动; 这被称为主动视角。

RSWG 推荐的定义是:弹性是在面对逆境时提供所需能力的能力。

手段的范围

在应用这一定义时,需要考虑实现复原力的方法范围:实现复原力的方法包括避免、承受和从逆境中恢复。 这些也可以被认为是复原力的基本目标(Brtis 和 McEvilley 2019)。 传统上,复原力包括从逆境中“承受”和“恢复”。 就工程系统而言,“避免”逆境被认为是实现弹性的合法手段(Jackson 和 Ferris 2016)。 此外,人们认为弹性应该考虑系统“进化和适应”未来威胁和未知未知的能力。

逆境的范围

逆境是可能降低系统所需能力的任何条件。 理想情况下,系统工程师应该考虑逆境的所有来源和类型; 例如来自环境来源,由于正常故障,以及来自对手、友方和中立方。 来自人类的逆境可能是恶意的或偶然的。 逆境可能会发生,也可能不会。 逆境可能包括“未知的未知数”。 下面讨论的实现弹性的技术适用于敌对和非敌对逆境。 值得注意的是,单个事件可能是多个逆境的结果,例如在试图从另一个逆境中恢复时犯下的人为错误。

实现弹性的分类法

通过考虑对其目标和技术的分类,可以促进实现弹性。 一个有用的基于目标的三层分类法包括:第一层,弹性的基本目标; 第二层,弹性目标的手段; 第三层,用于实现弹性的架构、设计和操作技术。 三层中的项目通过多对多关系关联。 (Brtis 2016) 和 (Jackson and Ferris 2013) 对弹性分类的工作汇总如下:

分类第 1 层:弹性的内在价值

三个目标揭示了复原力的内在价值:

  • 避免逆境
  • 承受逆境
  • 从逆境中恢复

分类法第 2 层:意味着目标本身不是目的

表 1 显示了一组目标,这些目标不如第 1 层中的那些基本目标,但能够实现第 1 层的目标:

表 1. 平均目标

• 适应性/灵活性 • 敏捷性 • 期待
• 约束 • 连续性 • 分解
• 进化 • 优雅降级 • 正直
• 准备 • 预防 • 重新架构
• 重新部署 • 稳健性 • 对情况的意识
• 宽容 • 转型 • 理解

分类第 3 层:实现弹性目标的架构、设计和运营技术

表 2 中的工程技术支持实现弹性目标。

表 2. 实现弹性目标的架构、设计和运营技术

• 吸收 • 适应性反应 • 分析监测和建模
• 边界执法 • 缓冲 • 复杂性规避
• 协同防御 • 欺骗 • 纵深防御
• 检测回避 • 分配 • 多元化
• 漂移校正 • 动态定位 • 动态表示
• 效果容差 • 人类参与 • 节点间交互和接口
• 最低权限 • 松耦合 • 模块化
• 中性状态或安全状态 • 非持久性 • 物理和功能冗余
• 权限限制 • 扩散 • 保护
• 重新调整 • 重新配置 • 可修复性
• 替代品 • 重组 • 细分
• 经证实的完整性 • 替代 • 威胁抑制
• 不可预测性 • 虚拟化

这些术语的定义可在 Brtis (2016) 和 Jackson and Ferris (2013) 中找到。 随着弹性域的成熟,手段目标以及架构和设计技术的列表将不断发展。

弹性过程

在系统中实现弹性需要执行分析和整体过程。 特别是,需要使用具有相关启发式的架构。 输入是期望的弹性水平以及威胁或破坏的特征。 输出是系统的特征,尤其是架构特征和元素的性质(例如,硬件、软件或人)。

工件取决于系统的域。 对于技术系统,将产生规范和架构描述。 对于企业系统,将产生企业计划。

分析和整体方法,包括架构技术,都是必需的。 分析方法确定所需的稳健性。 整体方法确定所需的适应性、耐受性和完整性。

一个陷阱是仅依靠一种技术来实现弹性。 深度防御技术表明,可能需要多种技术来实现弹性。

虽然在整个系统工程生命周期中都应考虑弹性,但在导致弹性需求发展的早期生命周期活动中考虑弹性至关重要。 一旦建立了弹性要求,就可以并且应该在整个系统生命周期中与贸易空间中的所有其他要求一起管理它们。 Brtis 和 McEvilley (2019) 建议将以下列出的具体考虑因素纳入早期生命周期活动。

  • 业务或任务分析流程
    • 定义问题空间应包括识别逆境和在逆境下对绩效的期望。
    • ConOps、OpsCon 和解决方案类别应考虑避免、承受和从逆境中恢复的能力
    • 替代解决方案类别的评估必须考虑在逆境中提供所需能力的能力
  • 利益相关者需求和需求定义过程
    • 利益相关者集应包括了解潜在逆境和利益相关者复原力需求的人。
    • 在确定利益相关者的需求时,确定在不利条件和退化/替代但有用的操作模式下对能力的期望。
    • 操作概念场景应包括弹性场景。
    • 将利益相关者的需求转化为利益相关者的要求包括利益相关者的弹性要求。
    • 利益相关者需求分析包括不利运营环境中的弹性情景。
  • 系统需求定义流程
    • 在识别需求时应考虑弹性。
    • 应从整体上解决实现复原力和其他逆境驱动的考虑。
  • 架构定义过程
    • 选定的观点应支持复原力的表示。
    • 弹性要求可以显着限制和指导可接受架构的范围。 弹性需求在用于架构选择时必须成熟,这一点至关重要。
    • 开发候选架构的个人应该熟悉实现弹性的架构技术。
    • 应从整体上解决实现复原力和其他逆境驱动的考虑。
  • 设计定义过程
    • 开发候选设计的个人应该熟悉实现弹性的设计技术。
    • 应从整体上解决实现复原力和其他逆境驱动的考虑。
  • 风险管理流程
    • 应计划风险管理以处理弹性活动确定的风险、问题和机会。

弹性要求

Brtis 和 McEvilley (2019) 调查了指定弹性要求所需的内容和结构。 弹性需求通常采用弹性场景的形式。 在 Conops 或 OpsCon 中可以有许多这样的场景线程。

以下信息通常是弹性要求的一部分:

  • 操作概念名称
  • 感兴趣的系统或系统部分
  • 感兴趣的能力 他们的指标和单位
  • 目标值; 即所需的能力数量
  • 场景期间的系统操作模式; 例如操作、培训、演习、维护和更新
  • 场景中预期的系统状态
  • 正在考虑的逆境、它们的来源和类型
  • 对系统及其度量、单位和价值的潜在压力
  • 与弹性相关的情景限制; 例如成本、进度、政策和法规
  • 感兴趣的时间框架和子时间框架
  • 弹性度量、单位、确定方法和弹性度量目标; 示例指标:所需能力的预期可用性、最大允许降级、最大降级长度和总交付能力。 可能有多个弹性目标; 例如阈值、目标和“尽可能有弹性”

重要的是,其中许多参数可能会随着场景的时间范围而变化(参见图 1)。 此外,单个弹性场景可能涉及多个逆境,这些逆境可能在整个场景中多次涉及。

图 1. 名义弹性情景参数的时间值。 (Brtis et al. 2021,经许可使用)

表示弹性需求的复杂性并不是直截了当的。 Brtis 等人。 (2021) 研究了这一挑战并推荐了弹性要求的模式。 他们推荐了三种形式的模式来满足不同受众的需求:(1) 自然语言,(2) 实体关系图(日期结构),以及 (3) SysML 的扩展。 用于表示弹性需求的自然语言模式示例如下:

<system, mode(t), state(t)> 遇到<adversity(t), source, type>,强加<stress(t), metric, units, value(t)> 从而影响<capability( t), metric, units> 在<scenario timeframe, start time, end time, units> 期间和<scenario constraints> 下,应针对<resilience metric, units, 确定方法实现<resilience target(t) (包括排除的影响)> >

负担得起的弹性

“负担得起的弹性”是指在弹性工程的生命周期成本和技术属性之间实现有效平衡。 这意味着在当前和不断变化的条件下面临逆境时提供所需的能力,以满足整个系统生命周期中多个利益相关者的需求。 负担得起的弹性的生命周期考虑不仅应解决随着时间的推移与已知和未知逆境相关的风险和问题,还应解决在已知和未知的未来环境中寻求收益的机会。

可承受弹性的技术属性包括对技术风险的潜在处理、可靠性、稳健性、灵活性、适应性、容忍度和完整性; 以及准备和避免、承受和从逆境中恢复的能力。 这通常需要平衡资金的时间价值与复原力的时间价值,以实现可承受的复原力,如图 2 所示。

图 2. 弹性与成本。 (Wheaton 2015,经许可使用)

一旦为每个关键技术属性确定了可承受的弹性水平,就可以通过标准技术确定这些属性的可承受水平的优先级,例如多属性效用理论 (MAUT) (Keeney and Raiffa 1993) 和层次分析法 (AHP) . (萨蒂 2009)

系统负担得起的弹性属性的优先级通常取决于领域; 例如:

  • 公共交通系统可能会强调安全以及满足监管要求和降低责任风险,并及时分配支出以匹配当前和未来的预算
  • 电子资金转账系统可能会强调网络安全,无论需要什么资金来满足监管要求和责任风险
  • 无人太空探索系统可能会强调生存能力,以承受以前未知的环境,通常有特定的(并且通常是有限的)近期资金限制
  • 电网可能会强调安全性、可靠性和满足监管要求,以及对发电和存储技术平衡变化以及配电和使用变化的适应性
  • 灾难的医疗能力可能强调对重大事件的快速适应能力,具有负担得起的计划、准备、响应和恢复水平,以满足公共卫生需求。 这种强调必须平衡潜在责任和关键紧急医疗实践的同时完成,例如分诊和“首先不伤害”。

领域关系

弹性与许多其他质量领域具有共性和协同作用。 示例包括可用性、环境影响、生存能力、可维护性、可靠性、操作风险管理、安全、安保和质量。 这组质量领域被称为损失驱动的系统工程,因为它们都关注系统开发和使用中涉及的潜在损失。 这些领域经常共享:考虑的资产、考虑的损失、考虑的逆境、需求以及架构、设计和流程技术。 这些领域必须相互密切合作,共享信息和决策,以实现整体方法。 追求损失驱动的系统工程的概念,它的预期收益,INCOSE 洞察 (2020 年)。

纪律标准

有两个标准突出了对弹性的洞察力:

  • ASISI (2009) 是关于组织系统弹性的标准。
  • NIST 800-160(Ross, R. et al. 2018)考虑了物理系统的弹性。

人事注意事项

人类是需要弹性的系统的重要组成部分。 这方面反映在杰克逊和费里斯(2013 年)确定的人在循环技术中。 人类做出的决定是由人类实时决定的。 Eyles (2009) 描述的阿波罗 11 号就是一个很好的例子。

指标

Uday 和 Marais (2015) 对弹性指标进行了调查。 确定的包括:

  • 故障持续时间
  • 恢复时间
  • 性能恢复与性能损失的比率
  • 恢复速度的函数
  • 中断和恢复操作前后的性能
  • 系统重要性度量

Jackson (2016) 针对十个不同案例研究中缺乏的原则,开发了一个衡量标准来评估四个领域的各种系统:航空、消防、铁路和配电。 这些原则来自 Jackson 和 Ferris (2013) 确定的集合,并以直方图的形式表示,绘制原则与遗漏频率的关系。 这些差距中的数据取自案例研究,在这些案例研究中,从引用的各种案例中的领域专家的建议中推断出缺乏原则。

Brtis (2016) 调查和评估了许多潜在的弹性指标,并确定了以下内容:

  • 最长停电期
  • 最长限电期
  • 最大停电深度
  • 能力的期望值:交付能力的概率加权平均值
  • 威胁弹性; 即提供的能力除以最低需要能力的时间积分比
  • 所需能力的预期可用性; 即对于给定的不利环境,所需的能力水平将可用的可能性
  • 弹性水平; 即在日益困难的逆境中提供所需能力的能力
  • 给对手的代价
  • 对对手的成本效益
  • 资源弹性; 即随着连续贡献的资产丢失而发生的能力下降

Brtis 发现可能需要多个指标,具体取决于具体情况。 然而,如果必须选择一个最有效的指标来反映弹性的含义,Brtis 建议它将是“所需能力的预期可用性”。 所需能力的预期可用性是所考虑场景中可用性总和的概率加权总和。 在其最基本的形式中,该度量可以在数学上表示为:

在哪里,

R = 所需能力的弹性 (Cr );

n = 一个上下文中详尽且互斥的逆境场景的数量(n 可以等于 1);

P i = 逆境情景i 的概率 ;

Cr(t) i = 情景i 期间所需能力的时间可用性: 如果低于所需水平,则为 0,如果等于或高于所需值,则为 1。 如果情况要求,这可能会呈现出更复杂的、非二进制的时间函数;

T = 感兴趣的时间长度。

系统抗电磁干扰

电磁干扰(EMI)是指当电子设备在射频(RF)频谱的电磁场附近时,对其运行的干扰。许多电子设备在强射频场的存在下无法正常工作。干扰可能会中断、阻碍或以其他方式降低或限制电路的有效性能。源可以是任何携带快速变化电流的物体,人工的或自然的。

电磁兼容性(EMC)是指系统、设备和设备能够利用电磁频谱在其预期的运行环境中运行,而不会因为电磁辐射或响应而遭受不可接受的退化或造成无意的退化的能力。它涉及到声电磁频谱管理的应用;确保无干扰操作的系统、设备和设备设计配置;以及能够最大化运营效率的明确概念和原则(DAU 2010,第7章)。

概述

光谱

每个国家都对其频谱的使用拥有主权,并且必须承认其他国家保留相同的权利。 必须有区域和全球论坛来讨论和解决邻国和邻近国家之间的频谱开发和侵权问题,否则这些问题可能难以解决。

拥有 193 个成员国的历史最悠久、规模最大、无疑也是最重要的此类论坛是在全球范围内管理频谱的联合国国际电信联盟 (ITU) 机构。 正如 NTIA 手册第 3 章所述,“国际电信联盟 (ITU)……负责国际频率分配、全球电信标准和电信发展活动”(NTIA 2011, 3-2)。 国际电联的广泛职能是国际电信的监管、协调和发展。

频谱分配过程由许多不同的国际电信地理委员会进行。 图 1 显示了全球范围内的各种国际论坛。

图 1. 国际和区域频谱管理论坛。 (SEBoK 原创)

分配频率非常复杂,如图 2 中的无线电频谱分配图所示。有时,商业实体会尝试使用实际分配给美国政府机构的频率,例如国防部 (DoD)。 当自动车库门供应商在位于政府设施附近的房屋上安装门时,发生了一起此类事件。 门的随意打开和关闭给供应商带来了本来可以避免的问题。

四个国际电联组织影响频谱管理(Stine 和 Portigal 2004):

  1. 世界无线电通信大会(WRC)
  2. 无线电规则委员会 (RRB)
  3. 无线电通信局 (RB)
  4. 无线电通信研究组 (RSG)

WRC 每四年召开一次会议,审查和修改当前的频率分配。 RB 登记频率指配并维护主国际登记簿。 RRB 批准无线电通信局用于登记频率指配和裁定成员国之间的干扰冲突的程序规则。 SG 分析地面和空间应用中的频谱使用情况,并向 WRC 提出分配建议。 大多数成员国通常会制定与无线电规则 (RR) 一致的国家频率分配政策。 这些法规具有条约地位。

美国频谱的双重管理

大多数国家只有一个政府机构来执行频谱管理职能,而美国有一个双重管理计划,旨在确保

  • 仅在考虑其对政府系统的影响后才能做出有关商业利益的决定; 和
  • 政府使用支持商业利益。

该计划的细节由 1934 年通信法制定,具体如下:

  • 联邦通信委员会 (FCC) 负责所有非政府使用
  • FCC 直接对国会负责;
  • 总统负责联邦政府的使用,并通过行政命令将联邦政府频谱管理委托给国家*电信和信息管理局 (NTIA); 和
  • NTIA 隶属于商务部长。

FCC 根据《联邦法规》第 47 条对所有非联邦政府电信进行监管。 例如,参见 FCC (2009, 11299-11318)。 FCC 由总统任命并经参议院确认的五名委员领导,任期五年。 委员会工作人员按职能组织。 六个运营局的职责包括处理许可证申请、分析投诉、开展调查、实施监管计划和举行听证会( http://www.fcc.gov )。

NTIA 通过频谱管理办公室 (OSM) 执行频谱管理职能,该办公室受《联邦无线电频率管理条例和程序手册》的管辖。 IRAC 制定和执行与频谱分配、管理和使用相关的政策、程序和技术标准。 频谱规划和政策咨询委员会 (SPAC) 审查审查 IRAC 计划,平衡制造、商业、研究和学术兴趣的考虑。

在国防部内部,频谱规划和日常运营活动受到合作管理。 频谱认证是一个强制性流程,旨在确保

  1. 给定频段的频段使用和服务类型符合相应的国家和国际频率分配表;
  2. 设备符合所有适用的标准、规范和法规; 和
  3. 批准用于开发依赖于无线通信的设备的支出。

东道国协调和东道国批准

在和平时期,国际频谱治理要求军队获得东道国许可——东道国协调(HNC)/东道国批准(HNA)——在主权国家内运行依赖频谱的系统和设备。 例如,美国国务院、国防部和用户服务部门在美国境内尊重和执行国际治理。

战时,交战国之间不尊重国际频谱治理; 但是,执行指定任务的军队必须尊重邻国的主权频谱权利。 例如,美国海军要求海航在毗邻国家的领空和/或毗邻国家的土地上使用依赖频谱的系统和设备。 海航必须在主权国家内运行依赖频谱的系统和设备之前获得。 战斗指挥官负责在其职责范围内协调与主权国家的请求。 由于作战指挥官对主权国家没有权力,因此 HNC/HNA 过程可能很漫长,需要在系统开发的早期开始。 图 2 显示了一个频谱示例。

图 2. 无线电频谱(商务部 2003 年)。 由美国商务部发布。 来源可在 http://www.ntia.doc.gov/files/ntia/publications/2003-allochrt.pdf 获得(2011 年 9 月 15 日检索)

实际考虑

EMI/EMC 对于在全球范围内运行的系统来说很难实现,因为产品设计用于在每个电信领域运行的频率不同。 数十亿美元用于改造美国国防部设备以在其他国家成功运行。

值得注意的是,核辐射环境比空间辐射环境更加紧张,并且与空间辐射环境有很大不同。

系统描述

窄带和宽带发射

为了帮助分析传导和辐射干扰效应,EMI 分为两种类型——窄带和宽带——定义如下:

  • 窄带发射

    窄带信号只占无线电频谱的很小一部分……此类信号通常是连续的正弦波 (CW),可能是连续的或间歇性的…… 杂散发射,例如窄带通信发射机的谐波输出、电力线嗡嗡声、本地振荡器、信号发生器、测试设备和许多其他人造源都是窄带发射器。 (巴加德 2009,G-1)

  • 宽带排放

    宽带信号可以将其能量传播到数百兆赫兹或更多……这种类型的信号由具有相对较短的上升和下降时间的窄脉冲组成。 宽带信号进一步分为随机源和脉冲源。 这些可能是短暂的、连续的或间歇性的。 示例包括来自通信和雷达发射器、电子开关触点、计算机、恒温器、点火系统、电压调节器、脉冲发生器和间歇性接地连接的无意发射。 (巴加德 2009,G-1)

暴风雨

TEMPEST 是一个代号,用于指代排放安全领域。 美国国家安全局 (NSA) 为研究危害排放 (CE) 进行的调查代号为 TEMPEST。 国家安全电信信息系统安全发行 (NSTISSI)-7000 规定:

电子和机电信息处理设备会产生无意的带有智能的放射物,通常称为 TEMPEST。 如果被截获和分析,这些辐射可能会泄露由设备传输、接收、处理或以其他方式处理的信息。 (NSTISS 1993, 3)

这些危害性辐射包括由处理国家安全信息的设备或系统内的源有意或无意发射的电能、机械或声能。 电子通信设备需要防止潜在的窃听者,同时允许安全机构拦截和解释来自其他来源的类似信号。 这些信号可以被截获的范围取决于信息处理设备的功能设计、安装和主要环境条件。

可以通过辐射硬化技术设计电子设备和系统,以抵抗由电离和其他形式的辐射引起的损坏或故障(Van Lint 和 Holmes Siedle 2000)。 系统中的电子设备可能会暴露于地球大气层周围范艾伦辐射带中的电离辐射、外层空间的宇宙辐射、核反应堆附近的伽马或中子辐射以及核事件期间的电磁脉冲 (EMP)。

单个带电粒子可以影响数千个电子,从而导致电子噪声,从而产生不准确的信号。 这些错误可能会影响卫星、航天器和核装置的安全有效运行。 晶格位移是对电子设备中元素晶体中原子排列的永久性破坏。 晶格位移是由中子、质子、α粒子和重离子引起的。 电离效应是一种暂时性损坏,会在大功率晶体管中产生闩锁毛刺,并在数字设备中产生诸如位翻转之类的软错误。 电离效应是由带电粒子引起的。

大多数抗辐射组件都基于其商业等效产品的功能。 设计特征和制造变化被结合以降低组件对辐射干扰的敏感性。 物理设计技术包括绝缘基板、封装屏蔽、耗尽硼的芯片屏蔽和磁阻 RAM。 逻辑设计技术包括纠错存储器、处理路径中的错误检测以及电路和子系统级别的冗余元件(Dawes 1991)。 核硬度表示为给定环境条件的敏感性或脆弱性。 这些环境条件包括峰值辐射水平、超压、剂量率和总剂量。

系统安全

在最一般的意义上,安全就是免于伤害。 作为一门工程领域,系统安全关注的是最大限度地减少可能导致具有预期严重性和预测概率的事故的危险。 这些事件可能发生在生命关键系统的元素以及其他系统元素中。 MIL-STD-882E 将系统安全定义为“在系统生命周期的所有阶段,在运行有效性和适用性、时间和成本的限制下,应用工程和管理原则、标准和技术来实现可接受的风险” (DoD 2012). MIL-STD-882E 定义了在系统安全实践中作为工程工具应用的标准实践和方法。这些工具适用于相关系统的硬件和软件元素。

概述

系统安全工程侧重于识别危害、其成因,并预测由此产生的严重性和概率。 该过程的最终目标是降低或消除已识别危害的严重性和概率,并将无法消除危害的风险和严重性降至最低。 MIL STD 882E 将危害定义为“可能导致意外事件或一系列事件(即事故),从而导致死亡、受伤、职业病、设备或财产损坏或损失,或环境。” (国防部 2012 年)。

虽然系统安全工程试图在整个系统的规划和设计过程中尽量减少安全问题,但由于不太可能的危险与最小概率的组合确实会发生事故。 因此,通常在部署后执行安全工程以应对不良事件。 例如,由于美国国家空中交通安全委员会根据事故调查提出的建议,飞机安全性得到了许多改进。 风险被定义为“事故的严重性和事故发生的可能性的组合”(DoD 2012)。未能识别安全风险以及无法解决或“控制”这些风险可能导致巨额成本,人力和经济(Roland 和 Moriarty 1990)。”

人事注意事项

系统安全专家通常负责确保系统安全。 空军指令 (AFI) 191-202 (USAF 2020) 第 11 章对系统安全专家的职责进行了冗长的阐述。 AFI 191-202 将系统安全定义为“应用工程和管理原则、标准和技术,以在系统生命周期所有阶段的操作有效性和适用性、时间和成本的限制下实现可接受的风险”。 AFI 确定了实现系统安全的八项活动:

  1. 记录系统安全方法
  2. 系统生命周期的危害识别和分析
  3. 风险评估,以后果的严重性和概率表示
  4. 识别和评估潜在的风险缓解措施
  5. 采取措施将风险降低到可接受的水平
  6. 风险降低验证
  7. 有关当局接受风险
  8. 在整个系统生命周期中跟踪危害和风险

尽管这些活动记录在空军指令中,但它们实际上非常通用,适用于几乎任何系统安全过程。

安全人员负责将系统安全要求、原则、程序和流程集成到程序和较低的系统设计级别中,以确保安全有效的接口。 两种常见的机制是安全工作组 (SWG) 和管理安全审查委员会 (MSRB)。 SWG 使所有集成产品团队 (IPT) 的安全人员能够根据 MIL-STD-882E (DoD 2012) 评估、协调和实施在系统级别集成的安全方法。 越来越多的安全审查被认为是一种重要的风险管理工具。 MSRB 提供计划级别的监督并解决所有 IPT 的安全相关计划问题。

表 1 提供了有关安全的附加信息。

表 1. 安全本体。 (SEBoK 原创)

本体元素名称 本体元素属性 与安全的关系
故障模式 失败的方式 必需属性
严重性 失败的后果 必需属性
关键性 失败的影响 必需属性
危害识别 识别潜在的故障模式 需要确定故障模式
风险 发生故障的概率 必需属性
减轻 采取纠正措施的措施 有必要确定关键性和严重性

表 1 表明,实现系统安全涉及安全工程与其他专业系统工程领域(如 系统可靠性、可用性和可维护性) 之间的密切联系。

系统安全性

安全工程关注构建系统,尽管存在恶意或错误,但仍保持安全。 它侧重于设计和实施主动和被动缓解漏洞的完整系统所需的工具、流程和方法。 安全工程是用于实现 系统保证 的主要领域。

系统安全工程 (SSE) 一词用于表示该专业工程领域,美国国防部将其定义为:“应用科学和工程原理来识别安全漏洞并最小化或包含与这些漏洞相关的风险的系统工程元素。漏洞” (DODI5200.44, 12)。

概述

安全工程包含许多跨领域技能,包括密码学、计算机安全、防篡改硬件、应用心理学、供应链管理和法律。 安全要求从一个系统到另一个系统差别很大。 系统安全通常有很多层,建立在用户身份验证、事务责任、消息保密和容错之上。 挑战在于保护正确的项目而不是错误的项目,以及保护正确的项目但不是以错误的方式。

安全工程是国防领域日益重视的一个领域。 鲍德温等人。 (2012) 提供了对问题的调查和详细的参考清单。

系统安全的目的(INCOSE 系统安全工作组 2020;经 Keith Willett 许可使用)

系统安全的目的是帮助确保在逆境中实现系统价值。 系统安全工程 (SSE) 的主要目标是最小化或包含防御系统对已知或假定的安全威胁的漏洞,并确保开发的系统能够抵御这些威胁。 在所有系统开发阶段都应用工程原理和实践,以识别和减少这些系统漏洞对已识别的系统威胁。

SSE 的基本前提是认识到对“设计”安全漏洞和“设计”对策的初始投资是一种长期的收益和成本节约措施。 此外,SSE 提供了一种方法来确保充分考虑安全要求,并在适当的情况下,在工程开发计划期间将特定的安全相关设计纳入整体系统设计。 安全要求包括:物理; 人员; 程序; 排放; 传播; 密码学; 通讯; 操作; 以及计算机安全。

不同项目的 SSE 过程可能存在一些差异,这主要是由于承包商要求的设计保证水平(即确保按计划正确实施了适当的安全控制)。 这些保证要求在程序的早期(可以充分计划)、实施和系统开发的适当过程中得到验证。

系统安全工程管理计划 (SSEMP) 是为 SSE 开发的关键文件。 SSEMP 确定计划的安全任务以及负责系统安全方面的组织和个人。 SSEMP 的目标是确保在计划的适当位置提出相关的安全问题,确保在设计、实施、测试和部署期间采取足够的预防措施,并确保仅发生可接受的风险水平当系统被释放以备战时。 SSEMP 是与 SSE 达成协议的基础,代表开发商、政府计划办公室、认证机构、认证机构以及与系统安全性相关的任何其他组织。 SSEMP 确定了认证和认证的主要任务 认证 (C&A)、文件准备、系统评估和工程; 确定每项任务的负责组织; 并提出完成这些任务的时间表。

SSE 安全规划和风险管理规划包括与建立工作说明和详细工作计划相关的任务和事件规划,以及与项目利益相关者就 SSE 计划的准备和谈判。 对于每个程序,SSE 都提供系统安全计划 (SSP) 或同等内容。 还可以开发初始系统安全操作概念 (CONOPS)。 SSP 提供: 拟议 SSE 工作范围的初步规划; 在整个系统开发生命周期中执行的 SSE 活动的详细描述; 系统的运行条件; 安全要求; 初始 SSE 风险评估(包括已知系统漏洞造成的风险及其因妥协和/或数据丢失造成的潜在影响); 以及预期的验证方法和验证结果。

这些计划与提案一起提交,并在工程开发期间根据需要进行更新。 在签订并实施正式 C&A 的情况下,这些计划符合政府的 C&A 流程、认证责任和其他协议细节(视情况而定)。 C&A 过程是客户和承包商之间关于认证边界的书面协议。 经利益相关者同意,这些计划在整个系统开发生命周期中指导 SSE 活动。

系统保障

NATO AEP-67(第 1 版),北约项目系统保障工程,将系统保障定义为:

…有理由相信系统按预期运行并且没有可利用的漏洞,无论是有意或无意地设计或在生命周期的任何时候作为系统的一部分插入……这种信心是通过系统保证活动实现的,其中包括一套计划的、系统的多领域活动,以实现可接受的系统保证措施并管理可利用漏洞的风险。 (北约 2010, 1)

NATO 文件根据 ISO/IEC 15288:2008 中的生命周期流程进行组织,并提供流程和技术指导以提高系统保障。

安全焦点(INCOSE 系统安全工作组 2020;经 Keith Willett 许可使用)

人们可以从系统是什么(结构)、它做什么(功能)、它包含什么(内容)、它使用什么、(输入、资源)或它所在的位置(环境)来考虑一个系统。 安全的重点(我们保护的)可能是结构、状态、功能、功能交换(输入、输出)、原材料(访问、供应)、运行系统的燃料/能源、包含整体(系统的系统)、或更广泛的当前秩序(生态系统)。 系统安全重点包括但不限于强化、防御、保护、最大限度地利用可再生资源、最大限度地减少对可枯竭资源的使用、保持与当前秩序兼容并保持可行性和相关性。

软件保障

由于大多数现代系统的大部分功能都来自软件,因此软件保障成为系统保障的首要考虑因素。 国家安全系统委员会 (CNSS) (2010, 69) 将软件保障定义为“对软件没有漏洞的信心水平,无论是有意设计到软件中还是在其生命周期的任何时候意外插入,并且软件功能以预期的方式。”

格策尔等。 al (2008, 8) 指出,“软件保障之所以重要,是因为如此多的商业活动和关键功能——从国防、银行、医疗保健、电信、航空到危险材料的控制——都依赖于正确的、可预测的软件操作。”

硬件保证

系统硬件保证是一组系统安全工程活动,旨在量化和提高电子设备在其整个生命周期内按预期运行且仅按预期运行的信心,并管理已识别的风险。 有关详细信息,请参阅 系统硬件保证

系统描述

稳健的安全设计明确而不是隐含地定义了保护目标。 认证信息系统安全专家 (CISSP) 共同知识体系 (CBK) 将强大的安全性划分为十个领域(Tipton 2006):

  1. 信息安全治理和风险管理涉及建立标准然后评估信息保护有效性的框架、原则、政策和标准。 安全风险管理包括治理问题、组织行为、道德和安全意识培训。
  2. 访问控制是使系统管理员能够允许或限制系统的操作和内容的过程和机制。 访问控制策略确定用户可以调用哪些流程、资源和操作。
  3. 密码学可以定义为在通信和存储过程中伪装信息以确保其完整性、机密性和真实性的原则和方法。 I 类设备已通过美国国家安全局 (NSA) 的机密信息处理认证。 类型 2 设备已通过 NSA 认证,可用于专有信息处理。 类型 3 设备已通过 NSA 认证,可用于一般信息处理。 4 类设备由工业或其他国家生产,没有任何正式认证。
  4. 物理(环境)安全涉及实际环境配置、安全程序、对策和恢复策略,以保护设备及其位置。 这些措施包括单独的处理设施,限制进入这些设施,以及扫描以检测窃听设备。
  5. 安全架构和设计包含用于定义、设计和实施安全应用程序、操作系统、网络和设备的概念、流程、原则和标准。 安全架构必须集成各种级别的机密性、完整性和可用性,以确保有效操作和遵守治理。
  6. 业务连续性和灾难恢复计划是在发生自然或人为事件时确保业务生存的准备和实践,这些事件会对正常业务运营造成重大干扰。 必须选择流程和具体的行动计划,以谨慎保护业务流程并确保及时恢复。
  7. 电信和网络安全是用于在通过私有和公共通信网络传输期间提供数据的完整性、可用性和机密性的传输方法和安全措施。
  8. 应用程序开发安全涉及在集中式或分布式环境中应用于应用程序软件的控制。 应用软件包括工具、操作系统、数据仓库和知识系统。
  9. 运营安全专注于为最终用户提供系统可用性,同时保护集中式数据处理中心和分布式客户端/服务器环境中的数据处理资源。
  10. 法律、法规、调查和合规问题包括确定是否发生事件的调查措施以及响应此类事件的流程。

对有助于系统安全的安全需求和领域的复杂性和多样性的一种回应是“纵深防御”,这是一种常用的架构和设计方法。 纵深防御实现多层防御和对策,最大限度地利用每一层的认证设备,促进系统认证。

纪律管理

基本安全原则(INCOSE 系统安全工作组 2020;经 Keith Willett 许可使用)

纪律管理包括以下带有非正式描述的基本安全原则(Willettt 2008)。 根据上下文的不同,有许多正式的定义具有不同的细微差别。 例如,基于政府的国际标准或特定立法。

原则 描述(正面) 描述(否定)
保密 确保仅授权披露 防止未经授权的披露
正直 确保仅授权修改 防止未经授权的修改
可用性 确保准备就绪 防止拒绝服务
拥有 确保实物占有 防止丢失或被盗; 尽量减少因丢失或被盗造成的损失
效用 确保适合用途 ,或准备好使用 防止失去目的
真实性 确保系统符合现实或根据符合现实的信息采取行动 防范欺骗
隐私 确保被忽视的权利和被遗忘的权利 防止不必要的观察和保留个人详细信息(例如照片)
不可否认性 确保不可否认性 在执行操作时防止匿名
授权使用 确保仅授权使用服务 防止滥用产生成本(资源消耗)的活动

安全域

安全域(INCOSE 系统安全工作组 2020;经 Keith Willett 许可使用)

有许多安全域,每个域都可能有不同或重叠的领域。 一些需要考虑的安全域:

  • 编排空间指导工作流执行
  • 工作流空间完成组织使命
  • 组织效能是完成使命的能力
  • 保障措施保持组织效能
  • 所需的安全态势是定义适用保障措施的故意假设位置
  • 风险态势是故意假设的位置,以推动所需的安全态势
  • 任务风险容忍度有助于定义风险态势
  • 对工作流程中断的容忍度推动了任务风险容忍度
  • 市场动态(生态系统动态)推动任务优先级
  • 任务优先级是非静态的,会影响任务风险承受能力
  • 漏洞空间包含编排和工作流中的弱点
  • 漏洞影响风险态势
  • 威胁空间包含对工作流程的潜在干扰
  • 合规空间部分解决了威胁空间
  • 合规驱动因素影响风险态势
  • 持续监控提供当前安全状况的快照
  • 差距分析提供所需和当前安全态势之间的差异
  • 纠正措施可在资源限制内缩小差距
  • 资源限制:人员(技能、知识)、预算、技术等。

任何一个领域的变化都会对其他领域产生连锁反应。 从这个意义上说,它们具有导致无限循环的因果循环或动态反馈。 一个新兴目标是在网络相关时间内识别、理解域状态和交互并对其采取行动(Herring 和 Willettt 2014)。

基于网络的资源

美国国土安全部的 Build Security In 网站 (DHS 2010) 是一个很好的系统和软件保证在线资源,它提供了用于工程安全系统的最佳实践、知识和工具的资源。

 

 


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



1010 次浏览
5次
 
欢迎参加课程:
数据建模方法与工具
MBSE(基于模型的系统工程)
基于 UML 和EA进行分析设计