Apollo 開放車輛的接口標準主要涉及到兩大部分，即線控系統(tǒng)和車輛系統(tǒng)。Apollo 對這兩者的功能指標、性能指標、安全指標進行一系列的約定并提出了相關(guān)標準。以常見的剎車和油門為例， Apollo 對這兩者的控制精度、控制力度、系統(tǒng)的周期時間、響應(yīng)時間都有著嚴格的規(guī)定。

線控系統(tǒng)對指令越界保護和控制的處理等安全指標都有著明確約定以及標準化的要求。而車輛系統(tǒng)要求有相對穩(wěn)定的CAN信號通道，同時對于車輛電源，包括電壓、功率、最大波動、輸出誤差都有一系列的規(guī)定，以夠保證在整個自動駕駛過程中電源輸出穩(wěn)定。

本文由Apollo開發(fā)者社區(qū)認證布道師-阿淵撰寫，對Apollo 3.5 車輛配置方案進行了詳細講解，希望這篇文章給感興趣的同學(xué)帶來更多幫助。

以下，ENJOY

最近在研究百度無人車 Apollo 的工廠模式及車輛配置方式，有一些小心得希望和大家一起分享。

Apollo 無人駕駛平臺支持 Lincoln MKZ、WEY VV6 等來自多個 OEM 的不同車型。

Apollo 兼容的開放車型，來源： http://apollo.auto/vehicle/certificate_cn.html

眾所周知，各車廠車型的配置方式、接口、信號都各不相同。那么 Apollo 是如何兼容各個車型的呢？本文將從以下三個層次來回答這個問題。

從平臺構(gòu)架上看，Apollo 借助“開放車輛認證平臺 (Open Vehicle Certificate Platform)"完成與汽車的交互，其他上層平臺無需關(guān)注底層實現(xiàn)。

Apollo 3.5 架構(gòu)圖， 來源：https://github.com/ApolloAuto/apollo

Apollo 的平臺架構(gòu)如上圖所示，Apollo 開放平臺包括了以下幾個部分：

云端服務(wù)平臺

開源軟件平臺

硬件開發(fā)平臺

開放車輛認證平臺

這里我們著重了解一下“開放車輛認證平臺”。

來源：http://apollo.auto/developer_cn.html

目前各個 OEM 廠商的大多使用 CAN 總線協(xié)議來進行車輛內(nèi)部各個 ECU 節(jié)點之間的通訊。CAN 總線通訊協(xié)議中各節(jié)點的信息使用 DBC（Database Can）文件來進行來進行描述。

The DBC file describes the communication of a single CAN network. This information is sufficient to monitor and analyze the network and to simulate nodes not physically available.

DBC文件描述了單個CAN網(wǎng)絡(luò)的通信。 此信息足以監(jiān)視和分析網(wǎng)絡(luò)并模擬物理上不可用的節(jié)點。[1]

各車廠的 DBC 文件定義通常并不相同，并且是嚴格保密的。為了解決開發(fā)者在開發(fā)無人駕駛系統(tǒng)中與車輛交互的問題，Apollo 搭建了《開放汽車認證平臺》，并提出了開放車輛認證計劃。

開放車輛認證計劃第一次在業(yè)內(nèi)提出標準化的無人駕駛系統(tǒng)與車輛接口，透過這個計劃，車企/車輛提供商可以更方便的將車輛平臺接入到Apollo開放平臺，從而覆蓋更廣泛的無人駕駛開發(fā)者人群，加速無人駕駛能力的上車部署。[2]

該平臺作為軟硬件中間層，提出了開放車輛接口標準，定義了系統(tǒng)與汽車的線控接口，負責(zé)完成系統(tǒng)與汽車的具體交互。該平臺抽象出了與車型無關(guān)的信號作為上層算法模塊的輸入，使得上層平臺可以與底層車輛信號解耦。

Apollo 的開放車輛接口標準定義了 Apollo 需要的諸多用于控制車輛和接收反饋的信號。大體而言， Apollo 需要車企提供線控轉(zhuǎn)向、驅(qū)動、制動、檔位、駐車、燈光、雨刮控制、喇叭控制等控制及故障反饋等接口。Apollo 乘用車的線控需求具體的詳細信息可參見下列規(guī)范。

https://link.zhihu.com/?target=http%3A//apollo-homepage.bj.bcebos.com/Apollo_by_wire_requirement.xlsx

