本文摘要：袁泉：掌握一项汽车电子和软件技术通常从熟练的应用开始，然后逐渐将其提炼为知识体系。

袁泉：掌握一项汽车电子和软件技术通常从熟练的应用开始，然后逐渐将其提炼为知识体系。而一个完整的知识体系又可以反过来引导技术创新或创造新领域的专门技术。

汽车软件架构正在经历这个过程，正在引入IT行业广泛使用的面向服务架构。虽然可以从互联网行业搜索到一篮子相关的软件技术产品，但是这些碎片化的技术还是需要汽车工程师进行系统的梳理和整合。AUTOSAR在这方面走在了前列，自适应平台的推出标志着向面向服务的汽车软件架构迈出了重要的一步。

AUTOSAR面向服务的软件架构可以方便地构建在Classic Platform和Adaptive Platform上。面向服务的架构设计离不开服务模型的设计。

本文将遵循设计师的思路，谈谈AUTOSAR服务模式的设计思路和关注点。服务架构设计中需要考虑的因素面向服务的架构设计在许多应用领域都很流行，它深刻地影响着软件设计和开发的各个方面。

当汽车软件架构转向服务时，首先想到的是遵循合作的范式设计。早在2006年，OASIS就发布了一个开放规模的“面向服务的架构参考模型”。参考模型是一个抽象的设计，不直接指定任何规模、技术或详细的实现方案。

此外，它提供了一系列通用语义，可以清晰地可视化各种服务架构的实现方案。贯穿整个参考模型的是各种设计元素，是指导SOA设计的关键。与架构相关的问题包括参考架构、架构风格和其他模型。这些元素最终构成了所需的软件架构方案。

这些内容来源于参考模型，是一系列运动的起源。任何一种架构方案，不仅仅是面向服务的架构，设计中也必然会发生一些需求，而这些解决现有问题的需求成为架构设计的需求和要达到的目标。架构设计一方面是为了满足这些目标和需求，另一方面是考虑它的运行，比如各种协议、规范、标准。

SOA的实现是以上要素整合的结果，从总体架构规范和基础架构到具体需求，最终完成一个完整的SOA架构设计。服务参考模型对面向服务架构的定义的解释之一是，SOA是一种组织和使用在不同领域下疏散的能力的范式。

重点——“服务”至少包括三个方面：1)为对方执行事情的能力。2)向对方提供的事物的说明。3)为另一方做某事的提议。

能力和应用能力互不相同。需求和能力可以独立于SOA而存在。

在SOA架构中，服务是一种结合需求和能力的机制，这就是设计SOA的意义。回到汽车软件面向服务的架构转型，传统执行器和传感器作为汽车基本能力的本质并没有改变。转向面向服务的体系结构后，改变的是在这些设备之间构建东西的标准和提供方法，同时也可以提高这些设备的可重用性、可扩展性、互操作性等特性。

下图显示了参考模型中的一些主要观点：1 .服务“服务”的观点是提供会议并在其他领域使用某些能力的机制，会议过程需要通过指定的接口进行，同时需要满足服务概要文件中定义的相关约束和策略。服务通常需要通过一个叫做服务提供者的实体来提供，而另一方叫做服务消费者。服务的实现对于服务消费者来说通常是不可见的，所以需要定义服务接口，其目的是让服务消费者知道服务的规模，以标准化的方式满足服务的内容。

2.服务的动态响应关于服务交互的方式有三种基本观点：可见性、真实世界效果和交互。2.1.可见性对于服务提供者和消费者来说，他们互动的前提是知道对方的存在。可见性包括三个前提，分别是：1)觉察：使自己的一面对他人可见，进入被发现的状态。这个发现过程通常被称为服务发现。

2)意愿：现场服务的交互，比如注册一个服务，也就是开始服务内容的交互。服务意愿受服务策略的制约。3)可达性：网络中双方的地址、使用的协议、服务当前是否可用等。

2.2.服务的交互服务的交互通常是消息的发送和接收，也包括状态的迁移和改变。服务的交互围绕着服务的出现，它们是：1)信息模型：服务交换数据的句法结构和语义。

2)行为模型：包括动作模型和过程模型，准确地表示与业务相关的动作和流程，与服务的应用领域密切相关。2.3.现实世界效果如果允许服务完成某件事，这个动作的效果将被认为是现实世界的效果。

此类影响包括：1)对请求信息的回复。2)实体状态的改变。3)以上两种效果的结合。

服务提供者和消费者的行为是对共享状态的改变。服务交互的现实世界效果是共享状态的累积状态变化。3.为了支持服务的交互性，服务本身表现在以下三个方面：服务描述、合同和策略以及执行上下文。

3.1.服务拓扑SOA的特点是大量的文档和拓扑。服务外观包括使用服务所需的信息，反映各方对运行实体和实施的要求，还包括信息模型、功效和策略。服务外观的目的是促进服务参与者之间的互动和可见性。

