|
掌握一门技术通常都是从熟练运用开始，再逐步提炼成一套知识体系。而完备的知识体系可以反过来指导技术的革新，或者创造出在新领域中的专门技术。 汽车软件架构正在经历这样的过程，IT行业广泛应用的面向服务的架构正在被引入其中。尽管从互联网行业可以搜索到一篮子的相关软件科技产品，然而这些碎片化的技术仍需要汽车工程师们进行系统化的梳理与整合。这方面走在前沿的当属AUTOSAR，自适应平台的推出标志着向面向服务的汽车软件架构迈出了重要一步。 AUTOSAR面向服务的软件架构可以方便地构建在安全控制器(Classic Platform)，还有高性能处理器之上(Adaptive Platform)。服务化的架构设计离不开服务模型的设计，本文将跟随设计者的思路谈谈AUTOSAR服务模型的设计思路和关注点。 01 服务架构设计需考虑的因素 面向服务的架构设计流行于多种应用领域，它深刻地影响着软件设计和开发的各个方面。当汽车软件架构要转向服务化，首先想到是遵从共同的范式设计。OASIS早在2006年就发布了开放标准－“面向服务架构参考模型“。该参考模型是抽象层面的设计，并不直接指定任何的标准，技术或者具体的实现方案。另外，其提供了一系列共通的语义，可以明确地描述各种服务架构的实现方案。 贯穿整个参考模型的是各类设计要素，这些要素是指导SOA设计的关键。架构相关的工作内容包括参考架构，架构式样，及其他模型。这些要素最终构成了所需的软件架构方案。而这些内容起始源自于参考模型，它是一系列活动的起源。 任何一种架构方案，不仅仅是面向服务的架构，设计势必是在某种诉求中产生的，这些解决现有问题的诉求就成为架构设计的需求，以及要达到目的。架构设计一方面是要满足这些目的和需求，另一方面则是要考虑其运行环境，例如各种协议，规范和标准等。 SOA的实现是以上要素综合的成果，从一般性的架构规范和基础设施，再到针对专门需求所制定的运行环境，最终完成一个完整的SOA架构设计。 02 服务参考模型 对于面向服务的架构定义，其中的一个解释是：SOA是一种范式，用以组织和利用分散在不同领域之下的能力(capabilities)。而其中的核心概念－“服务”，至少包含三方面的内容：1) 为另一方执行工作的能力。2) 为另一方提供的工作规范。3) 为另一方执行工作的要约。 能力与运用能力，概念上有所差别。需求与能力可以独立于 SOA 而存在。而在 SOA的架构中，服务是将需求与能力两者相结合起来的机制，这设计SOA的意义。 回到汽车软件面向服务化的架构转型，车内传统的执行器与传感器作为一种基本能力的实质并未改变。在转向面向服务的架构后，改变的是在这些设备间建立起工作的规范和要约方法，同时还能提升这些设备的复用性，拓展性，互用性等其他特性。 下图展示了参考模型中一些主要的概念： 1. 服务的概念 “服务”是提供访问与使用其他域中某些能力的一项机制，访问的过程需要通过规定的接口进行，同时需要满足服务描述中所定义的相关约束条件和策略。服务通常需要通过某个实体来提供-称做服务提供者(Service Provider)，而另一方称做服务消费者(Service consumer)。 服务的实现通常对服务消费者不可见，所以需要定义服务接口(Service Interface)，其目的是让服务消费者了解服务所包含的范围，并规范的去访问服务的内容。 2. 服务的动态响应性 服务相互作用的方式主要有３个基本概念：可见性(Visibility)，真实世界效应(Real world effect)，相互作用(Interaction）。 2.1. 可见性 对于服务的提供者和消费者，它们互动的前提是知道对方的存在。可见性包含三方面的前提，它们是：１）存在性(awareness)：使己方可被他方可见，并进入待发现的状态。这种发现的过程通常称作服务发现机制(Service Discovery)。２）意愿性(willingness)：参与服务的交互，例如注册某个服务，即开始服务内容的交互。服务的意愿性受服务策略的制约。３）可到达性(reachability)：服务双方在网络中的地址，使用的协议，服务当前是否可用等。 2.2. 服务的相互作用 服务的相互作用通常是消息的发送和接受，另外还包含的情况是状态的迁移和改变。服务的相互作用围绕着服务描述，它们是：1) 信息模型(Information model)：服务交换数据的句法结构与语义。2) 行为模型(Behavior model)：包括动作模型和过程模型，它们确切地描述业务相关的动作和流程，和服务的应用领域密切相关。 2.3. 真实世界效应 如果让服务去完成某件事情，这个动作产生的结果就被认为是真实世界效应。这类效应包括:１）回复被请求的信息。２）实体状态的变化。３）以上两种效应的组合。 服务的提供者和消费者的动作是对于共享状态的改变。服务相互作用的真实世界效应就是对共享状态的累计状态变化。 ３. 关于服务 为支持服务的互动性，服务本身通过以下三个方面来展现：服务接口(Service description)，契约和策略(Contracts and policies)，执行环境(Execution context)。 3.1. 服务描述 SOA的特征就是有大量的文档和描述。服务描述包含了使用该服务所需要的信息，反映的是各方对于运行实体和执行环境的要求，还包括信息模型，功能与策略等。 服务描述的目的是促进服务参与者之间的互动性和可见性。通过描述信息，使得潜在的参与者去建立提供服务的系统。每项服务包含哪些能力，怎么样去接入和使用这些服务，在服务描述中都有所体现。 服务描述要求使用标准，可引用的格式，例如使用标准的处理工具(如发现引擎)把服务描述具体化。 SOA的理念中，服务消费者并不需要知道服务实现的细节，所以服务描述应包含关键的信息，以让服务的消费者决定是否使用该服务。 通常服务的消费者需要知道以下的信息：１) 服务存在并可到达。2) 服务所执行的功能：服务描述需准确的描述服务被调用后所产生的真实世界效应，以及包含服务所提供的功能的局限性与技术假设。3) 服务运行的约束(constraints)和策略(Policies)，服务将符合哪些规定的策略等。４) 服务交互的方法：包括双方交换信息的格式和内容。通常被称作为服务接口(Service Interface)，它包括指定的协议，方法，信息交互的方式。服务接口和接入方式的描述是SOA最重要的部分。 3.2. 契约和策略 策略代表某种使用服务的约束或者条件。而契约则代表者多方之间的达成的一致协定。 策略包含三个方面：1) 策略断言：多数情况是表示服务的实现方式。2) 策略所有人。3) 策略实行。 服务契约是具体化的策略断言，管理双方或者多方的需求和期望。契约致力于解决服务提供者和消费者之间的交互问题。 3.3. 执行上下文 执行上下文是一组实例化后的基础元素，进程实体，策略断言和契约，是服务能力执行过程中所依赖的各种因素的集合。 执行上下文是服务交互的核心，它通常在服务交互的过程中逐步产生，并可以随之服务交互内容改变而随之发生改变。 执行上下文同时也区分了不同的服务实体，对不同消费者提供的服务的互动进行区别。 执行上下文也是数据交换时解释数据的场所。一段特定字符串在特定的执行环境下，在服务互动中代表的意义也不同。 03 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)，服务质量QoS 9) 可拓展至实时操作系统 基于以上的约束并结合服务参考模型，AUTOSAR的服务模型的雏形就展现出来了。见附图。服务模型的核心是以Method, Event, Fields组织在一起的集合。为专门解决与当前CP AUTOSAR兼容性的问题，重新设计了用于车载领域的SOME/IP协议。还有就是以Proxy/Skeleton的范式作为客户端服务器端的通信方式。 图：AUTOSAR服务模型概略 04 结尾 未来AUTOSAR是不是最合适的面向服务的软件架构还需要时间去检验，但从它的设计理念和思路可以看出其着力于汽车系统的基本软件要求，努力做到往前和往后的系统兼容性。在当前看来，是相对完整并具操作性的面向服务的软件架构解决方案。  《浅谈汽车电子软件》专辑 进入汽车行业是偶然，但选择做软件是必然。听一位前辈说过，“你永远别指望一个人能把一件不喜欢的事做好”，软件技术一直是我的爱好，汽车也是我热爱的，庆幸当初的自己能选择这个行业。现在闲暇时写一些分享性的文章，希望和行业中的友人们一起成长。 作者：Paulfrank |
|
|
