面向SOA的E/E架構設計數智化轉型實踐

金劭南 高仕寧 李超 吳振舉 陳泓宇 柳菁

【歡迎引用】 金劭南，高仕寧，李超，等. 面向SOA的E/E架構設計數智化轉型實踐[J].汽車文摘， 2024（3）： 31-38.

【Cite this paper】 JIN S N， GAO S N， LI C， et al. Digitalization & Intelligence Transformation Practice of SOA E/E Architecture Design [J]. Automotive Digest （Chinese）， 2024（3）： 31-38.

【摘要】隨著數智化潮流的推進，使用工具鏈進行整車架構開發已成為傳統車企數智化轉型的關鍵。通過文獻研究、實操探索等方式，結合集中式面向服務的架構（SOA）項目開發實例，研究使用EA、PREEvision工具鏈進行架構設計數智化轉型實踐，闡述相關工具在整車功能架構、軟件架構設計中的應用。同時根據工具在應用過程中存在的問題，進行二次插件開發，解決架構設計過程中存在的瓶頸。通過案例實踐表明，使用上述兩款工具可有效應對整車E/E架構設計數智化轉型，提高研發效率。

主題詞：整車架構 數智化轉型 工具鏈 架構設計 功能設計

中圖分類號：U463.61? ?文獻標志碼：A? ?DOI： 10.19822/j.cnki.1671-6329.20220288

Digitalization & Intelligence Transformation Practice of SOA E/E Architecture Design

Jin Shaonan， Gao Shining， Li Chao， Wu Zhenju， Chen Hongyu， Liu Jing

（Global R&D Center， China FAW CorporationLimited， Changchun 130013）

【Abstract】 As the trend of digital intelligence advances， using tool chain to develop vehicle architecture has become the key to the intelligent transformation of traditional automobile enterprises，through literature research， practical exploration and other ways，develop examples in conjunction with centralized SOA architecture projects，This paper studies the use of EA and PREEvision tool chain to carry out intelligent transformation practice of architecture design， describes the application of relevant tools in the design of vehicle functional architecture and software architecture. At the same time， according to the problems existing in the application process of the tool， the secondary plug-in development is carried out to solve the bottleneck in the architecture design process. The case practice shows that the above two tools can effectively cope with the intelligent transformation of vehicle E/E architecture design and improve the research and development efficiency.

Key words： Complete Vehicles Architecture， Digitalization & Intelligence Transformation， Tool Chain， Architecture Design，Function Design

0 引言

隨著汽車“新四化”（智能化、網聯化、電動化和共享化）的快速發展，汽車上的功能需求越來越豐富，車輛ECU控制器數量大幅度增長，汽車電子通信網絡越來越復雜，對整車E/E架構的要求也越來越高[1]。傳統分布式汽車電子電氣架構存在算力不足、布線復雜和高耦合性的缺陷，已然不能夠支撐當前的技術挑戰及市場需求。因此在軟件定義汽車的背景下，各大主機廠紛紛提出了面向服務的架構（Service-Oriented Architecture，SOA）。如Volvo-SPA2.0架構，其設計主要原則為標準化服務，服務松耦合，構建可重復利用的服務來實現粗粒度、松耦合、靈活性強的集中式汽車E/E架構[2]。

數字化時代，傳統企業“數智化轉型”已成為提升效率的必由之路[3]。企業數智化轉型是利用現代信息技術對企業業務進行重塑，運用主流、前沿的智能化技術對業務流程及機制進行優化和管理，實現業務效率的提升和創新，保持企業的競爭力。在軟件定義汽車的時代背景下，數智化轉型已在汽車行業內逐步應用，成為重塑產業結構的重要動力。很多主機廠都提出了數智化轉型之道。豐田作為數智化轉型的標桿，獨創“一頁紙極簡思考法” [4]；大眾也提出了相應的數智化轉型計劃，成立汽車軟件組織Car.Software，力爭2030年成為軟件驅動型的移動出行服務提供商。

智能網聯汽車數智化，學習互聯網思維，實現產品敏捷開發，即數字汽車開發[5]。針對面向SOA的電子電氣（Electrical&Electronic，E/E）架構設計數智化轉型，各傳統車企均處于探索實踐的階段，在這其中使用合適有效的工具鏈可以有效提升研發效率[6]。本文在SOA架構思維下，探究整車E/E架構設計中功能架構設計和軟件架構設計數智化轉型的解決方案并實踐，同時根據工具鏈間存在的痛點問題，對工具鏈進行二次開發，滿足業務靈活度及契合度。

