本發(fā)明涉及用于處理面向服務(wù)的中間件互聯(lián)網(wǎng)協(xié)議(Service Oriented Middleware over Internet Protocol，SOME/IP)流的方法和裝置，更具體地，涉及用于通過(guò)與音頻視頻橋接(Audio Video Bridging，AVB)技術(shù)交互工作(interworking)來(lái)處理SOME/IP流的方法和裝置，其中，在車載網(wǎng)絡(luò)中的SOME/IP服務(wù)處理過(guò)程期間，流的傳輸與AVB功能交互工作，以使SOME/IP服務(wù)流的服務(wù)質(zhì)量(Quality of Service，QoS)可得到保證。

背景技術(shù)：

IT最近的快速發(fā)展極大地影響了汽車工業(yè)，并且各種IT技術(shù)被應(yīng)用到車輛。

因此，為了支持各種功能，車載通信網(wǎng)絡(luò)變得更加復(fù)雜，并且應(yīng)用各種通信方案以在車輛控制器之間執(zhí)行有效的通信。

最近，控制器局域網(wǎng)(CAN)和本地互連網(wǎng)絡(luò)(LIN)主要用作當(dāng)前被應(yīng)用到車輛的總線通信系統(tǒng)。

另外，隨著車輛中所加載的控制器數(shù)目的增多以及控制器之間交換的信息量的增加，要求更寬的帶寬和更穩(wěn)定的通信環(huán)境，因此諸如FlexRay和面向媒體的系統(tǒng)傳輸(Media Oriented System Transport，MOST)的通信接口被用于車載通信中。

此外，比CAN 100快100倍或更多倍的以太網(wǎng)通信正作為新的車載通信方法吸引著注意。

車載以太網(wǎng)有望被用作批量生產(chǎn)的車輛中的系統(tǒng)網(wǎng)絡(luò)，且通過(guò)非屏蔽雙絞線(Unshielded Twisted Pair，UTP)連接以100MBit/s的速度在車輛中經(jīng)濟(jì)地傳輸攝像機(jī)圖像是可能的。該技術(shù)被稱為BroadR-Reach，并通過(guò)開放聯(lián)盟SIG協(xié)會(huì)(OPEN Alliance SIG consortium)標(biāo)準(zhǔn)化。

車載網(wǎng)絡(luò)已經(jīng)變成基于以太網(wǎng)通信，并且本領(lǐng)域的目標(biāo)為，到2015年，使用車載網(wǎng)絡(luò)作為用于信息娛樂(lè)和驅(qū)動(dòng)支持系統(tǒng)的網(wǎng)絡(luò)。一些OEM期望以太網(wǎng)從2018年開始將為主干網(wǎng)。

BMW已經(jīng)開發(fā)了名為“面向服務(wù)的中間件互聯(lián)網(wǎng)協(xié)議(SOME/IP)”的串行化協(xié)議。SOME/IP用于通過(guò)服務(wù)發(fā)現(xiàn)(service discovery，SD)協(xié)議確認(rèn)車輛中的電子控制單元(ECU)的服務(wù)是否可用。另外，SOME/IP用于發(fā)現(xiàn)服務(wù)并在ECU中注冊(cè)事件。

SOME/IP與音頻視頻橋接(AVB)被一起定義在AUTOSAR系統(tǒng)架構(gòu)上，但未定義傳輸將通過(guò)SOME/IP服務(wù)(例如，前攝像機(jī)和后攝像機(jī)以及導(dǎo)航系統(tǒng))傳輸?shù)膶?流同時(shí)通過(guò)AVB技術(shù)保證QoS的過(guò)程。根據(jù)當(dāng)前定義的SOME/IP，只能通過(guò)傳輸控制協(xié)議(Transmission Control Protocol，TCP)或用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol，UDP)才可處理將被傳輸?shù)牧鳌?/p>

技術(shù)實(shí)現(xiàn)要素：

因此，本發(fā)明針對(duì)通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置，其基本上避免了由于現(xiàn)有技術(shù)的限制和缺陷所引起的一個(gè)或多個(gè)問(wèn)題。

本發(fā)明的目的在于提供通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置。

本發(fā)明的另一個(gè)目的在于提供通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置，其中在車載網(wǎng)絡(luò)中的SOME/IP服務(wù)處理過(guò)程期間，層2流的傳輸與AVB功能交互工作，以使SOME/IP服務(wù)流的QoS可得到保證。

