《车载SOA软件架构技术规范1.0》是由AUTOSEMO撰写的首个车载SOA软件架构技术规范，这是首个面向汽车行业SOA软件架构的理论体系。近期，AUTOSEMO将组织针对本规范的官方解读，有兴趣的朋友可以关注“AUTOSEMO”公众号，了解更多信息。本规范是基于AUTOSEMO平台，进行车载SOA软件架构共性技术研究，以及开发性车载SOA架构规范的研究和定制。进行行业技术和规范共享，减少行业无序重复性开发，节约研发成本，最大化产业投入效益。本规范作为汽车领域的SOA架构规范的初版，侧重于SOA技术的行业交流学习，实现SOA文化的传播和行业认知的统一。本规范从SOA架构技术和AUTOSAR技术规范两个技术领域，探索车载软件架构技术规范的开发之路。
《车载SOA软件架构技术规范1.0》主体内容共4个部分，内容较多，我们将分多篇进行详细解读，本文将介绍前面两个章节。下图是目录：
SOA架构技术概述
面向服务计算的七大战略目标相互联系，具体来说可以分为两组，即战略目标和战略价值（优势）。其中提高组织业务敏捷性、提高投资回报率和减少研发成本（或IT负担）是其他四个目标实现所带来的价值和优势。在将面向服务持续应用于软件程序设计时，一系列战略目标和优势（如图1所示）共同代表了我们所期望实现的目标状态。理解这些目标和优势是非常有益的，因为它们可以为我们提供连续不断的总体背景和理由，以维持我们长期实现面向服务的投入。
1. 增强本征互操作性：即互操作性指的是数据的共享。软件程序的互操作性越高，其之间的信息交换越容易。2. 增强联合：即服务的联合。软件资源和应用程序联合在一起，同时保持其各自的自主性和自治性。3. 增加供应商多元化选择：即供应商多元化能力，指组织必须选择“最佳品种＂的供应商产品和技术创新。4. 同步提升业务与技术领域：即应用程序的设计和实现不仅要满足初始业务需求，也应满足未来随业务性质和方向变化时的业务需求。5. 提高投资回报率：即衡量自动化解决方案投资回报率(ROI)是决定应用程序或系统实际成本效益的关键因素。6. 提高组织的业务敏捷性：即组织能够对变化做出反应的效率，以适应行业变化并超越竞争对手。7. 减少研发成本(IT成本）：即减少浪费和冗余，缩小规模和运营成本，减少与其治理和演进相关开销等。SOA是一个组件化模型，它将应用程序的不同功能单元（服务）通过这些服务间良好的接口和契约联系起来。其中，服务(Service)是一个粗颗粒度的、可发现的软件实体，以一个单独实例存在，通过一组松耦合和基于消息的模型与其他应用或服务交互。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以以一种统一和通用的方式进行交互。交互的服务大致由三个实体组成：服务请求者、服务提供者和服务注册表。其中实体间的操作包括：服务发布、服务发现、服务绑定和调用。面向服务架构是众多软件架构风格中的一种，是微服务架构的一种。因面向服务架构风格具有基于标准、松散耦合、共享服务和粗粒度等优势，表现出易于集成现有系统、具有标准化的架构、提升开发效率、降低开发维护复杂度等特征，更符合智能网联化时代车载系统对软件架构的要求，所以被汽车行业引入和采用。SOA因组件化和服务化模型特征，有其自身的优缺点，具体分析如下（仅针对IT行业业务特征和实施环境）：
优点分析：
灵活性，根据需求变化，可重新编排服务或应用程序
对IT资产的复用
- 使企业的信息化建设真正以业务或应用为核心，业务人员根据需求编排服务，不需要考虑技术细节
在IT行业，国外于1996年由Gartner第一次提出SOA思想，2005年SOA开始推广和普及，2007年应用厂商希望通过发布标准来推动SOA的实施，如SCA和SDO通过OASIS审核，WS-POLICY、W3C成为W3C标准等，如今SOA在国外IT行业、通讯行业、政府部门得到广泛系统性应用。其中，欧美实现SOA架构的关键任务是：对已有系统中的功能进行提取和包装，形成标准化的“服务”。在国内，2006年之前是技术萌芽；2006-2008年是过热期；2009年度过了幻灭期；从2010年开始进入复苏期，现在正处于由复苏期迈向成熟期。其中，国内近30年的IT建设多为生产型系统，服务型系统普遍未开始建设，大量"服务"需要全新标准化构造。在汽车行业，因汽车智能化和网联化需求，尤其是自动驾驶系统研发应用的需要，车载系统SOA软件架构技术受到国内外整车企业的关注。国外，2010年以宝马、电装、大众等为首的欧、美、日汽车产业巨头便开始车载SOA软件架构的研究工作，形成一定理论基础和实践成果，并对传统汽车电子系统进行革命性创新。当前，大众、奥迪、宝马、福特等汽车巨头自成联盟，进行SOA软件架构技术和规范的应用研究，预计2023前后将开始应用于量产车型。国内，整车企业有加入和使用的意愿，但考虑软件架构规范核心实施技术不给予开放，后期产品技术和产品生态会高度依赖国外技术平台和标准规范，将会严重制约车企自身创新发展。其中， 一汽、东风和上汽等部分头部OEM己意识到SOA软件架构的重要性，在寻找自主解决方案。同时，软件架构技术属于行业共性技术，属于开发式共性平台，因国内缺少行业协同和协作机制，在共性平台和生态建设方面发展缓慢。
SOA技术规范现状
Web服务作为SOA架构技术发展的典型和成熟代表，其促进了SOA架构技术的发展和推广，其标准体系的开发方式和开发内容对于车载SOA软件架构技术规范开发具有深入的指导意义。SOA架构的WEB服务相关的标准化组织主要有三家，分别为万维网联盟(World Wide Web Consortium, W3C)、结构信息标准化促进组织(Organisation for the Advancement of Structured Information Standards, OASIS)和Web服务互操作组织(Web Service Interoperability Organisation,WS-I)W3C是一个专注于开发基于Web的行业技术标准的国际联盟。它的使命是通过开发协议和指导方针，确保万维网作为一种多功能媒体的长期增长，使万维网充分发挥其潜力。1994年Tim Berners-Lee创建了W3C,因为跨网络分割的风险变得越来越明显（特别是在多个版本的HTML同时工作时）。从那时起，W3C就开始优先开发核心的Web技术(HTML、XML等），以及相关的样式化语言(CSS 、XSLT等）。如今，Web服务严重依赖于W3C开发的技术，W3C委员会制作Web服务技术
主要由以下几部分：
OASIS成立于1993年，是一家非营利性的国际协会，旨在开发、整合和推厂包括Web服务、安全、商业事务、供应链、电子政务、互操作性等所需的标准。OASIS对Web服务的贡献包括对UDDI(Universal Description Discovery and Integration)规范的标准化，以及对WS-BPEL规范的标准化。此外OASIS也推出了诸如面向服务的架构参考模型和面向服务架构的相关规范等。OASIS和W3C不同，他的主要兴趣在于制定附加规范以及支持不同的行业，与应用领域的关系更为密切。
WS-I成立于2002年，其目的不是建立新的标准，而是旨在推动Web服务的互操作性。具体目包括三个方面：
- 促进跨平台、跨应用软件和跨程序语言的网络服务的一致和兼容，并保证可靠兼容；
- 致力于使网络服务协同成为本行业共同遵守的准则，以帮助客户在网络服务技术的选择上轻松决策，提高网络服务的应用范围和水平，并确保网络服务技术的持续发展。
为了充分利用Web服务技术，最大潜力发掘其技术价值，理解将技术规范开发为已批准的行业标准的过程是很重要的。这一切都始于新技术的原创想法，当社区对这个想法有足够的兴趣时，W3C就会举行一个开放的研讨会，相关方聚在一起讨论技术解决的范围和技术提出的解决方案。就Web服务而言，供应商组织通常倡议他们独立或合作开发的技术，虽然这些技术常常用来解决那些对供应商来说很重要的问题，但人们希望让它们成为非专有的Web服务框架的一部分。如果W3C参与者之间有足够的协议，那么这些所提出的技术将成为创建行业标准的基础。W3C技术规范声明周期的第一步是成立一个负责定义目标标准的工作组。该组将由W3C成员组成，他们通常由供应商代表和从业者组成。W3C还提供了支持的技术人员，帮助确保该技术将完全补充其他已经开发的行业标准。然后，该组通过以下阶段开发一个规范：l．工作草案——这是一个定期发布的规范的快照，以让社区了解工作组所采取的方向，并收集早期的意见。2．最后一次呼叫工作草案——当工作组认为该规范满足其所有原始要求时，它将发布此文件并正式请求社区的意见。这一步骤通常至少持续三周。3．候选推荐——纳入前一阶段的反馈后，工作组要求实施规范，以确保规范实际上是可实现和互操作的。4．建议——证明规范巳以互操作方式成功实施，已提交W3C咨询委员会批准，这一步骤至少会持续四周。5.建议——规范为W3C建议，通常称为“行业标准”。整个过程的持续时间因所开发规范的范围和复杂程度而不同。从一个工作组成立的那一刻起，它可能需要18个月到几年的时间来提交W3C建议。在这些阶段，公众可以通过提交工作组有义务回应的反馈，对正在制定的技术规范发表评论。工作组成员之间的所有通信和工作组的所有交付成果都发布为公开访问。W3C的一个特殊性是，它的过程是基于共识的，这意味着整个工作组在做出决定之前需要就解决方案达成一致。投票只有在有严重分歧的情况下才会进行投票，而通过投票作出的任何决定通常会在剩下的过程中进行仔细审查。2.2 AUTOSAR-AP平台SOA相关技术规范概述AUTOSAR-AP平台采用SOA方法论，主要涉及一种自适应软件产品的开发，是一套包括软件分析、设计、开发、部署在内的复杂工作流程。主要包括两个方面：工作流定义与成果物定义（如图2-2)。具体描述如下：AP平台的方法论作为CP平台的扩展，其引入了新的概念，AP平台软件的实例是在进程的上下文中执行。AP平台引入了“机器”(Machine)的概念，“机器”是虚拟化的ECU,一个可以部署软件的实体。它可以是真实存在的处理器，也可以是一个虚拟机，AP软件则运行在某一特定的“机器”上。(1)开发服务接口(Service Interface)AP平台是一个面向服务的软件架构(SOA)，基于AP平台的软件开发，首先需要进行服务接口的设计。服务接口可以由事件(Events)、方法(Methods)和字段(Fields)组成，是生成软件组件头文件的基础。(2)开发通信结构(Communication Structure)OEM在设计阶段需要指定预期“机器”(Machine)的通信结构以及相应的配置参数，包括机器的所有网络端点和服务发现地址端口等。这一步将产生一个可交付的“机器设计”(Machine Design)，一个特定的“机器”模型将引用一个特定的“机器设计“ 模型。(3)开发自适应应用软件(Adaptive Application Software)自适应应用软件开发从软件组件(SW component)的设计开始，软件组件是通过其端口(Port)定义的，每个端口实现一个服务接口。基于服务接口描述，生成包含实现软件组件的头文件。开发人员在此基础上实现软件组件的核心功能。(4)开发自适应平台软件(Adaptive Platform Software)与应用级软件类似，平台级软件可以由基于标准化服务接口的软件组件组成，也可以直接实现而不需要软件组件模型。包括了功能组状态和每个状态超时的定义，进程到特定机器的映射，以及平台服务（例如NM、DoIP) 和基础模块（例如日志）配置等。此过程会产生一个独立于服务实例或应用程序的机器清单(Machine Manifest)软件的实现和编译完成后，需要集成到一个可执行文件CExecutable)中。通过进程来定义特定机器上可执行文件的实例化，每一个进程会产生一个执行清单CExecution Manifest)，其中包括了进程及其启动配置。(7)定义和配置服务实例(Service Instance)首先对服务接口进行部署，然后定义服务接口的实例，并决定是否提供或使用该服务实例。其次要建立服务实例到机器的映射，以及服务实例到端口的映射。此过程会产生进程所需的所有服务实例清单(Service Instance Manifest)(8)生成软件包(Software Package)将可执行文件及所需清单整合为软件包上传到机器上，而无需重新刷写。OEM可以将软件包存储在后端服务器中进行统一管理。由于AUTOSAR的工作流包含了整个汽车软件开发流程，涉及多个开发角色，因此需要各个开发角色之间有信息交互，为了保证信息不出现二义性，需要对各个环节的工作成果物规则进行定义。同时为了信息的保存、传输、交互的需求，需要定义这些成果物的载体，ARXML就是定义了不同流程成果物的载体，使用不同的标签来表示不同的信息及流程，这些标签的定义就是AUTOSAR的数据元模型（如下图)。MO: 使用Ml级规则生成的可运行软件实体，例如车门控制的可自行软件组件Ml: 使用M2级规则定义软件组件，例如车门控制的软件组件，软件组件的表现形式可以是ARXML,C/C+＋语言或各类文档。一般情况下会使用工具链以ARXML的形式定义软件组件的框架，然后导入下游工具链生成目标语言。或直接生成目标语言框架，然后手写代码的形式完成整体的软件组件；M2: 使用M3级规则定义使用AUTOSAR开发的元素、语法及规则，例如软件组件，port口，机器，清单等。该级别的元素与具体的功能无关，类似于各类开发语言的语法；