此外，根據(jù)《開放車輛認證車企認證流程》，想要接入到 Apollo 開放平臺，車企需要遵循 Apollo 的接口規(guī)范，向 Apollo 開放平臺提供對應(yīng)的 DBC 文件。

Apollo 在與開放車輛的信號交互上和開放車輛配置上均使用了Protobuf。

Protocol Buffers 是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，或者說序列化。它很適合做數(shù)據(jù)存儲或 RPC 數(shù)據(jù)交換格式?？捎糜谕ㄓ崊f(xié)議、數(shù)據(jù)存儲等領(lǐng)域的語言無關(guān)、平臺無關(guān)、可擴展的序列化結(jié)構(gòu)數(shù)據(jù)格式。目前提供了 C++、Java、Python 三種語言的 API。[3]

通常車企會使用 DBC 文件來完成 CAN 信號的定義和解析， Apollo 則大量使用了 Protobuf 來進行模塊間的通信和配置，因此車企需要使用 Apollo 提供的工具基于 DBC 來生成 Apollo 可用的 Proto 文件 (如下所示)。

1//modules/canbus/proto/wey.proto 2messageWey{ 3optionalAds_shifter_115ads_shifter_115=1;//controlmessage 4optionalAds_eps_113ads_eps_113=2;//controlmessage 5optionalStatus_310status_310=3;//reportmessage 6optionalVin_resp3_393vin_resp3_393=4;//reportmessage 7optionalVin_resp2_392vin_resp2_392=5;//reportmessage 8optionalVin_resp1_391vin_resp1_391=6;//reportmessage 9optionalAds_req_vin_390ads_req_vin_390=7;//controlmessage10optionalAds1_111ads1_111=8;//controlmessage11optionalFbs2_240fbs2_240=9;//reportmessage12optionalFbs1_243fbs1_243=10;//reportmessage13optionalFbs4_235fbs4_235=11;//reportmessage14optionalFail_241fail_241=12;//reportmessage15optionalFbs3_237fbs3_237=13;//reportmessage16optionalAds3_38eads3_38e=14;//controlmessage17}

Protobuf 提供的 Codegen 工具會根據(jù) Proto 文件中定義的變量生成可直接使用的 C++ 代碼，十分便捷。

Protobuf 提供了一種名為TextFormat的序列化格式，該格式類似于Json，清晰易懂。配合事先定義的 Proto 文件， 開發(fā)者可以輕易實現(xiàn)從可讀的配置文件到具體對象的實例的反射，配置文件經(jīng)過反序列化后可以作為業(yè)務(wù)代碼類的輸入。這種方式使得配置變得便捷，不易出錯，且具有很好的向后兼容性。

Apollo 的代碼中大量使用了這種方式來管理配置。Apollo 激活車輛的配置文件為 modules/canbus/conf/canbusconf.pb.txt，開發(fā)者可以在這里定義車型及對應(yīng)的 CAN card 的參數(shù)，開發(fā)者只需修改 "vehicle_parameter" 相應(yīng)的字段，即可使 Apollo 支持對應(yīng)的車型。

1#modules/canbus/conf/canbus_conf.pb.txt 2vehicle_parameter{ 3brand:LINCOLN_MKZ 4max_enable_fail_attempt:5 5driving_mode:COMPLETE_AUTO_DRIVE 6} 7 8can_card_parameter{ 9brand:ESD_CAN10type:PCI_CARD11channel_id:CHANNEL_ID_ZERO12}1314enable_debug_mode:false15enable_receiver_log:false16enable_sender_log:false

上述配置文件的參數(shù)的含義是由下面的 Proto 文件決定的。

1//modules/canbus/proto/canbus_conf.proto 2messageCanbusConf{ 3optionalapollo.canbus.VehicleParametervehicle_parameter=1; 4optionalapollo.drivers.canbus.CANCardParametercan_card_parameter=2; 5optionalboolenable_debug_mode=3[default=false]; 6optionalboolenable_receiver_log=4[default=false]; 7optionalboolenable_sender_log=5[default=false]; 8} 910//modules/canbus/proto/vehicle_parameter.proto11//Apollo支持了LINCON_MKZ,GEM,LEXUS等多種車型12messageVehicleParameter{13enumVehicleBrand{14LINCOLN_MKZ=0;15GEM=1;16LEXUS=2;17TRANSIT=3;18GE3=4;19WEY=5;20}21optionalVehicleBrandbrand=1;22optionaldoublemax_engine_pedal=2;23optionalint32max_enable_fail_attempt=3;24optionalChassis.DrivingModedriving_mode=4;25}2627//modules/drivers/canbus/proto/can_card_parameter.proto28messageCANCardParameter{29enumCANCardBrand{30FAKE_CAN=0;31ESD_CAN=1;32SOCKET_CAN_RAW=2;33HERMES_CAN=3;34}35...36}