本發(fā)明另外的優(yōu)點(diǎn)、目的和特征在隨后的說(shuō)明書中部分給出，并且在檢視以下內(nèi)容后，這些優(yōu)點(diǎn)、目的和特征對(duì)本領(lǐng)域技術(shù)人員將顯而易見，或者可從本發(fā)明的實(shí)踐學(xué)習(xí)。本發(fā)明的目標(biāo)和其他優(yōu)點(diǎn)可通過(guò)說(shuō)明書、權(quán)利要求書以及附圖中具體指出的結(jié)構(gòu)來(lái)實(shí)現(xiàn)和獲得。

為了實(shí)現(xiàn)這些目的和其他優(yōu)點(diǎn)，根據(jù)本發(fā)明的意圖，如本文所實(shí)施和廣泛描述的，通過(guò)在服務(wù)器中與音頻視頻橋接(Audio Video Bridging，AVB)交互工作來(lái)處理面向服務(wù)的中間件互聯(lián)網(wǎng)協(xié)議(Service Oriented Middleware over Internet Protocol，SOME/IP)流的方法包括：通過(guò)SOME/IP服務(wù)發(fā)現(xiàn)過(guò)程來(lái)確定SOME/IP流的傳輸方案，以及根據(jù)所確定的傳輸方案生成InitialEvent消息，并且將所生成的InitialEvent消息傳輸?shù)娇蛻舳恕Ｈ绻_定的傳輸方案為L(zhǎng)2-幀，則通過(guò)AVB的層2傳輸SOME/IP流。

在本發(fā)明的另一個(gè)方面，通過(guò)在與服務(wù)器交互工作的客戶端中與音頻視頻橋接(AVB)交互工作來(lái)處理面向服務(wù)的中間件互聯(lián)網(wǎng)協(xié)議(SOME/IP)流的方法包括：通過(guò)SOME/IP服務(wù)發(fā)現(xiàn)過(guò)程來(lái)確定SOME/IP流的傳輸方案，以及從服務(wù)器接收對(duì)應(yīng)于所確定的傳輸方案的InitialEvent消息。如果所確定的傳輸方案為L(zhǎng)2-幀，則通過(guò)AVB的層2傳輸SOME/IP流。

應(yīng)理解的是，本發(fā)明的上述概括描述和以下詳細(xì)描述兩者為示例性和說(shuō)明性的，并且旨在提供如所要求保護(hù)的本發(fā)明的進(jìn)一步說(shuō)明。

附圖說(shuō)明

本申請(qǐng)所包括的用于提供本發(fā)明的進(jìn)一步理解并被并入本申請(qǐng)構(gòu)成本申請(qǐng)一部分的附圖示出了本發(fā)明的實(shí)施例，并與說(shuō)明書一起用于解釋本發(fā)明的原理。在附圖中：

圖1為示出傳統(tǒng)SOME/IP消息格式的視圖；

圖2為示出傳統(tǒng)AUTOSAR OS軟件堆棧(software stacks)的視圖；

圖3為示出傳統(tǒng)SOME/IP服務(wù)供應(yīng)過(guò)程的流程圖；

圖4為示出IEEE 802.1Qat中傳統(tǒng)資源預(yù)留過(guò)程的視圖；

圖5為示出在IEEE 802.1Qat中定義的傳統(tǒng)預(yù)留消息的結(jié)構(gòu)的視圖；

圖6為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，用于與AVB功能交互工作的SOME/IP消息格式的視圖；

圖7為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，用于為SOME/IP流與AVB技術(shù)交互工作的方法的視圖；

圖8為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，通過(guò)與AVB功能交互工作供應(yīng)SOME/IP流的過(guò)程的流程圖；以及

圖9為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，通過(guò)與AVB功能交互工作供應(yīng)SOME/IP流的過(guò)程的流程圖。

具體實(shí)施方式

現(xiàn)在將詳細(xì)參考本發(fā)明的優(yōu)選實(shí)施例，其中在附圖中示出該優(yōu)選實(shí)施例的示例。本說(shuō)明書下面所使用的元件的后綴“模塊”和“單元”僅出于易起草說(shuō)明書的考慮而一起給出或使用，不具有區(qū)分的意義或功能。

