基于柔性化架構的復雜產品變更管理模型構建

史宏

(上汽通用汽車有限公司，上海 201206)

0 引言

隨著工業4.0概念的普及，5G、物聯網、大數據等新技術進入各行各業，原本相對簡單的產品變得越來越復雜。對于集成了軟件平臺、智能通信或者數據處理的復雜產品設計，通常涵蓋結構硬件、系統軟件等錯綜復雜的產品設計結構矩陣關系，由分布在各地的設計團隊協同完成[1]，所以傳統的單一以硬件為主的產品設計變更管理流程(如傳統汽車)或者以軟件設計為主的產品變更管理流程(如網絡平臺系統)，都無法很好地滿足復雜產品變更管理的需求。

當前，對于產品變更管理流程的研究主要集中在流程精益性和數據完整性管理兩個方面。流程精益性的相關研究側重于流程過程精細的劃分，將變更分為請求、評估、實施階段[2]，并引入工作流[3]概念對變更流程進行梳理，從橫向上分析產品的設計變更流程優化方案；數據完整性管理的相關研究側重于變更管理的平臺化控制，如基于PDM流程搭建變更管理平臺，實現產品變更過程的自動控制和變更數據傳遞的完整性[4]，將橫向的變更管理流程平臺化。然而，相關研究缺乏對復雜產品多層次結構、多維結構矩陣關系的分析，在復雜產品變更管理中，存在變更影響評估不足、多零件變更實施協同性不足甚至變更難斷點等問題，嚴重影響產品開發和交付進度，增加產品開發投入。

柔性化架構理念是一種基于靈活性和適應性概念的開發思路。該架構可以根據復雜產品的實際情況進行靈活調整，從而將過程/流程/軟件系統開發和復雜產品的變化相適應，便于處理各種異常或例外情況，提高流程/軟硬件的應變能力；當下柔性化架構主要應用于制造生產線的多品種柔性化生產架構設計[5]或軟件系統開發的柔性化設計。本文將柔性化架構開發理念應用于復雜產品變更管理模型開發中，并對優化后的流程模型進行推演驗證。

1 產品變更管理模型的建立

1.1 產品模型維

面向對象的方法表達主要包含屬性和方法兩種。對象屬性表達為獨立的實體，對象方法用來表示獨立實體之間的邏輯關系[6]。復雜產品模型可以表示為多個獨立實體和實體之間邏輯關系的組合，CP=(A，M)，其中A=(Ai，Aj，i=1，2，…，n，j=1，2，…，n)，組成復雜產品的所有部件和子系統的集合；M=(Mi，i=1，2，…，n)，關聯模型。

1.2 變更管理模型維

采用對象分析的方法表達，復雜產品變更流程模型可以表示為實物對象、實物對象之間的關系、流程對象、流程對象之間的關系；產品變更流程模型的邏輯關系組合，PF=(A，M，P，R)，其中A=(Ai，Aj，i=1，2，…，n，j=1，2，…，n)，實物對象組成復雜產品的所有部件和子系統的集合；M=(Mi，i=1，2，…，n)，部件和子系統的關聯模型；P=(Pi，i=1，2，…，n)，組成流程對象的所有階段、過程和子任務的集合；R=(Ri，i=1，2，…，n)，流程對象之間的關聯模型。

1.3 基于柔性化架構的流程模型建立

縱向上，通過復雜產品實物對象和實物對象的關聯基礎模型的搭建和按需配置的方式，完成實物對象關聯模型和流程模型之間的柔性關聯。

圖1 變更管理模型

2 柔性化架構變更管理模型演進

變更管理模型的實現和變更管理流程階段過程及過程關系緊密相關，變更管理過程優化是變更管理流程模型演變的過程。

變更管理模型流程對象的迭代優化，可以從細化變更任務、柔性規劃人員和實物對象關系柔性配置三個方面集成演進。

2.1 細化變更任務

考慮將變更階段流程對象顆粒度從6個進一步細分為8個，同時考慮到軟件項目的敏捷項目管理在變更任務管理中的運用，將變更任務分為更改前的預評估、撰寫標準化變更請求、產品工程內部更改審批、各部門更改評估、更改上會審批、更改批準、更改實施、更改關閉。詳細任務如下：