另外要提到一點的是，Protobuf 提供了兩個版本的庫，即精簡版 ("libprotobuf-lite.so") 和 完整版 ("libprotobuf.so" )。

The "lite" library is much smaller than the full library, and is more appropriate for resource-constrained systems such as mobile phones.

精簡版體積遠小于完整版，因此更適合使用在諸如移動電話等資源受限的系統(tǒng)上。[4]

精簡版的 Protobuf 常用于嵌入式設(shè)備，但精簡版的庫并不支持 TextFormat 的反射功能。開發(fā)者如果想兼具代碼體積和功能的話，可以考慮自己寫一套格式化語言的反射機制，有興趣的同學(xué)可以參考《簡單的 C++ 結(jié)構(gòu)體字段反射》。

Apollo Software Overview, 來源：https://github.com/ApolloAuto/apollo

從軟件實現(xiàn)上看，Apollo 通過CANBus模塊來實現(xiàn)對車輛的管理和通訊 。

CANBus 模塊接收并執(zhí)行來自 Control 模塊的指令，同時收集汽車底盤的狀態(tài)，這些狀態(tài)是Apollo 抽象出的一組與車型無關(guān)的信號。Canbus 模塊處理這些狀態(tài)與各個汽車底盤信號的映射關(guān)系，隨后將這些狀態(tài)反饋回 Control 模塊。基于這樣的設(shè)計，Apollo 得以兼容多個不同的車型。

chassis.proto文件對 Apollo 抽象出的信號進行了定義，大體包括下列信息：

Chassis 信號

CANBus 模塊主要由以下兩個部件組成

Vehicle:the vehicle itself, including itscontrollerandmessage manager

CAN Client- CAN client has been moved to/modules/drivers/canbussince it is shared by different sensors utilizing the canbus protocol[5]

在這里著重介紹一下Vehicle部分。

Vehicle的Controller(modules/canbus/vehicle/vehicle_controller.h)的類圖如下(有簡化)：

Vehicle Controller 類負責(zé)完成與汽車底盤的具體交互，下面對部分公有接口做一些解釋。

1/***@briefstartthevehiclecontroller.*注：該函數(shù)會在內(nèi)部起一個名為"SecurityDogThreadFunc"的線程，該線程會周期性的檢*查與底盤的通訊狀況，關(guān)鍵信號是否有響應(yīng)，是否有錯誤等等。*@returntrueifsuccessfullystarted.*/ 2virtualboolStart()=0; 3 4/***@briefstopthevehiclecontroller.*/ 5virtualvoidStop()=0; 6 7/***@briefcalculateandreturnthechassis.*注：該函數(shù)完成了汽車底盤信號和Apollo內(nèi)部定義的底盤狀態(tài)信號的映射。*@returnsacopyofchassis.Usecopyheretoavoidmulti-threadissues.*/ 8virtualChassischassis()=0; 910/***@briefupdatethevehiclecontroller.*注：該函數(shù)負責(zé)執(zhí)行來自Control模塊的具體的指令。根據(jù)指令的要求和汽車目前所處*的模式(完全自動、完全手動、自動轉(zhuǎn)向等)來為執(zhí)行器的信號(檔位、油門、轉(zhuǎn)向等)進行*賦值。*@paramcommandthecontrolcommand*@returnerror_code*/11virtualcommon::ErrorCodeUpdate(constcontrol::ControlCommand&command);

Vehicle 的 MessageManager 類負責(zé)完成對具體信號的接收、發(fā)送、解析等，其類圖如下：

1//modules/drivers/canbus/can_comm/message_manager.h 2//用于指定系統(tǒng)向汽車底盤發(fā)送的控制型號 3template 4template 5voidMessageManager::AddSendProtocolData(); 6 7//用于指定系統(tǒng)接收的信號 8template 9template10voidMessageManager::AddRecvProtocolData();