1 面向SOA的E/E架構設計

1.1 傳統E/E架構設計

以傳統基于域控制架構開發的實際流程為例，基于域控制器的傳統分布式架構開發是以車型裝備定義作為輸入，在各階段輸出相應的功能設計規范傳遞給下游，指導其系統開發，傳統E/E架構設計如圖1所示。

基于域控制架構開發的核心是以控制器為主線進行的架構設計。首先通過裝備定義明確車型定位，在架構設計階段，依據裝備定義明確車型需要的所有功能，輸出功能特性列表。再對功能進行功能域劃分，結合ECU控制器按照功能域輸出架構設計方案。在此基礎上輸出每個功能的詳細功能描述方案。然而在“軟件定義汽車”的時代下，功能需求呈爆發式增長，該設計模式不能夠完美適應新架構思想下的開發設計，且傳統開發流程中各環節的輸出物為文檔，并未合理使用相關工具鏈，難以順應當前傳統車企數智化發展趨勢[7]。

1.2 面向SOA的E/E功能架構設計

相較于傳統的E/E架構開發，面向SOA的架構開發更側重于降低軟件的耦合度，抽象并暴露出更多的服務。本文參考AUTOSAR[8]標準中關于方法論的描述，以集中式SOA架構項目為例，提出一種基于集中式SOA架構的功能開發方案，如圖2所示。

基于圖2的功能架構設計，SOA的功能架構開發過程中，同樣以裝備定義作為輸入，用于描述整車產品的定位。不同于傳統架構開發以電子控制單元（Electronic Control Unit，ECU）控制器作為主線，SOA的功能架構開發過程中更側重于功能和服務[9]。輸出功能特性列表后進行功能定義、功能設計和服務抽象。借鑒互聯網開發的思維，在此過程中輸出用例圖和時序圖給下游專業。其中用例圖用來描述功能的定義內容，功能設計則是對車輛平臺軟件和硬件的能力分析，提取出產品能力（Product Capability， PC），并描述各能力之間的交互，最終形成時序圖。

1.3 面向SOA的E/E軟件架構設計

集中式SOA架構定義了整車級SOA軟件架構，通過分層部署，提取出全局變量的服務（如車速、時間、車輛狀態等），并將其作為通用的軟件模塊服務，以實現基礎功能軟件接口統一，并可靈活部署（圖3）。

上述工作需要在項目開發一開始便設計好，之后的軟件架構工作均需圍繞其開展。結合集中式SOA架構項目下整車E/E架構開發流程，其軟件架構設計方案如圖4所示。

在軟件架構設計之初，便需要對整車SOA架構進行合理分層以及模塊劃分，搭建整個軟件架構的框架，用于承接功能架構所輸出的平臺能力（PC）。

當接收到功能架構設計所輸出的平臺能力（PC）后，由軟件架構進行承接，對PC進行模塊部署，落到對應的模塊中，之后需要對模塊進行設計（Module Design）。軟件架構設計即根據平臺能力PC在Module上進行軟件組件（Software Component，SWC）劃分，并以輸入的平臺能力（PC）為參考，對SWC進行接口設計。將上一節內容產出的PC對功能的描述轉化為軟件描述。

2 面向SOA的E/E架構數智化轉型工具鏈

在數智化大背景下，使用合理的工具鏈進行開發設計可有效地提升研發效率[10-11]，高效對產出物進行管理，實現多人協同辦公。結合集中式SOA架構項目實際開發過程，闡述相應工具鏈的使用情況。

2.1 軟件生命周期設計工具——Enterprise Architect

Enterprise Architect（EA）是SparxSystems公司開發的旗艦產品，是一款基于統一建模語言（UnifiedModelingLanguage，UML）的可視化建模與設計工具[12-13]。Enterprise Architect是一個對于軟件系統開發有著極好支持的計算機輔助工程軟件（Computer Aided Software Engineering，CASE）。不同于VISIO等其他UML建模工具，CASE能夠支撐系統開發全過程，且支持多人協同操作，滿足團隊開發設計，同時能根據項目實際需求進行二次開發，有效提高建模設計效率及管理能力（圖5）。

結合面向SOA架構開發過程中功能架構開發流程的相關活動，EA主要用于功能定義設計及模塊、SWC定義等相關環節。主要建模內容如下：

