目录

软件架构定义

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件体系结构是构建计算机软件实践的基础。-- 来自百度百科

软件架构工作开始于第一个需求，结束语最后一个问题修复，贯穿了整个软件开发过程，从ASpice的体系中，也表现了这一点。

并且更多倾向于文档化，图形化，多种视图化。

摘自Automotive SPICE

是一种从更高层面去抽象，去规划子系统，以及模块之间的关系的方法，手段，与实现。

架构设计原则

设计原则实际上是对框架之下的各个组件，模块，制定的原则，制定的约束。整体目的是为了更合理的部署，更清晰的运行，资源，等方面去考虑。

摘自ASpice

从葵花宝典书面派，可以总结如下。

1.单一职责原则：每个模块或类应该只有一个引起变化的原因。这意味着一个模块或类应该只做一件事情，并且这件事应该完全由它来负责。这有助于降低系统的复杂性，提高代码的可读性和可维护性。

2.开闭原则：软件实体（如类、模块、函数等）应该对扩展开放，对修改封闭。这意味着在设计软件时，应该尽可能地避免修改现有的代码，而是通过添加新的代码来扩展系统的功能。这有助于提高系统的稳定性和可维护性。

3.接口隔离原则：客户端不应该依赖于它不需要的接口。这意味着在设计接口时，应该尽量细化接口，避免创建过于庞大的接口。每个接口应该只包含一组相关的方法，这样客户端只需要关心它需要的接口，而不需要了解其他不相关的接口。

4.依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。这意味着在软件架构中，应该尽量使用抽象类或接口来定义模块之间的依赖关系，而不是直接依赖于具体的实现类。这有助于降低模块之间的耦合度，提高系统的灵活性和可维护性。

5.最少知道原则：一个对象应该对其他对象保持最少的了解。这意味着在软件架构中，每个模块或类都应该尽量减少对其他模块或类的依赖和了解。这有助于降低系统的复杂度，提高代码的可读性和可维护性。

当我们软件模块相对硬件模块进行控制的时候，多多少少会遇到耦合的问题，修改一个模块，其他的也要跟动，如下。不同的需求，带来的耦合程度不同。

下面我们从设计各个角度去清晰化，解耦。

架构视图

功能视图

软件架构的功能视图主要关注系统的功能需求。这包括对用户可见的功能的描述，同时也包括了一些基础模块和辅助模块的功能定义。功能视图是软件架构设计中非常关键的一部分，它帮助开发者明确系统需要实现哪些功能，以及这些功能之间如何相互关联和协作。

通过功能视图，开发者能够清楚地了解到系统需要提供哪些服务，这些服务如何被组织和使用，以及它们如何满足用户的需求。同时，功能视图也为后续的详细设计和编程实现提供了实际的指导，确保系统的功能实现与需求保持一致。

在构建功能视图时，开发者需要充分考虑系统的业务逻辑、用户需求和业务流程等因素，确保功能视图的准确性和完整性。此外，还需要注意功能之间的划分和接口设计，以确保系统的可维护性和可扩展性。

总之，软件架构的功能视图是系统设计中不可或缺的一部分，它为软件开发者提供了一个清晰的框架，帮助他们在设计和开发过程中更好地理解、组织和实现系统的功能。

从上面的功能视图可以总结出来三要素。

•域

•功能

•依赖关系

行业发展的正常EE 架构，突出了域的概念，域的规划。

来源 |联合电子

开放的软件生态

基础软件层面：提供稳定的操作系统，底层驱动，虚拟化环境；依据芯片架构和硬件特性，优化传感器数据处理、AI算法布署，充分挖掘硬件算力，同时保障整车全生命周期的功能安全及信息安全。

中间件层面：应具备统一的中间件技术和服务接口SOA软件环境、标准化的通信协议以及为上层应用做到严格监控和全方面设防，并向上能给应用层提供良好的通信及同步机制，便于应用布署和移植。