下文中，盡管本發(fā)明的一個(gè)實(shí)施例將所有元件組合示出，但本發(fā)明的實(shí)施例不局限于此。也就是說(shuō)，可在本發(fā)明的范圍內(nèi)選擇性地組合所有元件中的一個(gè)或多個(gè)。進(jìn)一步地，可通過(guò)獨(dú)立的硬件分別實(shí)施所有元件，或者元件中的一些可被選擇性地組合并因此通過(guò)具有程序模塊的計(jì)算機(jī)程序?qū)嵤摮绦蚰K執(zhí)行多個(gè)硬件中的組合的元件的功能。本領(lǐng)域技術(shù)人員可以容易地推斷組成計(jì)算機(jī)程序的代碼和代碼片段。該計(jì)算機(jī)程序存儲(chǔ)在計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)中，并且通過(guò)計(jì)算機(jī)讀取和執(zhí)行，因此能夠?qū)嵤┍景l(fā)明的實(shí)施例。計(jì)算機(jī)程序的存儲(chǔ)媒介可包括磁記錄介質(zhì)、光學(xué)記錄介質(zhì)、載波介質(zhì)等等。

進(jìn)一步地，應(yīng)理解的是，本說(shuō)明書中的術(shù)語(yǔ)“包括”、“組成”或“具有”是指可包括相應(yīng)元件，并且可進(jìn)一步包括除該元件之外的其他元件。應(yīng)理解的是，包括技術(shù)或科學(xué)術(shù)語(yǔ)的所有術(shù)語(yǔ)具有如本領(lǐng)域技術(shù)人員所通常理解的相同的意義。通用術(shù)語(yǔ)，諸如詞典中所定義的術(shù)語(yǔ)，可被解釋為具有與本領(lǐng)域中所使用的意義一致的意義，并且可不被解釋為具有理想的或過(guò)于正式的意義。

進(jìn)一步地，在本發(fā)明的元件的描述中，可使用術(shù)語(yǔ)“第一”、“第二”、“A”、“B”、“(a)”、“(b)”等等。這些術(shù)語(yǔ)僅用于區(qū)分元件，并且不用這些術(shù)語(yǔ)限制相應(yīng)元件的特性、順序或次序。如果指明元件“連接到”、“組合有”或“耦合有”另一個(gè)元件，則應(yīng)理解的是，前者可直接連接到或組合有后者，或者可在兩個(gè)元件間插入其他元件。

圖1為示出傳統(tǒng)SOME/IP消息格式的視圖。

SOME/IP為車輛音頻視頻導(dǎo)航(Audio Video Navigation，AVN)系統(tǒng)和電子控制單元(ECU)之間的以太網(wǎng)通信協(xié)議，并通過(guò)TCP/IP的服務(wù)器/客戶端處理來(lái)傳輸數(shù)據(jù)。

在SOME/IP中，可通過(guò)服務(wù)發(fā)現(xiàn)(SD)協(xié)議確認(rèn)車輛中的服務(wù)是否可用。另外，SOME/IP可用于服務(wù)發(fā)現(xiàn)和ECU中的事件注冊(cè)。可在服務(wù)發(fā)現(xiàn)中確定何種傳輸協(xié)議用于傳輸、接收和處理數(shù)據(jù)。例如，可使用的傳輸協(xié)議可包括傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報(bào)協(xié)議(UDP)。

圖1示出SOME/IP消息的結(jié)構(gòu)。服務(wù)器傳輸各種各樣的服務(wù)，其中可通過(guò)服務(wù)器(例如，前攝像機(jī)和后攝像機(jī)以及導(dǎo)航系統(tǒng))經(jīng)服務(wù)ID將所述服務(wù)提供給客戶端，并且要求服務(wù)的客戶端通過(guò)服務(wù)請(qǐng)求注冊(cè)實(shí)例ID(instance ID)，并從而接收所期望的服務(wù)。

圖2為示出傳統(tǒng)AUTOSAR OS軟件堆棧的視圖。

更詳細(xì)地，圖2示出AUTOSAR OS上的SOME/IP和音頻視頻橋接(AVB)中所需的軟件的配置，其按照OSI層分割。

通常，在AUTOSAR系統(tǒng)的情況下，服務(wù)器可識(shí)別將通過(guò)SD經(jīng)由服務(wù)發(fā)現(xiàn)接收相應(yīng)服務(wù)的客戶端，并通過(guò)TCP和UDP將相應(yīng)的服務(wù)流傳輸?shù)剿R(shí)別的客戶端。

然而，最近，當(dāng)通過(guò)SOME/IP的SD發(fā)現(xiàn)服務(wù)并隨后傳輸服務(wù)時(shí)，SOME/IP在不與AVB交互工作的情況下單獨(dú)地操作。另外，盡管定義了保證QoS的AVB，但并未在標(biāo)準(zhǔn)中明確地定義用于使AVB與SOME/IP交互工作以便應(yīng)用到實(shí)際系統(tǒng)的方法。

圖3為示出傳統(tǒng)SOME/IP服務(wù)供應(yīng)過(guò)程的流程圖。