（1）用例（Use Case，UC）：系統功能基本描述，結合項目實際情況。

（2）用例圖：描述參與者與系統功能間的交互形式。

（3）狀態機圖：描述了一個對象在其生命周期內所經歷的各種狀態，以及狀態之間的轉移、發生轉移的原因、條件和轉移中所執行的活動。

（4）產品能力PC：描述整車產品所需提供的車輛能力。

（5）時序圖：描述平臺能力PC之間發送消息的時間順序顯示多個對象之間的動態協作。

（6）SWC：AUTOSAR標準制定目標之一，將PC的功能描述轉化為軟件描述。

2.2 軟件架構設計工具——PREEvision

PREEvision提供給開發人員完整的協同開發平臺，可用于基于AUTOSAR的軟件架構設計，支持SWC的創建劃分以及接口的定義設計，為軟件架構的定義和端口連接提供圖形支持，同時PREEvision還支持不同版本AUTOSAR軟件技術規范的導入和導出[14-15]。

使用PREEvision進行軟件建模的優勢主要有2點：

（1）PREEvision支持AUTOSAR標準，滿足集中式SOA架構項目的建設需求。

（2）PREEvision能夠很好的進行全鏈條的追溯，當其中某一環節發生改動時，PREEvision能夠展示出所有與之關聯的變動，供開發人員進行參考。

3 面向SOA的E/E架構數智化轉型實踐

在集中式SOA架構項目開發過程中嘗試使用EA、PREEvision相關工具鏈進行架構模型的構建。其中，使用EA實現功能架構設計相關內容，包括上述多種UML繪制、SWC和接口定義；使用PREEvision實現軟件架構設計內容，包括服務定義、SWC、接口的定義和設計，以及自適應應用（Adaptive Application）設計。本章以信息娛樂域中“車外模擬人工聲音”功能為例，闡述當前面向SOA的E/E架構開發數智化轉型實踐情況。

3.1 基于EA的電子電氣功能架構設計

在功能架構開發階段，主要使用EA進行UML模型的繪制。完成功能定義、功能設計及平臺能力PC部署建模。

3.1.1 功能定義

功能定義階段主要是將用戶需求轉化為工程需求，并運用行業標準UML語言進行建模規范。在功能定義階段主要工作是使用EA來定義功能用例（UC），并繪制UC圖。在設計每個功能的用例時，要明確以下屬性：

（1）描述：包括UC名稱及UC的詳細描述，對本UC進行簡單描述。

（2）前置條件/后置條件：描述該UC生效的前提條件和觸發UC后的狀態。

（3）場景：描述UC在觸發期間整個事件流，包括基本事件、異常事件和備選事件。

（4）非功能需求：為滿足功能而必須具有的功能需求以外的特性，包括安全性、可靠性、法規要求和時效性。

本文以“車外模擬人工聲音”為例將整個大功能的使用場景通過需求分析拆分成多個UC。

當定義好UC后，還需定義“參與者”，即描述觸發用例的角色，如駕駛員和乘客。還需要繪制時序圖，建立“參與者”、“用例”和非功能需求之間的聯系，如圖6所示。

在功能設計階段使用EA工具可以很好地使用工程描述語言表示出用戶與功能之間地交互關系，供相關專業開發人員進行開發。

3.1.2 功能設計

完成用例設計后，需要對每個用例進行功能設計，即為實現功能所需要的時序設計。該階段同樣在EA工具上使用UML建模語言進行動態交互圖設計。將UC涉及到的信息，功能實現過程和場景進行細化，參考功能定義中的前置條件、后置條件、功能場景進行設計，在設計過程中可以不斷發現功能設計階段所存在的遺漏點和不合理之處，不斷優化迭代。

功能設計首先根據功能定義中的信息提出平臺能力（PC），明確為實現全部功能整車需要提供什么樣的能力，以“車外模擬人工聲音”為例，為實現這個功能需要車輛具備模擬發動機聲音的能力，同時根據不同車速發出不同音效，還需要車輛具備獲取車速的能力。在設計PC時，需要考慮如下因素：

（1）PC名稱及描述：描述PC所提供的能力

（2）PC相關操作：描述PC之間交互的操作，如獲取車速信息，獲取車輛狀態；

（3）PC相關操作返回數據類型：PC間交互后返回數據的類型，為基本數據類型或結構體。