域日益成熟。功能分布变得尤为重要。

动力域

￮多种动力系统单元（内燃机，电动机/发电机、电池、变速箱）

￮计算和分配扭矩

￮变速器管理

￮电池监控

￮发电机调节

底盘域

￮转向

￮换挡

￮油门

￮悬挂

￮制动

智能座舱域（娱乐，通信）

￮语音识别

￮手势识别

￮显示性能：一芯多屏显示，仪表屏不同尺寸，中控屏，

￮虚拟化技术

￮安全级别不同的应用进行隔离

￮远程控制

￮整车OTA

自动驾驶(辅助驾驶ADAS)

￮多传感器融合

￮定位

￮路径规划

￮决策控制

￮无线通讯

￮高速通讯

车身域控制器

￮应用

￮灯光

￮雨刮

￮中控门锁

￮车窗

￮车门

物理视图

软件架构的物理视图主要关注系统在物理计算资源上的部署，包括硬件、网络、服务器、存储等。它描述了软件如何映射到硬件，以及系统如何分布方面的设计。物理视图的主要任务是确保目标程序及其依赖的运行库和系统软件能够正确、高效地安装和部署到物理机器上，同时还需要考虑如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

在物理视图中，通常会表示出机器与机器之间的访问关系，以及各个物理元素之间的连接和通信方式。这有助于软件工程师和系统架构师了解系统的物理部署情况，从而更好地进行系统的性能优化和故障排查。

因此，物理视图在软件架构设计中具有重要的作用，它能够帮助开发团队确保软件系统的物理部署与业务需求和技术要求相匹配，从而实现系统的稳定运行和高效性能。

在汽车上描述了整个EE架构的顶级视图。分解到不同的子系统，描述了子系统的物理连接等EE架构描述。

逻辑视图

逻辑视图的关注点是系统的拓扑结构，表现出逻辑组件的架构。

逻辑视图更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”等经典的三层架构，以便更清晰地理解系统的各个组成部分以及它们之间的交互关系。

总的来说，逻辑视图是软件架构中非常重要的一个方面，它帮助开发者和利益相关者更好地理解系统的功能需求和设计，为后续的开发工作提供指导。

注意逻辑组件里面的 属性，方法以及约束。

逻辑视图的设计方法。

描述如那件逻辑视图的第一步是识别组件，这些组件用UML 表示出来，或者类表示出来。然后我们对其进行关联，添加相互关系。从属等等。这也是设计系统描述通讯的主要输入之一。

架构风格

1.数据流风格：包括批处理序列和管道-过滤器风格。在管道-过滤器风格中，每个构件都有一组输入和输出，它们读取输入的数据流，经过内部处理后产生输出数据流。这种风格的连接件就像数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

2.调用/返回风格：包括主程序/子程序风格和面向对象风格。在面向对象风格中，数据的表示方法和它们的相应操作被封装在一个抽象的数据类型或对象中。

3.独立构件风格：例如事件系统风格，这种风格采用隐式调用和广播机制。构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程可以在这些事件中注册，当事件被触发时，系统会自动调用这些事件中注册的所有过程。

4.层次化设计风格：每一层为上层服务，并作为下层客户。这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列实现。

5.仓库风格（数据为中心的系统）：如数据库系统，它关注数据的存储和检索。

6.分布式处理风格：如客户机/服务器风格，它将系统分为客户端和服务器两部分，客户端向服务器发送请求，服务器进行处理并返回结果。这种风格能够实现分布式计算，提高系统的性能和可扩展性。

7.微服务架构风格：将系统拆分成多个小型的、自治的服务，每个服务都可以独立部署和运行。这种风格能够提高系统的可伸缩性、容错性和可维护性。

8.事件驱动架构风格：系统中的各个组件通过事件进行通信，每个组件都可以触发和处理事件。这种风格能够实现松散耦合、异步处理和高并发性。

当然我们汽车的软件来说，相对淳朴，简单一些。