在服務(wù)發(fā)現(xiàn)(SD)過(guò)程S320中，服務(wù)器310傳輸OfferService(提供服務(wù))消息，其包括指示各種各樣的服務(wù)的服務(wù)ID，其中可使用組播方案(multicast scheme)通過(guò)服務(wù)器310將服務(wù)提供到客戶端350(操作S321)。

此后，客戶端350確認(rèn)包括在OfferService消息中的服務(wù)ID，并且如果存在客戶端350所需的服務(wù)，則將包括客戶端350的IP地址和端口號(hào)的SubscribeEventgroup(訂閱事件組)消息傳輸?shù)椒?wù)器310(操作S323)。

服務(wù)器310響應(yīng)于SubscribeEventgroup消息，使用單播方案將SubscribeEventgroupACK(訂閱事件組ACK)消息傳輸?shù)娇蛻舳?50(操作S325)。

此后，服務(wù)器310可在事件供應(yīng)過(guò)程330中通過(guò)UDP將大量服務(wù) 流提供到客戶端350。

在事件供應(yīng)過(guò)程330中，服務(wù)器310將InitialEvent(初始化事件)消息傳輸?shù)娇蛻舳?50，并然后每當(dāng)事件發(fā)生時(shí)，將Event/Notification(事件/通知)消息傳輸?shù)娇蛻舳?50(操作S331到S335)。傳輸InitialEvents消息和Event/Notification消息時(shí)所使用的傳輸協(xié)議可為UDP，如圖3中示例性地示出。

如果客戶端350不再要求向服務(wù)器310請(qǐng)求的服務(wù)，則客戶端350可傳輸StopSubscribeEventgroup(停止訂閱事件組)消息到服務(wù)器310以停止服務(wù)流的傳輸(操作S337)。

圖4為示出IEEE 802.1Qat中的傳統(tǒng)資源預(yù)留過(guò)程的視圖。

在AVB技術(shù)當(dāng)中，IEEE 802.1Qat是關(guān)于多流預(yù)留協(xié)議(Multiple Stream Reservation Protocol，MSRP)的標(biāo)準(zhǔn)，用以保證以太網(wǎng)環(huán)境中實(shí)時(shí)流量的QoS，并定義了用于提供端到端，例如網(wǎng)橋/交換機(jī)和終端之間，QoS得到保證的流的資源預(yù)留方法的詳細(xì)規(guī)范。具體地，MSRP在OSI模型中定義了層2(數(shù)據(jù)鏈路層)中流式傳送的概念。在IEEE802.1Qat中，傳輸資源或流的終端被定義為發(fā)話者(talker)(源節(jié)點(diǎn)(source node))，希望接收源或流的終端被定義為收聽者(listener)，并且發(fā)話者和收聽者使用信令(signaling)(廣告(advertising)和就緒(ready))消息執(zhí)行資源預(yù)留過(guò)程。

圖4示出使用信令(廣告和就緒)消息進(jìn)行資源預(yù)留的示例。用于資源預(yù)留的廣告和準(zhǔn)備消息包括諸如用于識(shí)別特定流的流ID、對(duì)所有幀的VLAN ID分類的數(shù)據(jù)幀優(yōu)先級(jí)、用于帶寬競(jìng)爭(zhēng)的等級(jí)(Rank)以及指示服務(wù)的大小的流量規(guī)格(Traffic Specification，Tspec)的信息。等級(jí)指示相應(yīng)流的重要性，例如諸如911電話和安全公告的流的重要性可被設(shè)置為高于其他一般流的重要性。

參考圖4，具有將被傳輸?shù)臄?shù)據(jù)的發(fā)話者將廣告消息傳輸給所有收聽者。在已經(jīng)通過(guò)交換機(jī)接收了廣告消息的收聽者當(dāng)中，希望接收數(shù)據(jù)的收聽者設(shè)置流接收，并傳輸就緒消息以預(yù)留帶寬。就緒消息預(yù)留交換機(jī)的帶寬，通過(guò)該交換機(jī)的帶寬傳遞將要傳輸給發(fā)話者的就緒消息，也即分配傳輸相應(yīng)流所需的交換機(jī)的帶寬。當(dāng)在發(fā)話者中注冊(cè)了通過(guò)收聽者傳輸?shù)木途w消息時(shí)，發(fā)話者開始傳輸數(shù)據(jù)流。