本文以“車外模擬人工聲音”功能為例，給出EA工具鏈PC設計過程。PC設計過程見表1及圖7所示。

在初步提出PC后，需要使用這些提出的PC進行功能時序設計，其目的是通過同臺交互設計使用這些PC，共同協同工作實現整個用例UC。該過程使用UML時序圖進行工程描述。在繪制時序圖時，主要有考慮到如下因素。

（1）對象：實現功能的主要對象，即消息實體。在此主要包括參與者與上一步驟中所提到的PC。

（2）生命線：即功能實現的參與生命線。

（3）消息：各對象間交互的內容，實現功能事件的動態交互，主要用到了同步消息與異步消息，依據實現的內容不同來進行選擇。

（4）組合片段：包括一些條件判斷框，如選項片段（Opt）、備選條件進入框（Alt）、并行執行框（Par）等。用于處理用例（UC）中場景信息涉及到的不同情況。

本文以“車外模擬人工聲音”功能中的功能設計為例，給出功能設計示例，如圖8所示。

在繪制時序圖過程中可以檢驗上一步設計PC的合理性，保證每個PC的顆粒度是合理的，能夠覆蓋整個功能的完整生命周期，因此在功能設計階段PC的設計以及時序圖設計是一個相互迭代的過程，保證最終功能設計結果是合理的。

3.1.3 SWC及其接口定義

為了能夠建立PC上下游間的追溯關系，功能架構設計階段還需要在EA中完成PC的部署錄入工作，建立SWC及其接口，需要說明的是在EA中并不進行Module及SWC的設計工作，僅完成定義工作。其目的有2點：（1）方便對PC進行管理，后續PC可以對其他功能進行復用，方便PC的快速查找、迭代更新及管理。（2）在EA進行建模后可以提供良好的全鏈條關系追溯能力，后續可對每個功能的UC—PC—Module—SWC—接口進行全鏈條追溯，提升開發效率（圖9）。

3.2 基于PREEvision的電子電氣軟件架構設計

3.2.1 基于PREEvision的分層與模塊設計

在進行軟件架構開發之初便需制定好整個E/E架構分層設計與模塊設計，通常情況下該結構后期不會更改，用于支撐整個功能架構及軟件架構的開發，依據1.3節中圖3的劃分思想，本文按照功能域給出服務接口層級設計，如圖10所示。

本項目依照圖10的服務層級設計對整車進行接口層級劃分，保證后期的維護和管理，并在PREEvision里進行結構創建，如圖11所示。

在PREEvision中創建好結構后，后續的服務及SWC建模均在此結構上進行，因此在架構設計之初分層與模塊設計非常重要，決定后續軟件架構開發的合理性。

3.2.2 基于PREEvision的服務設計

在接收到功能架構的PC輸入后，在軟件架構開發階段需要先進行服務抽象，將PC轉化為服務。在AUTOSAR標準的指導下[8]，PREEvision支持開發二次插件腳本實現自動建模，導入標準格式的Excel并自動完成服務功能的搭建。為了保證準確導入，在服務設計階段，需要按照規范格式編寫軟件服務Excel表格，二次開發腳本對輸入表格進行解析，執行插件腳本即可導入服務模型到PREEvision，以車外模擬人工聲音功能為例，設計車速相關的功能服務，其解析前的Excel如表2所示。

PREEvision導入上述excel表并進行解析，在工具中自動創建相關服務接口，創建結果如圖12所示。

3.2.3 基于PREEvision的SWC設計

在AUTOSAR中，軟件架構由SWC組成，通過服務接口的軟件實現。軟件架構開發過程中依據傳遞過來的PC進行SWC設計，并在PREEvision中進行實現。本文以AP建模規范為例，依據所實現的服務來創建SWC，在Root Composition中新建用于AP的組成（Composition），并在該Composition中新建對應的自適應應用軟件組件（Adaptive Application SW Component），如圖13所示。

3.2.4 基于PREEvision的SWC接口設計

定義好SWC后，還需添加對應的 Adaptive Required/Provided Port，建立服務于SWC之間的關系，在此步驟中需要重新命名并將Required Port和Provided Port建立連接。將需要進行AP設計的Service Interface直接拖拽至AP Required/Provided接口。以獲取車速信息的SWC為例，在PREEvision中SWC接口設計如圖14所示。

3.2.5 基于PREEvision的Adaptive Application設計

