量體裁衣式的服務(wù)架構(gòu)-AUTOSAR服務(wù)模型

量體裁衣式的服務(wù)架構(gòu)一AUTOSAR服務(wù)模型掌握一門技術(shù)通常都是從熟練運用開始，再逐步提煉成一套知識體系。而完備的知識體系可以反過來指導(dǎo)技術(shù)的革新，或者創(chuàng)造出在新領(lǐng)域中的專門技術(shù)。汽車軟件架構(gòu)正在經(jīng)歷這樣的過程，IT行業(yè)廣泛應(yīng)用的面向服務(wù)的架構(gòu)正在被引入其中。盡管從互聯(lián)網(wǎng)行業(yè)可以搜索到一籃子的相關(guān)軟件科技產(chǎn)品，然而這些碎片化的技術(shù)仍需要汽車工程師們進行系統(tǒng)化的梳理與整合。這方面走在前沿的當屬AUTOSAR，自適應(yīng)平臺的推出標志著向面向服務(wù)的汽車軟件架構(gòu)邁出了重要一步。AUTOSAR面向服務(wù)的軟件架構(gòu)可以方便地構(gòu)建在安全控制器(ClassicPlatform)，還有高性能處理器之上(AdaptivePlatform)。服務(wù)化的架構(gòu)設(shè)計離不開服務(wù)模型的設(shè)計，本文將跟隨設(shè)計者的思路談?wù)凙UTOSAR服務(wù)模型的設(shè)計思路和關(guān)注點。01服務(wù)架構(gòu)設(shè)計需考慮的因素面向服務(wù)的架構(gòu)設(shè)計流行于多種應(yīng)用領(lǐng)域，它深刻地影響著軟件設(shè)計和開發(fā)的各個方面。當汽車軟件架構(gòu)要轉(zhuǎn)向服務(wù)化，首先想到是遵從共同的范式設(shè)計。OASIS早在2006年就發(fā)布了開放標準一“面向服務(wù)架構(gòu)參考模型“。該參考模型是抽象層面的設(shè)計，并不直接指定任何的標準，技術(shù)或者具體的實現(xiàn)方案。另外，其提供了一系列共通的語義，可以明確地描述各種服務(wù)架構(gòu)的實現(xiàn)方案。貫穿整個參考模型的是各類設(shè)計要素，這些要素是指導(dǎo)SOA設(shè)計的關(guān)鍵。架構(gòu)相關(guān)的工作內(nèi)容包括參考架構(gòu)，架構(gòu)式樣，及其他模型。這些要素最終構(gòu)成了所需的軟件架構(gòu)方案。而這些內(nèi)容起始源自于參考模型，它是一系列活動的起源。