分层架构

分层架构 layered architecture, 每一个组件有自己的层级关系。最为广泛的实例可能就是TCP/IP 分层结构了。

网络的7层模型

我们来抽象一个例子出来。

这种风格比较适合结构单一，功能不复杂的场景。很明显的能看出，同一层级的组件时没办法横向通讯的。比较适合 内部采用 while(1)的形式。看来是满足不了我们的汽车大控制器场景了。都是有优点，有缺点的存在。

基于组件

基于组件 component based. 这种风格相对于上面，更灵活一点，同一层级的组件时可以相互通讯的。彼此又有接口。

看着这描述，有没有想到autosar的 bsw 里面的层级关系 与 调用关系，没错，autosar的 bsw 使用的一部分就是这种架构风格

autosar bsw 结构风格。出自 autosar 官方文档

注意，这里说的只是BSW 的角度。

autosar也遵循了这一点，什么样的接口可以互相调用，什么样的接口是上下的，定义的很明确。

Autosar 官方也给出了很明确的定义。

所以也能看出来这里面的一个小缺点，就是如果定义不清淅，文档不明确，不充分。会给人一种很乱的感觉。

客户端 - 服务器

在 client server 架构风格种，系统定义了服务和客户端之间的关系。定义了一些动作，可以是 主动请求，也可以是被动接收推送。

比如10086 发信息给你说 你的话费不够了

比如你发信息给10086问，我还剩多少话费，10086回复你，您已欠费。。。。

客户端 - 服务端模型

Client/Server结构(C/S结构)是大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。

发布者 - 订阅者

发布者-订阅者 表面看和 客户端-服务端架构类似。并且从使用者的角度，数据通信也是类似的。那么区别是什么呢

在“发布者-订阅者”模式中，称为发布者的消息发送者不会将消息编程为直接发送给称为订阅者的特定接收者。这意味着发布者和订阅者不知道彼此的存在。存在第三个组件，称为代理或消息代理或事件总线，它由发布者和订阅者都知道，它过滤所有传入的消息并相应地分发它

发布者 - 订阅者 模型

发布/订阅消息传送具有以下优势：

•解耦仍然需要通信的子系统。可以独立管理子系统，即使一个或多个接收者处于脱机状态，也能正确管理消息。

•提高可伸缩性，改善发送者的响应能力。发送者可以快速将一条消息发送到输入通道，然后恢复其核心处理责任。消息传送基础结构负责确保将消息传送到感兴趣的订阅者。

•它提高了可靠性。异步消息传送可以帮助应用程序在负载增大的情况下继续保持平稳运行，并更有效地处理间歇性故障。

•它允许延迟或计划的处理。订阅者可以等到在非高峰期拾取消息，或者可以根据特定的计划路由或处理消息。

•这样可以简化使用不同平台、编程语言或通信协议的系统之间的集成，以及本地系统与云中运行的应用程序之间的集成。

•它简化了整个企业中的异步工作流。

•它改善了可测试性。在执行整个集成测试策略过程中，可以监视通道，并可以检查或记录消息。

•它为应用程序提供关注点分离。每个应用程序可以注重自身的核心功能，而消息传送基础结构可以处理所需的一切工作来可靠地将消息路由到多个使用者。

中间件

Middleware

在汽车软件种，现在主流的 autosar 就能看到中间件的架构设计风格。当然这是抽象出来很大的层面，内部的细节可能是别的架构模式。

从整体来说，autosar的中间件模式，完全解耦了 应用层算法逻辑 与 底层硬件驱动。实现了自己的中间件。

autosar 中间件 设计风格

面向服务

Service oriented

面向服务 松解耦采用了互联网的协议标准。强调架构里组建的接口可以使用通用的协议。并且可以动态的增加，减少服务。

在汽车软件中，也逐渐使用进来。代表作有someip.

大家可以直接去someip的主页进行学习。我也正在学习。

https://www.some-ip.com/standards.shtml