通过形貌信息，使得潜在的到场者去建设提供服务的系统。每项服务包罗哪些能力，怎么样去接入和使用这些服务，在服务形貌中都有所体现。服务形貌要求使用尺度，可引用的花样，例如使用尺度的处置惩罚工具(如发现引擎)把服务形貌详细化。

SOA的理念中，服务消费者并不需要知道服务实现的细节，所以服务形貌应包罗关键的信息，以让服务的消费者决议是否使用该服务。通常服务的消费者需要知道以下的信息：１) 服务存在并可到达。2) 服务所执行的功效：服务形貌需准确的形貌服务被挪用后所发生的真实世界效应，以及包罗服务所提供的功效的局限性与技术假设。

3) 服务运行的约束(constraints)和计谋(Policies)，服务将切合哪些划定的计谋等。４) 服务交互的方法：包罗双方交流信息的花样和内容。通常被称作为服务接口(Service Interface)，它包罗指定的协议，方法，信息交互的方式。

服务接口和接入方式的形貌是SOA最重要的部门。3.2. 契约和计谋计谋代表某种使用服务的约束或者条件。而契约则代表者多方之间的告竣的一致协定。计谋包罗三个方面：1) 计谋断言：多数情况是表现服务的实现方式。

2) 计谋所有人。3)计谋实行。

服务契约是详细化的计谋断言，治理双方或者多方的需求和期望。契约致力于解决服务提供者和消费者之间的交互问题。

3.3. 执行上下文执行上下文是一组实例化后的基础元素，历程实体，计谋断言和契约，是服务能力执行历程中所依赖的种种因素的荟萃。执行上下文是服务交互的焦点，它通常在服务交互的历程中逐步发生，并可以随之服务交互内容改变而随之发生改变。执行上下文同时也区分了差别的服务实体，对差别消费者提供的服务的互动举行区别。执行上下文也是数据交流时解释数据的场所。

一段特定字符串在特定的执行情况下，在服务互动中代表的意义也差别。AUTOSAR服务模型AUTOSAR服务模型从许多方面遵循了OASIS的参考模型。之前的文章已经提到过，AP AUTOSAR并不是要取代CP AUTOSAR，而是要衍生拓展对于服务化的支持。

所以AUTOSAR服务模型的设计需充实思量以下约束。1) 支持应用软件组件的独立性。应用软件组件独立性主要体现在单一功效的划分，并只管淘汰和其他功效模块的交互。

数据交互的接口接纳服务化的设计，以尺度的通信中间件实现应用之间的交互。2) 不依赖于特定通讯协议的面向服务架构服务可绑定差别的网络传输层协议，以支持适用于实时操作系统的跨网络传输协议(如SOME/IP)，适用于大数据量的传输层协议(如DDS)，适用于高性能场所的IPC通信。3) API尽可能性的精简，仅提供焦点的通讯机制业务层面的服务相关设计，不是AUTOSAR的关注点，应交给OEM和软件供应商，让他们自由地发挥想象力，去实现应用层级此外服务框架。

4) 支持动态的通讯机制，由APP掌控服务发现历程5) 需同时支持基于事件和基于轮询的应用挪用样式，使得通过CP AUTOSAR中RTE的API式样依然可以挪用服务的方法。另外为支持确定性执行的要求，通信治理模块需支持应用历程异步上下文切换，app接纳时间片轮询的方式举行调理，并由应用法式掌控数据收集和数据发送，从而制止不须要的上下文切换。6) 支持同步通信和异步通信两种方式7) 支持client/server，sender/receiver(with caches)的通信机制一般情况下应用之间主要发生的交互是数据交流和功效挪用，在CP AUTOSAR中，已有Sender Receiver，Client Server两种典型的通信机制。前者对应的是数据交流，后者对应的是功效挪用，由RTE统一完成应用之间的通信。

面向服务化后，依然需要满足这两种基本的通信机制，使CP和AP两个平台可以无缝的衔接。8) 拓展Security和Safety的功效(例如在CP平台已应用的SecOC, E2E)，服务质量QoS9) 可拓展至实时操作系统基于以上的约束并联合服务参考模型，AUTOSAR的服务模型的雏形就展现出来了。见附图。服务模型的焦点是以Method, Event, Fields组织在一起的荟萃。

为专门解决与当前CP AUTOSAR兼容性的问题，重新设计了用于车载领域的SOME/IP协议。另有就是以Proxy/Skeleton的范式作为客户端服务器端的通信方式。

图：AUTOSAR服务模型概略末端未来AUTOSAR是不是最合适的面向服务的软件架构还需要时间去磨练，但从它的设计理念和思路可以看出其着力于汽车系统的基本软件要求，努力做到往前和往后的系统兼容性。在当前看来，是相对完整并具操作性的面向服务的软件架构解决方案。

本文关键词：澳门新葡官网进入网站8883入口

本文来源：澳门新葡官网进入网站8883入口-www.masdulou.com