nnmnullrTSorjcaOriiiflLfK!Aiei:dcturnITpaTcnlaiorcnnmnullrTSorjcaOriiiflLfK!Aiei:dcturnITpaTcnlaiorcConciew任何一種架構(gòu)方案，不僅僅是面向服務(wù)的架構(gòu)，設(shè)計勢必是在某種訴求中產(chǎn)生的，這些解決現(xiàn)有問題的訴求就成為架構(gòu)設(shè)計的需求，以及要達到目的。架構(gòu)設(shè)計一方面是要滿足這些目的和需求，另一方面則是要考慮其運行環(huán)境，例如各種協(xié)議，規(guī)范和標準等。SOA的實現(xiàn)是以上要素綜合的成果，從一般性的架構(gòu)規(guī)范和基礎(chǔ)設(shè)施，再到針對專門需求所制定的運行環(huán)境，最終完成一個完整的SOA架構(gòu)設(shè)計。02服務(wù)參考模型對于面向服務(wù)的架構(gòu)定義，其中的一個解釋是：SOA是一種范式，用以組織和利用分散在不同領(lǐng)域之下的能力(capabilities)。而其中的核心概念一“服務(wù)”，至少包含三方面的內(nèi)容：1)為另一方執(zhí)行工作的能力。2)為另一方提供的工作規(guī)范。3)為另一方執(zhí)行工作的要約。能力與運用能力，概念上有所差別。需求與能力可以獨立于SOA而存在。而在SOA的架構(gòu)中，服務(wù)是將需求與能力兩者相結(jié)合起來的機制，這設(shè)計SOA的意義。回到汽車軟件面向服務(wù)化的架構(gòu)轉(zhuǎn)型，車內(nèi)傳統(tǒng)的執(zhí)行器與傳感器作為一種基本能力的實質(zhì)并未改變。在轉(zhuǎn)向面向服務(wù)的架構(gòu)后，改變的是在這些設(shè)備間建立起工作的規(guī)范和要約方法，同時還能提升這些設(shè)備的復(fù)用性，拓展性，互用性等其他特性。下圖展示了參考模型中一些主要的概念：服務(wù)的概念“服務(wù)”是提供訪問與使用其他域中某些能力的一項機制，訪問的過程需要通過規(guī)定的接口進行，同時需要滿足服務(wù)描述中所定義的相關(guān)約束條件和策略。服務(wù)通常需要通過某個實體來提供-稱做服務(wù)提供者(ServiceProvider)，而另一方稱做服務(wù)消費者(Serviceconsumer)。服務(wù)的實現(xiàn)通常對服務(wù)消費者不可見，所以需要定義服務(wù)接口(ServiceInterface)，其目的是讓服務(wù)消費者了解服務(wù)所包含的范圍，并規(guī)范的去訪問服務(wù)的內(nèi)容。服務(wù)的動態(tài)響應(yīng)性服務(wù)相互作用的方式主要有3個基本概念：可見性(Visibility)，真實世界效應(yīng)(Realworldeffect)，相互作用(Interaction)。2.1.可見性對于服務(wù)的提供者和消費者，它們互動的前提是知道對方的存在?？梢娦园矫娴那疤幔鼈兪牵?)存在性(awareness):使己方可被他方可見，并進入待發(fā)現(xiàn)的狀態(tài)。這種發(fā)現(xiàn)的過程通常稱作服務(wù)發(fā)現(xiàn)機制(ServiceDiscovery)。2)意愿性(willingness):參與服務(wù)的交互，例如注冊某個服務(wù)，即開始服務(wù)內(nèi)容的交互。服務(wù)的意愿性受服務(wù)策略的制約。3)可到達性(reachability):服務(wù)雙方在網(wǎng)絡(luò)中的地址，使用的協(xié)議，服務(wù)當前是否可用等。服務(wù)的相互作用服務(wù)的相互作用通常是消息的發(fā)送和接受，另外還包含的情況是狀態(tài)的遷移和改變。服務(wù)的相互作用圍繞著服務(wù)描述，它們是：1)信息模型(Informationmodel):服務(wù)交換數(shù)據(jù)的句法結(jié)構(gòu)與語義。2)行為模型(Behaviormodel):包括動作模型和過程模型，它們確切地描述業(yè)務(wù)相關(guān)的動作和流程，和服務(wù)的應(yīng)用領(lǐng)域密切相關(guān)。真實世界效應(yīng)如果讓服務(wù)去完成某件事情，這個動作產(chǎn)生的結(jié)果就被認為是真實世界效應(yīng)。這類效應(yīng)包括：1)回復(fù)被請求的信息。2)實體狀態(tài)的變化。3)以上兩種效應(yīng)的組合。服務(wù)的提供者和消費者的動作是對于共享狀態(tài)的改變。服務(wù)相互作用的真實世界效應(yīng)就是對共享狀態(tài)的累計狀態(tài)變化。關(guān)于服務(wù)為支持服務(wù)的互動性，服務(wù)本身通過以下三個方面來展現(xiàn)：服務(wù)接口(Servicedescription)，契約和策略(Contractsandpolicies)，執(zhí)行環(huán)境(Executioncontext)。3.1.服務(wù)描述SOA的特征就是有大量的文檔和描述。服務(wù)描述包含了使用該服務(wù)所需要的信息，反映的是各方對于運行實體和執(zhí)行環(huán)境的要求，還包括信息模型，功能與策略等。服務(wù)描述的目的是促進服務(wù)參與者之間的互動性和可見性。通過描述信息，使得潛在的參與者去建立提供服務(wù)的系統(tǒng)。每項服務(wù)包含哪些能力，怎么樣去接入和使用這些服務(wù)，在服務(wù)描述中都有所體現(xiàn)。服務(wù)描述要求使用標準，可引用的格式，例如使用標準的處理工具（如發(fā)現(xiàn)引擎）把服務(wù)描述具體化。SOA的理念中，服務(wù)消費者并不需要知道服務(wù)實現(xiàn)的細節(jié)，所以服務(wù)描述應(yīng)包含關(guān)鍵的信息，以讓服務(wù)的消費者決定是否使用該服務(wù)。通常服務(wù)的消費者需要知道以下的信息：1）服務(wù)存在并可到達。2）服務(wù)所執(zhí)行的功能：服務(wù)描述需準確的描述服務(wù)被調(diào)用后所產(chǎn)生的真實世界效應(yīng)，以及包含服務(wù)所提供的功能的局限性與技術(shù)假設(shè)。3）服務(wù)運行的約束（constraints）和策略（Policies），服務(wù)將符合哪些規(guī)定的策略等。4）服務(wù)交互的方法：包括雙方交換信息的格式和內(nèi)容。通常被稱作為服務(wù)接口（ServiceInterface），它包括指定的協(xié)議，方法，信息交互的方式。服務(wù)接口和接入方式的描述是SOA最重要的部分。契約和策略策略代表某種使用服務(wù)的約束或者條件。而契約則代表者多方之間的達成的一致協(xié)定。策略包含三個方面：1）策略斷言：多數(shù)情況是表示服務(wù)的實現(xiàn)方式。2）策略所有人。3）策略實行。服務(wù)契約是具體化的策略斷言，管理雙方或者多方的需求和期望。契約致力于解決服務(wù)提供者和消費者之間的交互問題。執(zhí)行上下文執(zhí)行上下文是一組實例化后的基礎(chǔ)元素，進程實體，策略斷言和契約，是服務(wù)能力執(zhí)行過程中所依賴的各種因素的集合。執(zhí)行上下文是服務(wù)交互的核心，它通常在服務(wù)交互的過程中逐步產(chǎn)生，并可以隨之服務(wù)交互內(nèi)容改變而隨之發(fā)生改變。執(zhí)行上下文同時也區(qū)分了不同的服務(wù)實體，對不同消費者提供的服務(wù)的互動進行區(qū)別。執(zhí)行上下文也是數(shù)據(jù)交換時解釋數(shù)據(jù)的場所。一段特定字符串在特定的執(zhí)行環(huán)境下，在服務(wù)互動中代表的意義也不同。03AUTOSAR服務(wù)模型AUTOSAR服務(wù)模型從很多方面遵循了OASIS的參考模型。之前的文章已經(jīng)提到過，APAUTOSAR并不是要取代CPAUTOSAR，而是要衍生拓展對于服務(wù)化的支持。所以AUTOSAR服務(wù)模型的設(shè)計需充分考慮以下約束。1）支持應(yīng)用軟件組件的獨立性。應(yīng)用軟件組件獨立性主要體現(xiàn)在單一功能的劃分，并盡量減少和其他功能模塊的交互。數(shù)據(jù)交互的接口采用服務(wù)化的設(shè)計，以標準的通信中間件實現(xiàn)應(yīng)用之間的交互。2）不依賴于特定通訊協(xié)議的面向服務(wù)架構(gòu)服務(wù)可綁定不同的網(wǎng)絡(luò)傳輸層協(xié)議，以支持適用于實時操作系統(tǒng)的跨網(wǎng)絡(luò)傳輸協(xié)議（如SOME/IP），適用于大數(shù)據(jù)量的傳輸層協(xié)議（如DDS），適用于高性能場合的IPC通信。3）API盡可能性的精簡，僅提供核心的通訊機制業(yè)務(wù)層面的服務(wù)相關(guān)設(shè)計，不是AUTOSAR的關(guān)注點，應(yīng)交給OEM和軟件供應(yīng)商，讓他們自由地發(fā)揮想象力，去實現(xiàn)應(yīng)用層級別的服務(wù)框架。4）支持動態(tài)的通訊機制，由APP掌控服務(wù)發(fā)現(xiàn)過程5）需同時支持基于事件和基于輪詢的應(yīng)用調(diào)用樣式，使得通過CPAUTOSAR中RTE的API式樣依然可以調(diào)用服務(wù)的方法。另外為支持確定性執(zhí)行的要求，通信管理模塊需支持應(yīng)用進程異步上下文切換，app采用時間片輪詢的方式進行調(diào)度，并由應(yīng)用程序掌控數(shù)據(jù)收集和數(shù)據(jù)發(fā)送，從而避免不必要的上下文切換。6）支持同步通信和異步通信兩種方式7）支持client/server，sender/receiver（withcaches）的通信機制一般情況下應(yīng)用之間主要產(chǎn)生的交互是數(shù)據(jù)交換和功能調(diào)用，在CPAUTOSAR中，已有SenderReceiver，ClientServer兩種典型的通信機制。前者對應(yīng)的是數(shù)據(jù)交換，后者對應(yīng)的是功能調(diào)用，由RTE統(tǒng)一完成應(yīng)用之間的通信。面向服務(wù)化后，依然需要滿足這兩種基本的通信機制，使CP和AP兩個平臺可以無縫的銜接。8）拓展Security和Safety的功能（例如在CP平臺已應(yīng)用的SecOC,E2E），服務(wù)質(zhì)量QoS9）可拓展至實時操作系統(tǒng)基于以上的約束并結(jié)合服務(wù)參考模型，AUTOSAR的服務(wù)模型的雛形就展現(xiàn)出來了。見附圖。服務(wù)模型的核心是以Method,Event,Fields組織在一起的集合。為專門解決與當前CPAUTOSAR兼容性的問題