在AUTOSAR方法論中，AP是可執行文件（Executables）的集合，一個Executable源于一個AP SWC，在PREEvision中設計方法如下。

（1）在System Software Architecture下新建 SW Package， 在此Package下新建兩個名稱為 Application和Executable的SW Package，在兩個SW Package下分別創建Adaptive Application以及Executable。

（2）在Adaptive Application的General屬性窗口，選擇Adaptive Application Kind為Application Level或者Platform Level。

（3）在Adaptive Application 欄 Adaptive Application Editor中將APP與Executable關聯，并填寫Adaptive Application Version信息，Executable Build Type及Version信息，將AP SWC與對應Adaptive Application建立關聯。

Adaptive Application設計完成后，最終以Application為單位，導出ARXML供下游專業進行軟件開發。

3.3 關鍵工具鏈二次開發設計

使用工具鏈進行面向SOA的E/E架構開發可以提升研發效率，提升了模型管理及維護能力，減少容錯率，一定程度上保證了模型的嚴謹性。但工具并非萬能，一方面開發過程中使用工具可有效提升工作效率，實現一定程度上的數智化轉型，另一方面工具的局限性可能會帶來一些重復冗余的工作，給開發設計增添了工作量。無論是EA還是PREEvision，都并非能按照實際開發需求進行完美適配，在開發過程中難免會存在一定的局限。本文結合項目實踐過程中發現的問題進行總結并給出解決方案：

（1）對建模內容管理困難

在開發過程中，EA上維護了超過300個功能、3 000個UC、6 000個平臺能力PC。EA工具缺乏對這些功能的導出，只能在工具上進行查看，對于不使用EA的開發人員來說，不方便查看建模內容。

（2）無法高效產出功能需求文檔

在面向SOA架構開發需要產出功能需求文檔（Product Requirement Document，PRD）傳遞給下游專業進行實現，目前在EA上實現的建模內容只能通過手動粘貼的方式來編寫PRD，在此過程中產生了一些不必要的工作，且容易出現人為失誤。

（3）EA工具缺乏對全鏈條追溯的能力

UC、PC等模型元素雖然可通過建模的方式進行關聯追溯，但EA工具鏈中缺少相關功能能夠直觀展現這些關系，且不支持全鏈條關系導出供開發人員參考，在實際工作中會產生一定的麻煩。

（4）EA工具與PREEvision工具間未實現打通

從前兩節的實踐操作中可以看出，在架構開發中主要使用的工具鏈為EA和PREEvision，2個工具相互獨立，且在各自的工作范圍內有重復的工作，增添了冗余的操作，一定程度上降低了工作效率，且不能實現聯動更新，為后期維護增添了困難。

針對上述存在的問題，考慮到EA以及PREEvision均可支持二次插件開發來提高生產效率，如圖15所示。

本文結合工作實際情況中存在的問題瓶頸，在插件開發過程中給出解決問題的思路及辦法。

（1）針對EA上模型管理困難的問題，可以考慮通過EA二次開發插件程序，抓取UC、PC元素并獲取到模型元素中的信息，通過Excel表的形式導出，供架構開發人員進行管理?？紤]到功能數量繁多、模型信息需要人為錄入缺乏規范性管理，可以制定相應的規范標準，制定屬性信息描述范式與命名規則。同時可以按功能域進行劃分，對用例進行管理。

（2）針對EA模型無法導出功能需求文檔PRD的問題，同樣可以使用二次插件開發的方法進行解決。首先需要規定好PRD文檔的模板，通過抓取EA中用例圖、時序圖及相關模型元素的信息，導出PRD初版文檔，該文檔中包含在EA中建模所有內容，PRD中其它與模型無關的（如用戶故事、法規項等）內容在導出后的文檔中補充即可，避免重復操作，減少開發人員的工作量（圖16）。

（3）針對功能全鏈條難以追溯的問題，主要原因是EA工具的局限性，不能完美適配面向SOA的整車E/E架構開發，同樣可以通過開發插件的方式進行彌補，將EA上的模型元素建立關聯關系后，選擇相應的功能或某個特定的UC，實現從Function -UC-PC-Module-SWC的全鏈條導出，如圖17所示。

