系统架构活动目的是定义一个全面的解决方案

系统架构活动的目的是定义一个全面的解决方案，它基于相互逻辑关联和一致的原则、概念和属性。解决方案架构的特征、属性和特征,满足尽可能表达的问题或机会的一组系统需求(可追踪任务/业务和利益攸关方需求)和生命周期的概念(例如,操作,支持),哪些是可实现通过技术(如机械、电子、液压、软件、服务、过程、人类活动)。

系统架构是抽象的，面向概念的，全球性的，并且专注于实现系统的任务和生命周期概念。它还侧重于系统和系统要素的高层结构。它介绍了相关系统的架构原则、概念、属性和特征。它还可以应用于多个系统，在某些情况下，为类似或相关系统的类或系列形成公共结构、模式和需求集。

概念和原则的概念结构

系统工程知识体系认为系统工程涵盖了系统创建的所有方面，包括系统架构。

系统架构的大多数解释都基于相当无形的结构概念(即要素之间的关系)。一些作者限制了被认为是架构学的结构类型;例如，限制自己的功能和物理结构。最近的实践扩展了对结构的行为、时间和其他维度的考虑。

ISO/IEC/IEEE 42010系统和软件工程—架构描述提供了对架构的有用描述，考虑了利益攸关方的关注、架构观点、架构视图、架构模型、架构描述，以及整个生命周期的架构。

关于系统架构特性的讨论可以在中找到。

INCOSE英国架构工作组描述了在系统工程中开发和应用系统方法来描述架构信念系统特征的尝试。

系统的架构描述

架构框架包含标准化的视点、视图模板、元模型、模型模板等，这些可以促进系统架构视图的开发。ISO/IEC/IEEE 42010 (ISO 2011)指定了架构框架、视点和视图的规范特性，因为它们属于架构描述。一个观点处理一个特定的利益攸关方关注点(或者一组紧密相关的关注点)。视点指定了在开发系统架构中使用的模型的种类，以处理该关注点(或关注点集)，模型应该以何种方式生成，以及如何关联模型并使用它们来组成视图。

逻辑和物理模型(或视图)通常用于表示系统架构的基本方面。其他互补的观点和观点必须用于表示系统架构如何处理利益攸关方关注的问题，例如，成本模型、过程模型、规则模型、本体论模型、信念模型、项目模型、能力模型、数据模型等等。

原则和启发式的分类

工程师和架构师混合使用数学原理和启发式(启发式是通过经验获得的教训，但没有经过数学证明)。当通过系统需求识别和定义一个问题时，原则和启发式可能能够也可能不能解决它。系统视图/模型中使用的原则和启发式可以根据使用这些系统视图/模型的领域进行分类，如下:

静态域与分解为系统和系统要素的系统利益（SoI）的物理结构或组织有关。它处理分区系统、系统要素和物理接口。

动态领域与逻辑架构模型相关，特别是与系统行为的表示相关。它包括功能(即输入流到输出流的转换)和系统功能之间以及外部对象或系统之间的交互的描述。它考虑对启动或停止系统功能执行的事件的反应。它还涉及系统的有效性(即性能、运行条件)。

时间域与系统功能执行的时间不变性水平有关。这意味着每个功能都是根据循环或同步特性执行的。它包括决策级别，这些级别是某些功能行为的异步特征。

环境领域与使能者(生产、后勤支持等)有关，但也与应对自然灾害或威胁的系统生存能力有关，与应对内部潜在危险的系统完整性有关。例如，这包括气候、机械、电磁和生物方面。

从系统需求到逻辑和物理架构模型的转换

方法的目的是从系统需求进展(代表问题从一个供应商/设计师的角度,尽可能独立于技术)通过一个中间的逻辑架构模式来分配系统的逻辑架构模型的要素的要素候选项物理架构模型。

(系统需求和逻辑架构模型共享许多特征，因为它们都在功能线上组织，独立于实现。一些作者甚至将两者合并，从而简化了对多个同时发生的视图的处理。是否采用这种方法取决于开发组织的具体实践，以及契约的边界在哪里划定。)

设计决策和技术解决方案是根据性能标准和非功能需求来选择的，例如操作条件和生命周期约束(例如，环境条件、维护约束、实现约束等)，如图1所示。创建中间模型,如逻辑架构模型,便于功能的验证,行为,和时间系统的特性对系统需求没有重大技术影响影响期间的生活系统,物理接口、技术层面完全没有质疑系统的逻辑功能。

原文标题：系统架构

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。

责任编辑：haq