面向服务的架构SOA（Service-Orientied Architecture）是一种软件设计范式，本文主要介绍SOA面向服务的电子电气架构开发方法。
SOA将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间良好定义的接口和协议联系起来，接口采用中立的方式进行定义，他独立于实现服务的硬件平台、操作系统和编程语言。文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
设计范式是设计解决方案逻辑的一种方法，在构建分布式解决方案逻辑时，设计方法通过一种称为“关注点分离”的软件工程理论实现，简而言之，这个理论说明，将更大的问题分解为一组较小的问题或关注点时，这个问题就能得到更有效的解决，这让我们产生了将解决方案逻辑划分为多个功能的想法，每个功能都旨在解决单一的关注点，相关功能可以分组为解决方案逻辑单元。分布式解决方案逻辑存在不同的设计范式，面向服务体现在：面向服务执行关注点分离的方式以及如何塑造具有特定特性和支持特定目标状态解决方案逻辑的单个单元。从根本上说，面向服务将合适的解决方案逻辑单元整合为企业资源，其可以被设计为解决即时问题，同时对更大的问题保持不可知，这就为我们提供了不断的机会来重新利用那些单元内的功能并解决其他问题。文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
在面向服务持续应用于软件程序设计时，一系列战略目标和优势共同代表了我们所期望实现的目标状态，理解这些目标和优势是非常有益的，因为它们可以为我们提供连续不断的总体背景和理由，以维持我们长期面向服务的投入。文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l增加本征互操作性:即增加数据共享，软件程序的互操作性越高，其之间的信息交换越容易；文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l增强联合:即服务的联合，软件资源和应用程序联合在一起，同时保持其各自的自主性和自治性；文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l增加供应商的多元化选择：即供应商多元化能力，指组织必须选择“最佳品种”的供应商产品和技术创新；文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l同步提升业务与技术领域：即应用程序的设计和实现不仅要满足初始业务需求，也应满足未来随业务性质和方向变化时的也业务需求；文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l提高投资回报率：即衡量自动化解决方案投资回报率（ROI）是决定应用程序或系统实际成本效益的关键因素；文章源自线束工程师之家-https://www.suncve.com/development-method-of-service-oriented-electronic-and-electrical-architecture/
l提高组织的业务敏捷性：即组织能够对变化做出反应的效率，以适应行业变化并超越竞争对手；
l减少研发成本：即减少浪费和冗余，缩小规模和运营成本，减少与其治理和演进相关开销等。
1、SOA面向服务的设计原则
(1)标准化服务合约原则
面向服务架构体系中，服务通过一个服务合约来表达他们的目标和能力，标准化服务合作设计原则是面向服务中最基本的原则之一，其本质上是在设计一个服务的公开技术接口，或评估作为服务正式合约的一部分而发布的内容特性和数量时，给予特殊考虑指导方法。
服务合约设计时，需要重点考虑服务能力的表达方式、数据类型和数据模型，以及服务策略、服务端点的一致性、可靠性和可治理性。
(2)服务松耦合原则
耦合是指两个事务之间的关联和联系，这一原则主张在服务的边界之内和之外创建特定类型的关系时，要始终强调减少服务合约、服务实现和服务消费者之间的依赖关系（车载领域尤其需要关注感知、决策和执行的耦合关系），在服务设计过程中存在各种数据类型的耦合关系，每一个都会影响合约的内容和粒度，需要依靠原则指导和实际经验获得一个适当的耦合级别。
(3)服务抽象原则
这个原则强调尽量隐藏服务的更多细节，服务需要一致地抽象关于技术、逻辑和功能的相关信息，不会展现给外部世界（服务逻辑开发上之外的世界），届时，服务合约需要抽象仅仅包含服务不要对外发布公开的信息，如必要的交互需求、约束和必须的服务元数据。
(4)服务可复用性原则
服务可复用性原则强调在无关的功能性上下文环境中，把服务定位为企业的资源，确保服务是无关单个应用和业务流程，具有无关功能性和通用性，可以在无关服务环境中被定义，并且可以保证它们能促进必要的复用环境，可以被多个消费者程序提供访问。
(5)服务自治性原则
为了让服务能够持续可靠地提供服务能力，底层的方案逻辑要求对环境和资源进行相当程度的控制，这一原则涉及服务逻辑设计及服务实际实施环境的各类问题，合理利用可以增加服务的可靠性和行为的可预测性的设计特性，可以对其他设计原则在实际开发过程中的有效应用提供足够的支持。在车载领域，由于涉及不同安全等级和实时性要求，尤其要关注隔离级别和服务规范化，针对不同应用领域一起可以达到各自适合程度的自治，对于经常需要共享的可复用服务来说尤其重要。
(6)服务无状态性原则
就服务而言，管理过多的状态信息会导致服务可用性和伸缩性潜力的破坏，在理想情况下，服务只应该在必要时保持状态；
(7)服务可发现性原则
将服务定位为可服用资产时，若复用机会出现，服务可以被发现并理解。服务发现机制（SOME/IP-SD等）和服务自身的设计（尤其服务端点）都需要将服务的“交流质量”和其自身能力考虑在内。
(8)服务可组合性原则
面向服务的解决方案的复杂程度在持续增长，位于其下的服务组合配置的复杂度也在持续增长，车载领域也面临同样的问题，能够有效组合服务能力是面向服务计算的一些基本目标的关键要求，复杂的服务组合对服务设计提出了要求，服务有望作为有效的组合成员参与，无论他们是否需要立即加入组合。
2、SOA面向服务的设计方法
在面向服务的架构开发时，分析和设计服务架构的过程是从客户需求到SOA架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。
（1）需求分析
用例（Use Case）驱动的开发方法指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用，由用例驱动的开发活动，可建立需求和系统功能之间清晰的追溯关系，更好的应对智能汽车产品需求的快速迭代更新。
（2）功能设计
在功能设计阶段我们用产品能力（Product Capability）描述功能实现的逻辑，产品能力是连接功能设计和软件设计的桥梁，在功能设计层面，借助UML动态图（序列图、活动图、状态机）运用产品能力PC描述每个UseCase的功能实现链路；在软件架构设计阶段，通过将产品能力分配到不同的软件模块，从而明确各软件模块的职责范围，作为软件开发的输入，同时各软件模块中的服务也根据PC描述的功能范围来设计。
（3）软件架构设计
软件分层
为了更好地管理依赖关系和构建软件架构，应该使用分层软件架构，对于SOA的应用软件架构分层可采用如下原则:
a.分离HMI和核心应用软件
HMI行为比核心应用功能更容易改变，因此，将核心应用软件和HMI之间的分离将使设计更容易更改，特别是在开发期间的后期更改，或在HMI适应新产品时，此外，开发核心应用软件和HMI设计需要不同的的能力技能，分开时应该更容易处理，基本的策略是将HMI功能与其他应用软件（功能）的核心部分分离，为了实现这一点，MVC(Model-View-Controller)模式需要被使用，这意味着核心应用软件不应该意识到任何HMI，而是HMI应该对模型做出反应并呈现给用户，用户输入由Controller处理，Controller解释用户的意图并操作模型。
b.分离传感器/执行器软件和应用软件
将硬件逻辑，例如传感器和执行器逻辑与应用程序逻辑分开，以便能够在中央系统中分配应用程序，同时保持传感器/执行器尽可能的具体，这将促进能够在应用程序之间使用SOA，及时传感器和执行器不支持，更容易将传感器/执行器作为现有组件来采购，从而降低价格；更容易处理中央系统的可变性；将战略软件与中央系统分开，以更好地控制，并在需要时更容易进行内部开发；此策略目的在于提高上层应用软件关键功能的复用性，将依赖硬件的功能与逻辑控制功能分离。
c.分离的设备抽象层
这一层包含了对设备的抽象，即设备代理（Device Proxy）和设备驱动程序（Device Driver）,这里的模块将在需要时，对信号到服务之间进行转换，并处理设备层中的可变性，这一层不应该包含任何车辆功能，只管理设备，在这一层的Device Driver不允许直接彼此通信，必须通过DP或车辆控制层，DP和DD可以使用一些平台服务，如日志、诊断等；
d.分离平台服务和主应用软件
与所有系统一样，需要一些更偏向支持的功能，这是所有模块都可以使用的公共服务，如日志记录，资源管理等；
e.应用软件分为多层
即便我们已经将HMI 、Platform Service、Sensor/actuator和Device Abstraction与核心应用进行分离，针对庞大的核心应用功能的开发，对于开发部门来讲还是很复杂的，为了促进高效的开发工作，这个核心应用功能需要以某种方式进行分割，根据核心应用功能软件特点，公司组织结构等，可根据需要将核心应用功能软件划分为多个层次：
-车辆应用层：这一层包含的软件部件，对本车应用负有总体责任，例如如何使用各种能源策略的定义，他们更像是应用程序类型的SWC，使用其他层中的服务，而不向其他层提供服务接口；
-车辆协调层：这一层包含协调特定范围内（Domain内）功能的软件部件，例如协调不同类型的电气能量的使用；
-车辆控制层：这一层包含控制功能范围更有限的软件部件，例如门窗控制，门锁控制等，除分层外，核心应用功能，或部分的核心应用功能也可以根据开发组织进行分离，例如：Connectivity，Energy,Motion，Control,Safety,Body和Infotainment，不同的企业可以采用不同的定义方案。
(4)服务设计
a.服务分层
l硬件抽象服务：基于ECUs功能和硬件外围设备（传感器/执行器），定义硬件抽象服务，这些服务应该在软件平台级别提供。
l平台核心服务：所有跨应用程序集群和域的公共服务都需要在软件平台级别定义和提供；
l域核心服务：在一个应用集群中，跨不同应用程序的公共服务应定义为域核心服务，
l应用程序服务：特定于系统的每个应用程序或功能的服务，需要定义为应用程序服务；
b.服务类型
根据服务提供功能的特点，可以分为基础型服务与功能型服务，
l基础型服务：提供与业务无关的通用系统服务能力，包括操作系统、基础软件、通用中间件提供的功能；
l功能型服务，提供具体业务功能相关的服务，包括与域控相关的专用中间件、应用层提供的功能。
c.服务框架
Service Framework是对通用基础软件的扩充，在基于不同种类的操作系统及基础软件平台之上提供系统级服务调用及整车级功能设计视图，其次对AutoSAR的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，最后提供基于引擎的动态服务配置方法，基于预设的静态服务，通过云端对静态服务进行编排，实现更加丰富的业务功能。
l原子服务：不可拆分的服务，一般为执行单一操作的功能，不同功能节点可以提供针对业务的原子服务；
lSOA+：基于AutoSAR的服务框架扩展，向应用层提供更多基于服务开发需要的功能，其中包括服务转换、服务调试、服务同步、服务权限管理和基于Andorid的SOA协议栈；
l系统基础服务：系统可以提供的基础服务，体现该系统可以提供的能力，需要依赖通用基础软件提供的功能，可以通过API或服务的形式提供给上层，针对不同异构系统分别提供软件包；
l整车级系统基础服务：整车角度需要多个控制器协同实现的功能
l动态服务：基于原子服务及系统服务提供的功能进行组合，实现服务的级联，包括动态服务配置接口：提供给调用者实现动态服务的可配置接口；动态服务引擎，根据配置接口的输入，执行动态服务的核心功能。
d.服务定义
车载SOA软件接口是服务提供者或使用者之间数据交换的定义，它定义了向使用者公开的服务的属性、方法和事件等，服务定义定义服务之间的依赖关系，以及服务的接口（Require Interface Provide Interface）
(5)物理架构设计
定义整车的网络拓扑以及硬件架构类型（功能域架构、中央计算单元+区域架构），综合各家OEM的下一代电子电气架构分析，车载计算单元+自动驾驶域控制器+智能座舱域控制器+区域控制器的架构形态被大多数的OEM所采用。
(6)网络通信设计
可在PREEvision中定义SOME/IP服务矩阵，设计Machine，SWC to Machine Mapping, Machine Deployment,Application Deployment,Servcie Instance Design,可导出Service Interface Description ARXML文件，该文件可以包含一个或多个服务接口的详细信息，如Method/Event/Property以及对应的数据类型等内容。该文件可以将服务接口信息准确的传递给其他工具，如DaVinci Adaptive IDE，用于生成服务接口的头文件。
同时可导出Execution Manifest包含了Adaptive Application部署到目标AUTOSAR Adaptive平台上所需的信息，比如进程启动配置，进程与Machine的映射等内容，导出Machine Manifest包含Machine部署相关的信息，比如网络配置信息，计算资源等，导出Service Instance Manifest包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。
(7)应用层软件开发
将PREEvision导出的SWC Description ARXML文件导入MatLab Simunlink 创建模型框架，配置服务发现机制，确认AutoSAR属性，生成代码。
接下来需要利用基础软件供应商提供的开发工具（例如DaVinCi Adaptive tool Suite）和AP中间件（例如MICROSAR）进行集成、配置，详细的过程我们后续再来探讨。
推荐阅读：
一文看懂，Adaptive AUTOSAR从入门到精通（二）