上述Tspec信息是關(guān)于由發(fā)話者產(chǎn)生的流的期望大小的信息，并用于計(jì)算當(dāng)通過(guò)交換機(jī)或網(wǎng)關(guān)傳輸數(shù)據(jù)時(shí)所需的帶寬以及用于分配交換機(jī)中所需的帶寬。Tspec信息包括帶寬/秒和幀速率/秒信息。借此，每個(gè)交換機(jī)可保證特定的預(yù)留流的QoS。如果發(fā)話者所希望傳輸?shù)牧鞯拇笮〕隽私粨Q機(jī)可提供的帶寬備用區(qū)域，則發(fā)話者和收聽者接收預(yù)留失敗消息，其指示未正確地執(zhí)行預(yù)留且停止流預(yù)留。

圖5為示出在IEEE 802.1Qat中定義的傳統(tǒng)預(yù)留消息的結(jié)構(gòu)的視圖。

更詳細(xì)地，圖5示出通過(guò)發(fā)送器傳輸?shù)膹V告消息的結(jié)構(gòu)。

參考圖5，廣告消息包括分別具有8字節(jié)長(zhǎng)度的流ID(Stream ID)、數(shù)據(jù)幀參數(shù)(Data Frame Parameter)和Tspec、具有3比特長(zhǎng)度的數(shù)據(jù)幀優(yōu)先級(jí)(Data Frame Priority)、具有最大5比特長(zhǎng)度的等級(jí)(Rank)、具有4字節(jié)長(zhǎng)度的累積延遲(Accumulated Latency)、具有8字節(jié)長(zhǎng)度的網(wǎng)橋ID(Bridge ID)，以及具有1字節(jié)長(zhǎng)度的故障代碼(Failure Code)。

這里，流ID包括MAC地址，用以記錄發(fā)話者的MAC地址，以及2字節(jié)的唯一ID。

數(shù)據(jù)幀參數(shù)包括6字節(jié)的目標(biāo)地址(Destination Address)，用以記錄將接收相應(yīng)流的目標(biāo)節(jié)點(diǎn)的MAC地址，以及2字節(jié)的VLAN標(biāo)識(shí)符。

Tspec包括2字節(jié)長(zhǎng)度的MaxFrameSize，其指示每秒傳輸?shù)淖畲笞止?jié)數(shù)目，即帶寬，以及MaxIntervalFrames，其指示單位時(shí)間的幀的數(shù)目。

圖6為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，用于與AVB功能交互工作的SOME/IP消息格式的視圖。

在本發(fā)明中，將用于與AVB功能交互工作的消息格式添加到SOME/IP消息，并且因此可傳輸QoS可得到保證的AVB層2流。

出于該目的，根據(jù)本發(fā)明的SOME/IP消息600可將用于與層2AVB功能交互工作的MAC地址(MACaddr)610添加到圖1的傳統(tǒng)SOME/IP消息100。

因此，服務(wù)器可將相應(yīng)客戶端的MAC地址信息添加到SOME/IP消息600，以使可通過(guò)AVB層2的L2-幀將服務(wù)流傳輸?shù)娇蛻舳恕?/p>

SOME/IP消息600中所包括的L4-協(xié)議(L4-Proto)620字段為用 于識(shí)別傳輸協(xié)議的字段，該傳輸協(xié)議將用于在已經(jīng)完成SD過(guò)程之后傳輸所請(qǐng)求的數(shù)據(jù)流。在SOME/IP中通常定義的傳輸協(xié)議包括僅UDP和TCP。例如，對(duì)應(yīng)于UDP和TCP的L4-協(xié)議620的值可被定義為0x11和0x01。

在本發(fā)明中，可最新定義向L4-協(xié)議620指示層2流傳輸?shù)腖2-SRP(0x21)，以使可通過(guò)與AVB交互工作將SOME/IP流傳輸?shù)綄?，以便保證QoS。

因此，收聽者可確認(rèn)包括在所接收的InitialEvent消息中的L4-協(xié)議620字段的值，并因此確認(rèn)將通過(guò)何種傳輸方案來(lái)傳輸相應(yīng)方案。

根據(jù)本發(fā)明的一個(gè)實(shí)施例的收聽者可支持SOME/IP但可能不支持AVB。在這種情況下，如果收聽者接收到通知基于AVB進(jìn)行L2-幀傳輸?shù)腎nitialEvent消息，即，如果L4-協(xié)議620字段的值被設(shè)置為L(zhǎng)2-SRP，則收聽者可向發(fā)話者傳輸包括指定的故障代碼的就緒消息，該指定的故障代碼指示AVB不被支持。