接下來我們以 Wey VV6 車型為例，來分析 Apollo 是如何在代碼層面上完成配置任務(wù)的。

Wey 文件夾包含有如下文件：

根據(jù) Apollo 的官方文件how_to_add_a_new_vehicle， 想要為 Apollo 添加 Wey 車型需要完成以下內(nèi)容：

實現(xiàn)新的車輛控制器--wey_controller.cc，繼承VehicleController類

實現(xiàn)新的消息管理器--wey_message_manager.cc繼承MessageManager類

實現(xiàn)新的車輛工廠類--wey_vehicle_factory.cc, 繼承AbstractVehicleFactory類

更新配置文件

在modules/canbus/vehicle/vehicle_factory.cc中進行注冊

更新配置文件modules/canbus/conf/canbus_conf.pb.txt

通過上述方式可以增加新車型的原因在于 Apollo 的配置是基于工廠模式實現(xiàn)的。

工廠方法模式（Factory method pattern）是一種實現(xiàn)了“工廠”概念的面向?qū)ο笤O(shè)計模式。就像其他創(chuàng)建型模式一樣，它也是處理在不指定對象具體類型的情況下創(chuàng)建對象的問題。工廠方法模式的實質(zhì)是“定義一個創(chuàng)建對象的接口，但讓實現(xiàn)這個接口的類來決定實例化哪個類。工廠方法讓類的實例化推遲到子類中進行?！盵6]

Canbus 模塊中 Vehicle 相關(guān)的內(nèi)容使用工廠模式抽象出了 VehicleController，MessageManager，AbstractVehicleFactory 三個接口。 Canbus 的業(yè)務(wù)代碼（canbus_component.cc）通過以上接口來操縱具體的對象，用戶無需關(guān)心具體的對象是什么，從而實現(xiàn)了業(yè)務(wù)邏輯和目標對象的解耦。

工廠方法模式的定義和實現(xiàn)的相關(guān)講解有很多，本文就不再贅述，可參考下列鏈接和書籍:

https://en.wikipedia.org/wiki/Factory_method_pattern

《設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》

《Head First 設(shè)計模式》

Apollo 社區(qū)布道師賀志國老師曾對 Apollo 的工廠模式進行過介紹， 接下來本文會在此基礎(chǔ)上繼續(xù)延伸。

https://blog.csdn.net/davidhopper/article/details/79197075

Apollo 提供了一個工廠模版(modules/common/util/factory.h)，該模版可支持任何類型的輸入，類圖如下：

工廠模版

Factory類包含了Register()、Unregister()、Empty()、CreateObjectOrNull()、CreateObject()等公有函數(shù)，其中Register()、Unregister()函數(shù)用于注冊和反注冊產(chǎn)品類，其作用與經(jīng)典模式中抽象工廠接口類的功能類似，Empty()函數(shù)用于判斷當(dāng)前工廠類中是否包含產(chǎn)品創(chuàng)建函數(shù)，CreateObjectOrNull()、CreateObject()函數(shù)用于創(chuàng)建可能包含空指針和不包含空指針的產(chǎn)品類對象。[7]

Factory 工廠模版維護了一個 Map 用來管理 IdentifierType 和 ProductCreator 的鍵值對，根據(jù)輸入的 IdentifierType， 模版可返回 ProductCreator 生產(chǎn)的產(chǎn)品，從而實現(xiàn)了從 IdentifierType 到 Product 的“映射“。

在Canbus 模塊中，工廠類為 "VehicleFactory"， 該類繼承于工廠模版 "Factory" 。VehicleFactory 工廠維護了鍵值對為 VehicleParameter::VehicleBrand和AbstractVehicleFactory 的 Map。

如下所示，每新注冊一種車型，該 Map 中就會插入一條汽車品牌(VehicleBrand)和該品牌汽車生產(chǎn)工廠(AbstractVehicleFactory )的鍵值對。

1voidVehicleFactory::RegisterVehicleFactory(){ 2Register(apollo::common::LINCOLN_MKZ,[]()->AbstractVehicleFactory*{ 3returnnewLincolnVehicleFactory(); 4}); 5Register(apollo::common::GEM,[]()->AbstractVehicleFactory*{ 6returnnewGemVehicleFactory(); 7}); 8Register(apollo::common::LEXUS,[]()->AbstractVehicleFactory*{ 9returnnewLexusVehicleFactory();10});11Register(apollo::common::TRANSIT,[]()->AbstractVehicleFactory*{12returnnewTransitVehicleFactory();13});14Register(apollo::common::GE3,[]()->AbstractVehicleFactory*{15returnnewGe3VehicleFactory();16});17Register(apollo::common::WEY,[]()->AbstractVehicleFactory*{18returnnewWeyVehicleFactory();19});20}