(1)更改前的預評審的過程，分為更改的需求及更改的影響，以初步確定后續是否需要撰寫更改，減少不必要的更改，提升工作效率。

(2)標準化變更請求的過程，可以減少撰寫出錯的概率，也便于后續各部門評估，提升整體工作效率。

(3)產品工程內部評審的過程，作為檢查和二級評審環節。

(4)各部門更改評估的過程，關鍵是確保變更信息流動的完整性。

表2給出了浮動位線攻擊方法的仿真結果。從表中可以看出,使用浮動“0”攻擊低電壓SRAM單元時,R1和R2的檢測電阻分別降低到3.5 MΩ和3.7 MΩ。使用浮動“0”攻擊的方法僅對減小R1和R3有作用;使用浮動“1”對低電壓SRAM單元進行攻擊時,最小可檢測電阻R3和R4分別從不可檢測分別變為260 MΩ和290 MΩ[11]。對于電阻R3和R4,使用浮動“1”攻擊效果更明顯,但此時的最小可檢測電阻R1和R2仍然不變。因此,我們需要使用浮動“0”和浮動“1”這兩種攻擊方法來檢測最小可檢測電阻R1-R4。

(5)更改上會審批過程，作為一級評審，結合各部門對變更的影響評估的數據，做出是否實施變更的決策。

(6)更改批準的過程，把決策落實到流程內的一個閥點。

(7)更改實施環節的過程和更改評估類似，需要確保所有更改各相關部門都能獲得更改實施的命令，同時設置統一的斷點時間。

(8)更改關閉的過程，也是一個閥點。

軟件變更管理采用敏捷方法和以硬件為主的變更管理不同：首先，對問題跟蹤需求表中的變更需求進行整理并放入Sprint backing中；其次，確定各需求的影響和優先級；最后，根據優先級確定特定需求的啟動變更的計劃或者版本迭代計劃，觸發變更后，通過Scrum的方法對系列變更內容或者迭代的軟件版本進行快速迭代更新，滿足產品開發需求。

2.2 柔性規劃人員

在模型設置中，首先，對各環節評估人員名單對評估流程進行統一規劃；其次，保留人員增減窗口，實現評審人員在不同變更實例中的柔性化，確保評審流程對象關聯模型的柔性，提高效率。

更改前的預評估階段，可以由更改請求發起方或者產品設計人員組織，有選擇性地發給關鍵部門如采購和制造進行影響評估；撰寫變更請求，除了產品設計人員進行撰寫，也可以添加相關配置人員，對撰寫的標準化文檔進行檢查；產品工程內部更改審批，可以請相關產品和項目主管進行檢查；各部門的評估環節，建議將采購、制造、物流、法規、財務等人員都劃分到評估行列，并請他們對更改進行審批；更改上會審批，主要是邀請更改評估委員會成員進行審批，關鍵任務是確定整車項目的負責人；更改實施環節，考慮到設計釋放、BOM釋放、物流斷點、采購合同、財務總費用變更等內容，需要請相關負責人更改文件并審批。

2.3 實物對象關系柔性配置

實物對象和實物對象的關系模型可以根據產品特征配置實現。以混動智能汽車的動力總成為例，增程器和減速器之間的硬件配合關系包括間隙和尺寸匹配關系等，任何增程器的變更都可能導致減速器的同步變更需求；增程器和減速器的驅動由驅動模塊控制，增程器和減速器上任何感應和執行部件的變更都可能導致驅動模塊控制軟件程序的調整。與此同時，在搭建變更模型時，部件之間的軟硬件交互關系已經通過實物對象和實物對象的關系模型確定，后續任何新產品設計需要運用變更管理模型時，只需實現對象關系模型的重新配置。

3 智能汽車變更管理流程模型

3.1 智能汽車產品模型

某汽車公司全新智能汽車產品，從功能實現維度將智能汽車劃分為車輛設施技術和信息交互技術兩個部分。車輛設施技術主要是通過機電一體的硬件結構實現出行服務，其硬件嵌入式控制系統是為了實現出行功能自動化而設計；信息交互技術主要是采用嵌入式的軟件系統平臺實現通信和交互功能，應用程序在軟件系統平臺上開發，如5G通信實現車聯網V2V功能、汽車虛擬鑰匙實現車輛王V2X功能。具體見表1。