此時(shí)，發(fā)話者通過(guò)所接收的故障代碼可確認(rèn)相應(yīng)接收器中的L2-幀接收被禁用，將所請(qǐng)求的服務(wù)流轉(zhuǎn)換為AVB傳輸(即L2-幀傳輸)以外的TCP或UDP模式，并然后將所轉(zhuǎn)換的流傳輸給收聽者。

根據(jù)本發(fā)明的另一個(gè)實(shí)施例，可提前定義并在發(fā)話者中維護(hù)根據(jù)所提供服務(wù)的類型的傳輸方案。在這種情況下，當(dāng)通過(guò)SD過(guò)程確認(rèn)了收聽者所請(qǐng)求的服務(wù)時(shí)，發(fā)話者可使用對(duì)應(yīng)于所請(qǐng)求的服務(wù)的傳輸方案來(lái)傳輸相應(yīng)服務(wù)。

例如，可將可靠性較高的AVB傳輸方案，即層2傳輸方案，應(yīng)用到高速實(shí)時(shí)圖象數(shù)據(jù)流，并且可將諸如通過(guò)SOME/IP的UDP或TCP的層4傳輸方案應(yīng)用到低速數(shù)據(jù)。

圖7為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，用于為SOME/IP流傳輸與AVB技術(shù)交互工作的方法的視圖。

根據(jù)本發(fā)明的服務(wù)器可通過(guò)SD過(guò)程獲得客戶端的IPv4地址和端口號(hào)，并附加地獲得客戶端的MAC地址(MACaddr)610。

當(dāng)通過(guò)SD過(guò)程獲得了客戶端的MAC地址時(shí)，服務(wù)器可通過(guò)在下文中被簡(jiǎn)稱為L(zhǎng)2-幀(L2-Frame)的基于AVB的層2幀(AVB-based layer2frame)來(lái)將SOME/IP服務(wù)流傳輸?shù)娇蛻舳恕?/p>

參考圖7，服務(wù)器可通過(guò)SD過(guò)程獲得客戶端的MAC地址，在預(yù)留消息700中記錄所獲得的MAC地址以用于流的預(yù)留，即，廣告消息的目標(biāo)地址710字段，并且將預(yù)留消息700傳輸?shù)较鄳?yīng)客戶端。

參考圖4，傳統(tǒng)Qat預(yù)留過(guò)程包括通過(guò)MAC廣播從多個(gè)不特定的收聽者中找到要求預(yù)留傳輸?shù)姆?wù)接收者的廣告過(guò)程，以及獲得所述接收者的MAC地址并同時(shí)分配位于傳輸路由上的交換機(jī)的所需帶寬的就緒過(guò)程。

然而，在根據(jù)本發(fā)明通過(guò)與AVB交互工作的SOME/IP流傳輸方案中，服務(wù)器通過(guò)SOME/IP的SD過(guò)程提前確認(rèn)要求服務(wù)接收的客戶端以及相應(yīng)客戶端的MAC地址信息，并且因此，AVB的流預(yù)留過(guò)程不要求單獨(dú)的客戶端MAC地址獲取過(guò)程。

進(jìn)一步地，在本發(fā)明中，可通過(guò)AVB流預(yù)留分配過(guò)程將AVB流的傳輸優(yōu)先級(jí)分配給具有相同特性的SOME/IP流，并且因此，可通過(guò)更多種方案保證QoS。例如，可通過(guò)根據(jù)車輛安全性要求將不同的優(yōu)先級(jí)授予傳輸多媒體數(shù)據(jù)的前攝像機(jī)、后攝像機(jī)和導(dǎo)航系統(tǒng)來(lái)提供各種QoS服務(wù)。

圖8為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，通過(guò)與AVB功能交互工作供應(yīng)SOME/IP流的過(guò)程的流程圖。

更詳細(xì)地，圖8示出通過(guò)與AVB交互工作，從SOME/IP中的SD過(guò)程到事件的傳輸和終止的整個(gè)功能交互工作過(guò)程。

參考圖8，當(dāng)已經(jīng)完成了SOME/IP SD過(guò)程S820時(shí)，服務(wù)器810將傳輸服務(wù)流的InitialEvent消息傳輸?shù)娇蛻舳?50的MAC地址。在該過(guò)程期間，客戶端850可檢測(cè)所傳輸流的最大幀大小(MaxFrameSize)，并根據(jù)各種各樣的服務(wù)(SR-型A、B)檢測(cè)最大幀傳輸時(shí)段(MaxIntervalFrames)。以上所描述的兩個(gè)值是通過(guò)預(yù)留消息傳輸來(lái)分配交換機(jī)的帶寬所必需的，并被稱為Tspec信息。此后，服務(wù)器810作為發(fā)話者860操作且客戶端850作為收聽者870操作，發(fā)話者860通過(guò)InitialEvent消息將一個(gè)流傳輸?shù)绞章犝?70，并且收聽者870經(jīng)由該流通過(guò)的交換機(jī)將就緒消息傳輸?shù)桨l(fā)話者860，以使可分配各交換機(jī)的帶寬。

