本文节选自《车载SOA软件架构技术规范1.0》，该规范是由AUTOSEMO撰写的首个车载SOA软件架构技术规范，也是首个面向汽车行业SOA软件架构的理论体系。
车载SOA软件架构：服务设计原则
根据客户功能或系统给出的输入，考虑以下主要服务设计原则定义逻辑功能架构：
1.1 重用
在逻辑功能架构定义期间，定义逻辑工件，以便应在客户功能，系统和域之间按原样重用它们。
如果逻辑元素的功能相同但被实例化了多次，则确保将其创建为重用。这将确保对一个逻辑元素的任何进一步更新将在多个实例之间自动级联。
如果感觉或输入始终需要特定的后处理，则将它们一起封装在BuildingBlock中。这将使整个客户功能／系统中的完整构建块可以重复使用。建议在这种情况下重用完整的构建块，而不是特定的感知元素。
如果执行机构或输出始终需要进行特定的预处理，则将它们一起封装在Building Block中。这将使整个客户功能／系统中的完整构建块可以重复使用。在这种情况下，建议重用完整的构造块，而不是重新使用特定的致动元件。
如果存在一组在功能上相互关联且密切相关的逻辑功能，则将它们一起封装在一个Building Block中。
这将使整个客户功能／系统中的完整构建块可以重复使用。
在这种情况下，建议重用完整的构建块，而不要重用特定的逻辑功能元素。
如下图所示，应创建多个重用实例，以实例化车辆中四个车轮中的每个车轮的“ReadWheelSpeed”感应块。要设计车道保持辅助(LKA)客户功能的逻辑体系结构，应该可以重用车道偏离警告(LDW)的逻辑块，并在此基础上构建此新客户功能。
1.2 抽象
应该在正确的抽象级别上仔细考虑逻辑功能体系结构定义中的逻辑元素。
低级别的抽象可能会冒逻辑架构对未来解决方案的适用性丧失（无法重用）的风险。
高级别的抽象可能需要花费更多的时间和精力才能将需求转换为逻辑体系结构。这可能会导致对实际客户功能的错误解释。
紧急事件触发电子呼叫（紧急呼叫）功能。基于逻辑功能体系结构上下文中抽象的定义，系统工程师只需强调需要感知（检测崩溃事件）和相应的数据流（崩溃事件）的需求。系统工程师不需要回答什么地方，什么地方，这些细节在实施阶段更为合适。
根据基准数据，此客户功能的实际实施在各个汽车制造商之间是不同的：
解决方案1: RCM或安全气囊控制器将碰撞事件数据发布到E-Call主机ECU,以进行后续处理和采取措施
解决方案2: 将E-Call算法包含在被动安全系统中，然后将请求发布到主机ECU以激活E-Call
- 解决方案3: 将独立的低分辨率G力传感器（加速度信号）直接硬接线到E-Call主机ECU,以进行E-Call激活决策和致动。
1.3 粒度
尽管按照上述标准对逻辑元素进行抽象很重要，但是确保逻辑功能也足够精细同样重要。考虑输入和需要提供哪些输出，逻辑功能应表示紧密相关的功能。具有正确粒度级别的逻辑功能可以灵活地重新部署。例如，如下图所示：仲裁，启用和处理功能应定义为单独的逻辑块，而不是创建一个称为Process Smart Windows Plus的逻辑块。
逻辑功能体系结构定义中的逻辑元素应尽可能组合在一起（封装在一起），以便可以在客户功能或系统或域中按原样重用它们。可以使用构件块来实现封装。封装不仅可以确保体系结构的重用，而且其他领域的系统工程师也无需了解构建模块的内部原理，而只需使用公开的巳发布或预订的数据流即可。
例如，定速巡航客户功能的核心逻辑功能应封装在一个构造块中，以便完整的构造块应再次用于（自适应）定速巡航控制客户功能。
1.5 协调
对于逻辑体系结构定义，不同的系统工程师还要处理来自不同域的不同客户功能集。在创建新的逻辑元素之前，系统工程师应始终确保检查其是否巳存在并重复使用。系统负责人和域负责人应确保逻辑体系结构得到协调和重用。以下是典型的工作流程：
处理给定客户功能或系统的系统工程师创建逻辑元素（如果尚不存在）。如果存在，请重用它们。系统负责人／域负责人需要检查系统工程师的逻辑功能架构，并确定是否存在重复的逻辑元素并进行修复。系统线索／域线索也应确保将可重用的逻辑元素创建到公共池中。建议在公共逻辑包中将所有逻辑感测元素与各自的后处理逻辑元素一起构造。建议在每个域中使用各自的预处理逻辑元素来构成所有逻辑促动。车载SOA软件架构：服务策略
虽然SOA现在发展的如火如荼，但还是处在不断的发展中，还是存在很多有待改进的地方。其缺点目前来说，主要表现在以下几个方面：可靠性，安全性，性能。在电子商务的应用中，有一个很重要的可靠性，就是不可否认性，信息确保发送且仅且一次以及事务的回滚，这点是必须得到满足的，但是，目前来说，SOA架构还没有为此做好准备。至于安全性我们在下面会做详细的分析。至于性能问题，不可否认，这个SOA架构最遭人诟病的地方。SOA架构的性能稍低，主要是因为SOA的分布性质和web服务协议的开销。任何分布式系统的执行速度都不如独立式系统，因为这里面有网络的制约因素。所以，在对那些实时性要求较高的地方，在构建SOA架构之前，就应该先搞清楚它的适用范围了。
这里之所以特意把安全问题拿出来作为一个独立的段落，是因为安全问题对一个系统来说应该受到足够的重视。如果你没有在在它上面付出应有的努力，也许，它就会成为导致SOA架构在实施的时候失败的主要原因。由于SOA架构的松散耦合性，当其向客户提供服务时，任何形式的网络都能获取IT应用程序和系统时，人们会本能的担心非正当人群也能访问程序和系统。互联网对世界开放，从而更加剧了人们的这一担忧。通常我们企业都知道保护网络接入，认证用户以及运行访问控制列表。假设所采用的SOA基础架构具有实施安全粒度的能力，这就使得有效控制访问方式成为可能。但是，如果保证数据在网络中输送的隐秘性又是一个难题，要达到一定的保护水平，可以采用各种加密标准。然而不幸的是，市场并没有很好的处理整个SOA安全事件，简单的看很多与安全相关的web服务“标准“草案都是尚未成熟，考虑欠佳，并不真正的实用。一般来说，我们针对SOA的安全能做些什么呢？需要的SOA网络安全策略和许多的基于web的应用程序是采用相同的策略的，他们采用的方式都可以归结为创建一个虚拟局域网来保证服务器和客户端达到交互，使用数字证书来建立SSL(secure socket layer)保护或者HTTPS,或者通过在软件或者硬件上部署防火墙基础架构来检测通过SOA进来的可疑请求，但是这只是构建一个安全的通道，我们依旧不能保证数据不被窃取。所以，为了确保数据的安全性，我们需要对数据加密。针对SOA架构来说，就是对原始的XML数据进行保护了。通常，我们采用XML加密和XML签名来把安全加入到基于XML的数据中去。XML加密可以让数据能够在请求者和响应者之间以一种模糊的方式传输。这样，即使数据受到窃取，信息也很难读懂。而XML签名，则是用来进行XML文档的篡改检测的。它可以保证所传输的数据没有收到篡改或者状态没有发生改变。
车载SOA软件架构：服务分类
为了更好地管理依赖关系和构建软件结构，应该使用分层软件架构。下图显示了软件架构定义的层级，其中不同层中的组件之间存在有效的依赖关系。HMI行为比核心应用功能更容易改变。因此，将核心应用软件和HMI之间的分离将使设计更容易更改，特别是在开发期间的后期更改，或在HMI适应新产品时。此外，开发核心应用软件和HMI设计需要不同的能力技能，分开时应该更容易处理。基本的策略是将HMI功能与其他应用软件（功能）的核心部分分离。为了实现这一点，model-view-controller模式需要被使用。这意味着核心应用软件不应该意识到任何HMI,而是HMI应该对模型做出反应并呈现给用户。用户输入由Controller处理，Controller解释用户的意图并操作模型。将硬件逻辑，例如传感器和执行器逻辑（外设为绿色）与应用程序逻辑（主应用程序为蓝色）分开，以便能够在中央系统中分配应用程序，同时保持传感器／执行器尽可能的具体。这将促进:
能够在应用程序之间使用SOA,即使传感器／执行器可能不支持。
更容易将传感器／执行器作为现成的组件来采购，从而降低价格。
更容易处理中央系统的可变性。
将战略软件与中央系统分开，以更好地控制，并在需要时更容易进行内部开发。
这一层包含了对设备的抽象，即设备代理(DP)和设备驱动程序(DD)。这里的模块将在需要时，对信号到服务之间进行转换，并处理设备层中的可变性。这一层不应该包含任何车辆功能，只管理设备。在这一层的DD不允许直接通信彼此，必须通过DP或车辆控制层。DP和DD可以使用一些平台服务，如日志、诊断等。与所有系统一样，需要一些更偏向于支持的功能，这是所有模块都可以使用的公共服务，如日志记录、资源管理等。即便我们巳经将HMI、Platform Services、Sensor/Actuator和Device Abstraction与核心应用功能分离，针对庞大的核心应用功能的开发，对于开发部门来讲还是很复杂的。也就是说，为了促进高效的开发工作，这个核心应用功能需要以某种方式进行分割。根据核心应用功能软件特点、公司组织结构等，可根据需要将核心应用功能软件划分为多个层次。这一层包含的软件部件，对本车应用负有总体责任，例如如何使用各种能源的策略定义。它们更像是应用程序类型的swc，使用其他层中的服务，而不向其他层提供服务接口。这一层包含协调特定范围内功能的软件部件，例如协调不同类型的电气能量的使用。这一层包含控制功能范围更有限的软件部件，例如控制产生电能的特定执行器。除分层外，核心应用功能，或部分的核心应用功能也可以根据开发组织进行分离。例如：Connectivity, Energy, Motion Control, Safety, Body, 和Infotainment。不同的企业可以采用不同的定义方案。
车载SOA 软件架构：服务部署
具有更高层次逻辑的软件更有可能是战略性的和复杂的，这种软件，在中央计算机中更易于管理。无论是从服务的角度，还是从战略的角度，因为更容易有较短的开发周期等等。因此，处理管理、协调和高级控制等高级逻辑的软件应尽量部署到中央控制器。我们希望与传感器／执行器的接口尽可能靠近设备，以便在进入中央系统之前尽快将低级信号转换为服务。直接在区域控制器中处理可变性也会更容易，而不会让它扩散到中央系统。因此，与传感器或执行器硬件紧密耦合的软件应该部署到离传感器／执行器最近的区域控制器上。将紧密耦合的软件部署到相同的ECU将节省大量的通信和网络带宽。特别是如果它们之间有高频率的交流。因此，将相互紧密耦合的软件，例如，在它们之间有广泛的信息交换，应该尽可能地部署到相同的ECU。将具有相似操作需求的软件组合在一起可以节省系统资源和／或成本。例如，将一个ECU中低功耗软件集群分组有助于降低总功耗，因为在低功耗模式中需要唤醒的ECU较少。因此，具有相似操作需求的软件应尽量部署在相同的ECU上，例如：
为了实现必要的功能安全级别和实现安全目标，必须将安全关键软件部署到正确的运行环境。与功能安全相关的ECU通常比其他，非功能安全相关的ECU更昂贵，因为功能安全标准可能需要更昂贵的设计和过程度量。所以，我们希望尽可能少的ECU被归类为安全相关的ECU。如果可能的话，所有安全关键软件都应该部署到中央ECU的一个安全处理器上。如果这是不可能的，额外的安全分类ECU的数量应保持在最低限度。我们也不希望在同一个ECU中混合安全分类和非安全分类软件，如果它们没有以某种形式分开，比如在不同的CPU或虚拟机中。在软件打包和部署时，都必须考虑软件组件的功能安全分类。网络安全战略的重要组成部分是将连接的软件部署在正确的ECU上。对于在何处部署网联软件和安全漏洞软件有许多限制。对于分配到不同安全域的ECU,部署规则如下：暴露的安全域
- 包含所有出于安全原因或其他原因与车辆外部没有任何依赖关系但仅包含在车辆内部的ECU