表1 按功能維度分解智能汽車產品功能

運用產品模型維分析，以智能汽車總成為例，CP智能汽車產品=(A1車輛設施技術，A2信息交互技術，Mi車輛設施和信息交互的邏輯關系)，Mi=邏輯關系，如M1=智能網聯汽車5G通信(交互技術)和車輛輔助駕駛功能模塊通信(車輛設施)，輔助駕駛功能模塊再和整車控制模塊交互并發信號給驅動系統，執行車輛加速減速的命令。又以車輛設施技術為例，CP車輛設施技術=(A11內飾，A12外飾，…，A1n自動駕駛，M1i)，M1i=產品的邏輯關系，如M11=智能網聯汽車輔助駕駛的視覺傳感器(車輛設施)和硬件的整車控制模塊通信(車輛設施)，整車控制模塊做決策并發信號給驅動系統，執行驅動命令。CP信息交互技術=(A21通信技術，A22智能座艙，M2i)，M2i為產品的邏輯關系，以M21兩輛汽車通過通信模塊進行交互，并通過智能座艙進行信號傳遞，如中控屏顯示通信內容，智能座椅通過震動提醒駕駛員由信息輸入，如圖2所示。

3.2 智能汽車變更管理流程搭建

模型建立步驟如下：

(1)確定流程流程對象，包括預評審、撰寫變更請求、內部評審、各部門更改評估、上會審批、更改批準、更改實施、更改關閉。

(2)建立流程流程對象關系，包括在各流程中添加判斷條件，確定下一步步驟是否實施；撰寫環節加入配置工程師審查，變更評估前的環節加入產品工程內部主管審查，變更上變更委員會批準等。

(3)考慮車輛設施技術和信息交互技術兩個部分的產品變更特點，考慮到車輛設施技術的軟件屬性，變更管理采用敏捷方法進行快速迭代更新，滿足產品開發需求。在智能汽車變更管理流程模型在變更問題撰寫階段，加入迭代循環逐步明確需求和問題，如圖3所示。

(4)建立實物對象關聯模型和流程對象模型之間的關聯。以智能汽車車輛設施技術的電驅動系統模塊為例，電驅動系統模塊=(A131電機A132減速器A133逆變器A134電驅殼體A135熱交換A136潤滑冷卻A137駐車A138電子泵A139差速器A140旋變A141標定程序，M13i，P13i，R13i)，其中i=1，2，…，n。例如，M131是電機和減速器的尺寸配合關系；P131是指在撰寫電機變更請求的階段，會通過回答問題的形式確定對減速器的影響，以及確定是否需要推送減速器變更的請求給對應產品設計人員；R131是指除了在撰寫電機變更請求的階段對減速器進行評估，還需要在內部評審部門更改評估時同步推送減速器變更影響的評估。

(5)應用柔性化架構變更管理模型方法論建立智能汽車變更管理架構模型，如圖3所示。

3.3 新流程模型實踐結論

運用新搭建變更管理流程模型在智能汽車開發項目的實踐結果表明：

(1)數據完整性強。將汽車所有零部件和軟件系統的變更管理集成到一個變更管理框架內，數據完整性更好。

圖2 智能汽車結構模型

圖3 智能汽車變更管理模型

(2)軟硬件變更整合度高。考慮到軟件變更的迭代敏捷管理，將軟件變更實施和硬件變更實施在一個系統內整合協同好。

(3)零部件變更交互優。通過產品對象和流程對象的合成、變更的影響分析，充分考慮到其他相關零件的變更，變得更加準確；沒有發生由于一個零部件變更引起其他零部件變更未被識別到的事件。

4 結語

本文針對如何構建復雜產品變更管理模型進行了詳細闡述。通過建立產品模型維和變更管理模型維，結合柔性化架構理念，從橫向和縱向兩個維度著手，在橫向上保證單一產品的變更管理流程實現，在縱向上對多種產品變更集成管理，從而構建全新的產品變更管理模型。在某公司全新智能汽車開發實踐中，用復雜產品變更管理模型方法，開發了智能汽車產品變更管理模型，結果表明新流程在數據完整性、軟硬件變更整合及零部件變更交互上具有顯著優勢。