當(dāng)發(fā)話者860成功地接收就緒消息時(shí)，發(fā)話者860識(shí)別流預(yù)留被 正常地執(zhí)行，并開始預(yù)留傳輸。也就是說(shuō)，只要存在要傳輸?shù)牧鳎l(fā)話者860就可生成事件/通知消息并將該事件/通知消息傳輸?shù)绞章犝?70。

如果客戶端850希望服務(wù)終止，則客戶端850可將StopSubscribeEventgroup消息傳輸?shù)椒?wù)器810，以請(qǐng)求停止相應(yīng)服務(wù)流的傳輸。此后，服務(wù)器810可根據(jù)Qat標(biāo)準(zhǔn)過(guò)程執(zhí)行取消被分配到流預(yù)留被停止的交換機(jī)的帶寬的帶寬取消過(guò)程。

具體地，根據(jù)本發(fā)明的發(fā)話者860可通過(guò)將包括客戶端850的MAC地址信息以及通知AVB L2-幀傳輸?shù)腖2-SRP信息的InitialEvent消息傳輸?shù)绞章犝?70，經(jīng)與AVB交互工作來(lái)執(zhí)行流的預(yù)留傳輸。這里，InitialEvent消息可包括流的預(yù)留傳輸所必需的Tspec信息以及含有Tspec信息的廣告消息。收聽者870可通過(guò)將包括所接收的Tspec信息的就緒消息傳輸?shù)桨l(fā)話者860來(lái)接收所預(yù)留并被分配給位于相應(yīng)服務(wù)流的傳輸路徑上的交換機(jī)的帶寬。

如果InitialEvent消息中所包括的L4-協(xié)議620字段值被設(shè)置為L(zhǎng)2-SRP且客戶端850不支持AVB功能，則客戶端850可將StopSubscribeEventgroup消息傳輸?shù)椒?wù)器810，該StopSubscribeEventgroup消息包括指定的宣布禁用L2-幀接收的錯(cuò)誤代碼。

此后，服務(wù)器810可將L4-協(xié)議620字段值設(shè)置為對(duì)應(yīng)于UDP或TCP的值，然后將InitialEvent消息傳輸?shù)娇蛻舳?50，以使可通過(guò)UDP或TCP傳輸相應(yīng)服務(wù)流。

根據(jù)本發(fā)明的另一個(gè)實(shí)施例，客戶端850可在SD期間將StopSubscribeEventGroup消息的L4-協(xié)議620字段值設(shè)置為L(zhǎng)2-SRP，并請(qǐng)求服務(wù)器810通過(guò)與AVB交互工作將流通過(guò)L2-幀傳輸。此后，服務(wù)器810可根據(jù)客戶端850的請(qǐng)求分配Qat流帶寬，生成其中L4-協(xié)議620的值被設(shè)置為L(zhǎng)2-SRP的InitialEvent消息，并且將所生成的InitialEvent消息傳輸?shù)娇蛻舳?50。因此，服務(wù)器810可通過(guò)可保證QoS的L2-幀來(lái)傳輸客戶端850請(qǐng)求訂閱的服務(wù)流。

根據(jù)本發(fā)明的一個(gè)實(shí)施例，服務(wù)器810可將OfferService消息傳輸?shù)娇蛻舳?50，以通知客戶端可用的服務(wù)，并且客戶端850可通過(guò) SubscribeEventgroup消息將相應(yīng)服務(wù)的訂閱請(qǐng)求發(fā)送到服務(wù)器810。這里，服務(wù)器810可通過(guò)OfferService消息中所包括的L4-協(xié)議620通知客戶端850何種傳輸方案用于傳輸該可用服務(wù)的流。

根據(jù)本發(fā)明的另一個(gè)實(shí)施例，客戶端850可判斷利用何種傳輸方案接收將請(qǐng)求訂閱的服務(wù)流，并且通過(guò)SubscribeEventgroup消息的L4-協(xié)議620將判斷結(jié)果傳輸?shù)椒?wù)器810。

根據(jù)本發(fā)明的另一個(gè)實(shí)施例，服務(wù)器810可保持指明隨所指定服務(wù)而變的傳輸方案的表格，其中提前定義隨所提供服務(wù)而變的傳輸方案，并且當(dāng)服務(wù)器810從客戶端850接收具體服務(wù)的訂閱請(qǐng)求時(shí)，參考表格確定對(duì)應(yīng)于所請(qǐng)求服務(wù)的L4-協(xié)議620的值。