（4）由于在開發過程中使用到了EA以及PREEvision兩套工具，其相互獨立，未形成聯動，導致創建SWC和SWC的接口等工作在兩套工具上都進行了一遍，重復工作在開發過程中費時費力，且容易出現差錯，一旦其中一種工具上進行了修改，很難同步到另一種工具上，導致后期圍護工作量加大。為解決此問題，可以對EA上的SWC模型進行導出標準格式的Excel文件，同時在PREEvision上也進行二次開發，將Excel文件導入到PREEvision上進行自動建模，保證工具鏈之間建模內容的一致性，避免重復的操作，提升工作效率。通過EA二次開發插件所導出Excel格式文件如圖18所示。

4 結束語

在面向SOA架構開發的過程中，EA和PREEvision是2款可以提高開發及管理效率的數智化轉型工具。利用EA工具可以有效開展功能架構設計工作，通過UML語言可很好的闡述功能定義和功能實現邏輯。PREEvision可以很好的對SWC進行設計并導出ARXML供下游進行軟件開發，并提供優秀的追溯性。同時結合兩款軟件的不足之處和局限性，有針對性的進行二次開發，解決了開發流程中所存在的問題，打通了工具之間的瓶頸，使其更加適配于項目本身，提升設計效率，改善設計質量。

參 考 文 獻

[1] 李丹， 呂穎， 李駿， 等. 面向服務的體系架構[J]. 汽車文摘， 2021（10）： 52-57.

[2] 王東， 李井波， 張晨暉， 等. 一種基于SOA架構的總線系統：CN112822080B[P]. 2022-09-16.

[3] 編輯部. 德國大眾旗下CARIAD攜手意法半導體面向軟件定義汽車[J]. 單片機與嵌入式系統應用， 2022， 22（10）：2-2.

[4] 金華旺， 張桂新. 工業企業數智化轉型關鍵問題及推進路徑研究[J]. 信息系統工程， 2022， 346（10）： 14-17.

[5] KUGELE S， HETTLER D， PETER J.Data-centric communication and containerization for future automotive software architectures[C]. IEEE International Conference on Software Architecture （ICSA）， 2018.

[6] 李升凱， 吳長水. 智能駕駛硬件計算平臺及CAN通信軟件設計[J]. 軟件工程， 2022， 25（7）： 51-54.

[7] 唱佳韻， 孫明陽. 汽車文化APP界面設計研究——以紅旗汽車文化APP界面設計為例[J].工業設計， 2022， 195（10）： 64-66.

[8] 詹克旭. 基于AUTOSAR架構的汽車電子軟件產品的開發方法[J]. 汽車電器， 2021（11）： 73-76.

[9] 王飛飛， 劉夢夢， 翟曉蘭. 智能網聯汽車測試示范區發展模式探究[J]. 汽車實用技術， 2022（13）： 26-30.

[10] 李震， 劉敏. 基于AUTOSAR的整車電子電氣架構設計方法[J]. 機電一體化， 2012（11）： 73-76.

[11] 伏軍鋒. 汽車電氣系統設計[J]. 汽車電器， 2010（1）： 1-5.

[12] 陳敏. 基于EA的電子電氣架構功能設計探討[J]. 汽車電器， 2022（6）： 38-41+45.

[13] FENG J T. UML-Based Radar Software Design[C]//Proceedings of 5th International Conference on Electrical & Electronics Engineering and Computer Science（ICEEECS 2018）， 2018： 426-429.

[14] 王永輝. 基于PREEvision的汽車電子電氣架構設計介紹[J]. 汽車實用技術， 2019， 294（15）： 111-112.

[15] 匡小軍， 唐香蕉， 周濤， 等. 基于PREEvision的汽車電子電氣架構工具鏈研究[J]. 汽車電器， 2019， 372（8）： 62-64.

（責任編輯 明慧）

【作者簡介】

金劭南（1995-），男，中國第一汽車股份有限公司研發總院，碩士，研究方向為整車電子電氣架構設計。

高仕寧（1984-），男，中國第一汽車股份有限公司研發總院，碩士，研究方向為整車電子電氣架構設計。

李超（1986-），男，中國第一汽車股份有限公司研發總院，碩士，研究方向為整車電子電氣架構設計。

吳振舉（1982-），男，中國第一汽車股份有限公司研發總院，學士，研究方向為整車電子電氣架構設計。

陳泓宇（1990-），男，中國第一汽車股份有限公司研發總院，碩士，研究方向為整車電子電氣架構設計。

柳菁（1989-），女，中國第一汽車股份有限公司研發總院，學士，研究方向為整車電子電氣架構設計。