當(dāng)VehicleFactory類的"CreateVehicle" 方法被調(diào)用時， VehicleFactory會根據(jù)輸入的汽車品牌，在 Map 中查找并返回可以生產(chǎn)這種汽車的工廠 。

例如輸入汽車品牌"WEY" ， VehicleFactory 會返回 WeyVehicleFactory ，WeyVehicleFactory 繼承于 AbstractVehicleFactory 。

1/**2*@briefCreatesanAbstractVehicleFactoryobjectbasedonvehicle_parameter3*@paramvehicle_parameterisdefinedinvehicle_parameter.proto4*/5std::unique_ptrCreateVehicle(6constVehicleParameter&vehicle_parameter);

AbstracVehicleFactory 工廠會產(chǎn)出一組適用于該品牌車型的產(chǎn)品即 MessageManager 和 Vehicle controller。

以 “Wey” 為例， WeyVehicleFactory 會產(chǎn)出 WeyMessageManager 和 WeyController 用于實現(xiàn) “Wey”車型的通訊和控制。

完整的類圖如下所示：

最后對 CANBus 模塊的CanbusComponent進行介紹 。該類繼承于 " TimerComponent"， 主要作用為處理來自控制模塊的控制指令，并將信號消息發(fā)送至 Can card。

CanbusComponent 的初始化函數(shù) (init )主要完成了以下工作：

1. 讀取 CANBus 配置文件

1if(!GetProtoConfig(&canbus_conf_)){2AERROR<

2. 根據(jù)配置文件初始化 Can—client.

1can_client_=can_factory->CreateCANClient(canbus_conf_.can_card_parameter());

3. 根據(jù)配置文件獲取汽車工廠

1VehicleFactoryvehicle_factory;2vehicle_factory.RegisterVehicleFactory();3autovehicle_object=4vehicle_factory.CreateVehicle(canbus_conf_.vehicle_parameter());

4. 獲取該汽車工廠生產(chǎn)的 message_manager 和 Vehicle_contorller

1message_manager_=vehicle_object->CreateMessageManager();2...3//初始化can_receiver_和can_sender_4if(can_receiver_.Init(can_client_.get(),message_manager_.get(),5canbus_conf_.enable_receiver_log())!=ErrorCode::OK){...}6if(can_sender_.Init(can_client_.get(),canbus_conf_.enable_sender_log())!=7ErrorCode::OK){...}89vehicle_controller_=vehicle_object->CreateVehicleController();

5. 使能 Can 收發(fā)和 Vehicle_contorller

初始化完成之后，CanbusComponent 會周期性的報告車身狀態(tài)，并執(zhí)行來自 Control 模塊和 Guardian 模塊的命令。

1boolCanbusComponent::Proc(){ 2//publish底盤信息 3PublishChassis(); 4if(FLAGS_enable_chassis_detail_pub){ 5//Publish底盤的細節(jié)信息 6PublishChassisDetail(); 7} 8returntrue; 9}1011//事件觸發(fā)，執(zhí)行來自Control模塊的指令12voidCanbusComponent::OnControlCommand(constControlCommand&control_command){...}1314//事件觸發(fā)，執(zhí)行來自Gurdian模塊的指令15voidCanbusComponent::OnGuardianCommand(16constGuardianCommand&guardian_command){17apollo::control::ControlCommandcontrol_command;18control_command.CopyFrom(guardian_command.control_command());19OnControlCommand(control_command);20}

Apollo 開放車輛認證平臺定義了系統(tǒng)與線控車輛的接口標準，并且從各個車型中抽象出了用于算法的與具體車型無關(guān)的信號。

在軟件模塊中， Canbus 模塊負責(zé)處理這些信號與車輛底盤信號的映射。

Apollo 以 Protobuf 為基礎(chǔ)使得車輛配置管理變得十分簡潔易用。

Apollo 使用抽象工廠模式，使業(yè)務(wù)邏輯得以與具體的車輛解耦。

上述方式的綜合應(yīng)用，使得 Apollo 得以支持多種不同的車輛。