圖9為示出根據(jù)本發(fā)明的一個(gè)實(shí)施例，通過(guò)與AVB功能交互工作供應(yīng)SOME/IP流的過(guò)程的流程圖。

當(dāng)服務(wù)器810從客戶端850接收具體服務(wù)的訂閱請(qǐng)求時(shí)，服務(wù)器810確認(rèn)對(duì)應(yīng)于所請(qǐng)求服務(wù)的L4-協(xié)議620的值是否為L(zhǎng)2-幀，即L2-SRP(操作S903)。

如果對(duì)應(yīng)于所請(qǐng)求服務(wù)的L4-協(xié)議620的值為L(zhǎng)2-幀，則服務(wù)器810生成InitialEvent消息，其中包括客戶端850的MAC地址且L4-協(xié)議620的值被設(shè)置為L(zhǎng)2-幀，并將所生成的InitialEvent消息傳輸?shù)娇蛻舳?50，以用于通過(guò)與AVB功能交互工作進(jìn)行流的預(yù)留傳輸(操作S905)。這里，服務(wù)器810可確定請(qǐng)求訂閱的服務(wù)的Tspec信息，并將InitialEvent消息(其包括所確定的Tspec信息或含有所確定的Tspec信息的AVB廣告消息)傳輸?shù)娇蛻舳?50。

客戶端850確認(rèn)是否實(shí)現(xiàn)了來(lái)自所接收的InitialEvent消息的Tspec信息的加載(操作S907)。作為確認(rèn)的結(jié)果，如果實(shí)現(xiàn)了Tspec信息的加載，則客戶端850可將包括所加載的Tspec信息的就緒消息傳輸?shù)椒?wù)器810(操作S909)。

當(dāng)服務(wù)器810接收到就緒消息時(shí)，服務(wù)器810判斷是否實(shí)現(xiàn)了對(duì)交換機(jī)的帶寬的預(yù)留和分配(操作S911)。作為判斷的結(jié)果，如果實(shí)現(xiàn)了對(duì)交換機(jī)的帶寬的預(yù)留和分配，則服務(wù)器810通過(guò)Qat中帶寬的預(yù)留和分配來(lái)執(zhí)行相應(yīng)服務(wù)流的預(yù)留傳輸(操作S913)。

如果在以上操作S903中L4-協(xié)議620的值不是L2-幀，則服務(wù)器 810通過(guò)TCP或UDP將相應(yīng)服務(wù)流傳輸?shù)娇蛻舳?50(操作S915)。

進(jìn)一步地，如果未實(shí)現(xiàn)來(lái)自所接收的InitialEvent消息的Tspec信息的加載且L4-協(xié)議620的值為L(zhǎng)2-幀，則作為以上操作S907中確認(rèn)的結(jié)果，客戶端850不執(zhí)行單獨(dú)的流預(yù)留程序，即，不將就緒消息傳輸?shù)椒?wù)器810，并且可從服務(wù)器810接收層2幀(L2-幀)。

如從以上描述顯而易見的，根據(jù)本發(fā)明的方法和裝置將具有如下效果。

第一，本發(fā)明提供用于通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置。

第二，本發(fā)明提供用于通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置，其中，在車載網(wǎng)絡(luò)中的SOME/IP服務(wù)處理過(guò)程期間將AVB功能應(yīng)用到層2流的傳輸，以使SOME/IP服務(wù)流的QoS可得到保證。

第三，本發(fā)明提供用于通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置，其中可防止通過(guò)傳統(tǒng)SOME/IP中的UDP傳輸而產(chǎn)生的音頻流和視頻流的丟失，并且可通過(guò)SOME/IP流之間的優(yōu)先級(jí)設(shè)置保證QoS。

第四，本發(fā)明提供用于通過(guò)與AVB技術(shù)交互工作來(lái)處理SOME/IP流的方法和裝置，其中可防止通過(guò)UDP傳輸而產(chǎn)生的音頻流和視頻流的丟失，并且可通過(guò)SOME/IP流之間的優(yōu)先級(jí)設(shè)置保證QoS。

對(duì)本領(lǐng)域技術(shù)人員顯而易見的是，可在不脫離本發(fā)明的精神和范圍的情況下，作出各種修改和變型。因此，本發(fā)明旨在覆蓋權(quán)利要求及其等同物范圍內(nèi)的本發(fā)明的修改和變型。