同步開發數字化評審流程研究

武翔宇 王夢琦

（中汽信息科技（天津）有限公司, 天津 300300）

0 引言

隨著現代科技不斷地發展，汽車的電氣化、智能化程度越來越高，汽車車型功能不斷增多、系統不斷升級，然而越是復雜的功能和系統越容易出錯，除了需滿足功能、安全要求外，還需兼顧成本最優并滿足用戶不斷提高的審美標準。

目前判斷汽車新產品的設計開發是否滿足生產工藝的要求仍然處于人工干預的階段，往往需專人進行工藝評審數據單的手動審核，評審流程存在效率低下、耗費人力、人工評審可能存在誤差等問題。因此，在設計階段同步進行評審十分必要，同步開發數字化流程的研究可以更快、更早地發現、解決和優化問題。本文提出一種利用計算機數據結構將工藝評審數據轉化為評審模型的方法，該方法為評審標準數據賦予可復用性，提高工藝評審的效率。

1 同步開發數字化流程

1.1 需求分析

軟件需求分析是軟件系統開發過程中尤為重要的環節，首先需要對整個流程需求進行調研，然后根據同步工程范圍與評審的數字化流程進行需求分析。整個同步工程的流程周期耗時長且較為繁瑣，人工比對的方式存在弊端，同步開發數字化可以解決這些弊端。它可以將信息模型化形成評審標準模型，通過將待評審項與評審標準自動比對的方式輸出評審結果，不僅節約了人力，而且可重復利用的評審標準模型能夠使同類型評審提高效率，從而形成同步開發數字化流程。

數字化評審通過梳理同步開發評審標準并制定相應的評審規范；同時梳理評審標準關聯的測試需求及測試需求關聯的測試邏輯。以實現自動獲取評審項、調用評價標準、關聯測試需求及測試邏輯。

1.2 總體設計

整體來說，同步開發數字化流程總體設計需要解決以下問題：（1）評審的流程中如何實現同步開發的數字化流程；（2）系統如何存儲和獲取自動評審項關聯的設計詳情；

（3）系統如何設計和存儲與設計詳情相關聯的評審標準；

（4）系統如何設計評審表單中的評審模型，評審標準與評審模型之間的關聯關系如何建立。

基于以上問題，針對同步開發數字化流程的特點進行系統軟件總體設計，通過設計與開發同步工程管理系統進而實現對同步開發數字化流程的管理。同步工程管理系統旨在解決同步開發流程中存在的問題，實現同步開發數字化自動評審流程。

2 軟件設計模式及架構

2.1 設計模式

根據同步開發數字化流程的特點，在軟件的整個生命周期中，軟件系統的設計是軟件開發的關鍵環節，以系統的需求分析作為基礎[1]。軟件設計模式的重點是為反復出現的各種設計相關問題提供一個通用的解決方案。

軟件的設計模式為軟件整個開發過程提供了整體的設計方案，從具體組件功能的角度來描述整個系統的結構，可以有效加快軟件系統開發的速度，不僅可以降低系統各個組件之間的耦合性，還更利于系統后期維護，使新了解系統的工程師用更短的時間、更高效的速度來了解整個系統，增強系統的穩定性為提升系統后期可擴展性帶來了便利[2]。

早在20世紀70年代，國外就提出了業務模型、用戶界面、控制器（Model View Controller，MVC）設計模式的概念，即使用MVC模式將模型（M）和圖像（V）實現代碼分離。MVC模式具有耦合性低、重用性高、部署快、可維護性高的優點，主要用于Web應用程序的開發，是目前軟件開發的主要模式。MVC設計模式也可應用于同步開發數字化流程，MVC模式結構如圖1所示。

圖1 MVC模式結構

2.2 總體框架

規劃一個完整的可滿足同步開發數字化流程研究的同步工程管理系統，系統總體框架是所有工作的先決條件，也是奠定系統性能的基礎，對于軟件系統的開發至關重要。系統的體系結構應該分層組織，將系統的功能模塊化低耦合，可以更加方便快捷地根據實際需求進行修改、重用和部署，進而能滿足未來系統彈性擴展的要求。

同步工程管理系統具體分為應用框架、技術框架、系統框架，其中應用框架滿足訪問控制、權限管理、用戶管理、其他應用的基本應用服務和表單模板、界面模板的應用模板；技術框架分為登錄認證、異常處理、數據庫連接、日志管理、緩存處理、數據加密和集成框架、服務器頁面（Java Server Pages，JSP）標簽、軟件界面設計（User Interface，UI）應用技術的框架與技術；系統框架為服務器操作系統與數據庫，系統總體框架如圖2所示。

圖2 同步工程管理系統總體框架

3 工藝數據解析

3.1 評審模型概述

同步工程中的評審標準由同步工程專家與汽車產業專家共同制定[3]，該標準取代傳統評審單中的“問題描述及原因分析”和“對策及要求事項”2 項數據項。評審單是汽車工藝中待評審內容的評判準則，由自然語言或數值構成。通過對傳統評審單中的數據進行分析，可將評審標準詳細劃分為：數值類、布爾類、字段類、故障碼類和數據標識符（Data IDentifier，DID）類。

因此，在評審標準數據模型化的過程中，可將評審模型定義為以下5種：值模型、布爾模型、字段模型、故障診斷標準模型、DID 模型。下面詳細闡述各個模型的轉化方法與構成規范。

3.2 評審類別與評審模型的關系

一個類別可包含多個評審標準數據，而評審標準與評審模型為一一對應的關系，因此同一類別下可包含多種評審模型。同類別數據評審模型相對固定，但也可根據具體的評審需求進行選擇。如進行診斷流程一致性評審時，多數情況下可使用DID 模型，少數情況下如果評審項無法用DID 模型涵蓋也可選擇其他模型替代[4]。

3.3 值模型

3.3.1 值模型的轉化方法

車輛狀態數據中車輛轉向速度、車輛速度、車輛發動機水溫、蓄電池上電時間等以及生產環境要求維度下的環境溫度、車輛水平度、環境光線照度等都屬于數值型數據，因此可以根據標準名稱、標準值和單位，將以上同類型的數據轉化為值模型。

3.3.2 值模型的構成與評審規范

值模型由3 部分組成，分別是：標準名稱、標準值和單位。標準值可細化為數值型標準值和范圍型標準值，標準值與單位共同成為本模型的評判準則。

（1）標準名稱定義評審標準的名稱，數據類型為字符串。利用標準名稱與待評審內容進行完全匹配，確保評審內容的準確性。

（2）“標準值”定義標準值的大小，數據類型為數值。可以輸入1個數值固定標準值（固定型標準值）或2個數值（范圍型標準值）將范圍劃定。評審中需要判斷的值是否相同或值是否在范圍中，值不同或值不在范圍中視為評審項不通過。

（3）“單位”定義標準值的單位，數據類型為字符串。評審過程中需驗證待評審內容的單位與標準模型的單位是否完全一致，不一致則評審項不通過。

3.3.3 值模型示例

在評審系統功能可制造性維度下，車輛狀態要求為“車輛速度=0 m/s”，將此項評審數據按照值模型的結構“標準名稱+固定型標準值+單位”轉化后的結果如下：

（1）標準名稱：車輛速度；

（2）固定型標準值：0；

（3）單位：m/s。

3.4 布爾模型

3.4.1 布爾模型的轉化方法

布爾類型的數據是常見的數據類型之一，其數據要求符合二元性。車輛狀態要求維度的數據（如車輛啟動/熄火、電源擋位狀態、車輛空調狀態、車輛電器開關狀態），包含是與否、開與關、有與無的均可使用布爾模型的結構將其轉化。

3.4.2 布爾模型的構成與評審規范

布爾模型由3 部分組成，分別是：標準名稱、標準值、標準值的語義集。標準名稱將待評審內容與對應的評審標準模型匹配起來，標準值將本布爾模型與標準值的語義集進行匹配，標準值的語義集是本布爾模型的評判準則。

（1）“標準名稱”定義評審標準的準確名稱，數據類型為字符串。利用標準名稱與待評審內容進行匹配，確保的準確性。

（2）“標準值”定義標準值的準確內容，數據類型為字符串。標準值作為標準值語義集的標簽，與語義集進行匹配。

（3）“標準值的語義集”由布爾模型預設，自動匹配。如果標準值與某語義集中的某字段完全匹配，則該語義集內的全部字段視為與標準值同義。可使用該語義集與待評審項進行比對，無匹配項視為評審不通過。

3.4.3 布爾模型示例

如評審系統功能可制造性評審車輛狀態要求中的車輛空調狀態，評審標準數據為“車輛空調狀態關”。將以上評審數據按照布爾模型的結構“標準名稱+標準值+標準值的語義集”轉化為模型的結果是：

（1）標準名稱：車輛空調狀態；

（2）標準值：關；

（3）標準值的語義集：關、關閉、未開啟、緊閉、已關、閉、閉合。

3.5 字段模型

3.5.1 字段模型的轉化方法

字段模型需要進行字符串比對的任意字符串類型的數據都可通過提取關鍵字符信息轉化為字段模型。此外，如遇到某種復雜結構的評審標準數據無法歸類于其他4 種評審模型時，可以從原始數據中提取關鍵信息作為關鍵字段從而轉化為字段模型。因此由字符串組成的評審標準數據或任意判斷是否包含關鍵字段信息的數據都可以轉化為字段模型。

3.5.2 字段模型的構成與評審規范

字段模型由多個字段模塊構成。本模型具備較強的可編輯性，可由一個或多個字段組成本模型的評判準則。“字段1”定義評審標準的內容或關鍵字/詞。數據類型為字符串。如待評審內容與本字段不一致則評審不通過。“字段n”可由評審工程師根據評審標準實際長度添加，數據類型為字符串。如待評審內容與該字段不一致則評審不通過。

字段類型為2種：關鍵字段和組合字段。

（1）關鍵字段是評審標準的核心字段，如待評審內容包含關鍵字段視為評審通過。

（2）組合字段定義評審的多條規則，組合字段間為并列關系，多條組合字段組合成為一條評審準則，只要待評審內容包含多個組合字段中的一個視為評審通過。

根據評審標準數據定義多個字段共同作為評審準則，字段數量不受限制。

評審數據與模型字段進行比對的過程可引入算法，計算二者匹配度，提升數據評審的準確度[5]。

3.5.3 字段模型示例

如評審系統功能可檢測性評審的系統輸出信號狀態可查詢時，關于發動機怠速起停信號的評審標準數據為“應體現發動機怠速起停許可功能輸入信號標識符”。本條數據全部為字符串構成，因此可將長字符串分解為關鍵字符串轉化為字段模型如下：

關鍵字段1：發動機怠速起停；

關鍵字段2：許可功能輸入；

關鍵字段3：信號標識符。

4 系統詳細設計及界面

根據需求分析系統組成及其功能，完成詳細設計以及界面，對軟件系統的設計進行相對完整的剖析。

系統的登錄模塊是系統的基礎模塊，在同步工程管理系統的設計過程中，登錄界面系統只能登錄系統維護過的賬號，若忘記密碼可以點擊“忘記密碼”顯示“請聯系管理員郵箱”。系統會首先預置好管理員的賬號，管理員可以通過管理設置模塊維護賬號信息進行賬號的新增、刪除、停用、重置密碼、更改權限的操作。

系統的建立評審任務模塊以獨立的菜單在頁面顯示，頁面顯示評審任務基礎信息，可以通過索引條件搜索評審任務，可以新增和編輯評審任務。點擊進入評審表單頁，評審表單頁上方可新增可制造性評審和新增可檢測性評審（評審維度分為可制造性維度和可檢測性維度），右上方為導入設計詳情按鈕，導入模型按鈕；評審表單頁中間為自動評審表單詳細內容，顯示任務名稱、評審類別、車型、功能、控制器、評審維度、評審子維度、一級子項、評審項、設計詳情、評審標準且都為必填項；評審標準右邊列為評審模型列，顯示新建模型/編輯模型按鈕；下方為保存和開始評審按鈕。頁面操作時先新增評審維度（可制造性維度/可檢測性維度），選擇評審維度對應的評審子維度（評審子維度在管理設置模塊的子維度管理中進行維護），填寫對應的一級子項，填寫一級子項對應的評審項，然后點擊保存按鈕再點擊導入詳情按鈕，自動匹配并顯示評審項對應的設計詳情（評審項對應的設計詳情在后臺維護），然后填寫設計詳情對應的評審標準，然后點擊保存按鈕再點擊導入模型按鈕，自動匹配并顯示評審標準對應的評審模型（評審標準對應的評審模型在后臺維護且評審標準唯一），若評審標準有對應的評審模型可編輯模型若評審標準沒有對應的評審模型則可新增模型，評審表單中一個評審維度對應多個評審子維度，一個評審子維度對應多個一級子項，一個一級子項對應一個評審項。先保存，再點擊開始評審。如果未填寫完整就點擊開始評審，則提示“請把以上數據補充完整”再進行評審，填寫完整后點擊開始評審則進行自動評審，評審表單頁面詳情如圖3 所示。

圖3 評審表單頁面詳情

評審報告查詢模塊以獨立的菜單在頁面顯示，頁面顯示上方為車型、控制器、功能的索引條件；中間左邊導出按鈕可按照評審任務導出模板樣式導出Excel 表格；下方展示評審任務編號、評審任務名稱、車型、評審類別、控制器、功能、負責人狀態信息，操作列可查看當條評審任務的詳情。管理員登錄后默認的頁面是報告查詢頁面，評審報告頁面詳情如圖4所示。

圖4 評審報告頁面詳情

建立評審模型模塊和數據庫管理是在后臺進行維護的，管理設置模塊可以對子維度管理進行維護。子維度管理頁面上方為評審維度的可制造性、可檢測性Tab 頁和子維度索引條件；中間左邊新增按鈕可新增相關的子維度；下方展示子維度，操作列可編輯、刪除子維度，子維度管理頁面詳情如圖5所示。

圖5 子維度管理頁面詳情

管理設置中的評審任務管理頁面上方是車型、控制器、功能、負責人的索引條件；下方顯示任務編號、任務名稱、車型、評審類別、控制器、功能、負責人、狀態，操作列可刪除狀態為未開始和已完成的評審任務，評審任務頁面詳情如圖6 所示。

圖6 評審任務管理頁面詳情

日志管理頁面上方顯示用戶名、職責、對象的索引條件；下方展示用戶名、職責、對象、操作內容、操作時間。賬號管理頁：上方是賬號、姓名、職責的索引條件；中間左邊新增按鈕可彈窗新增賬號，填寫賬號、姓名、郵箱，選擇職責且賬號、姓名、職責為必填項；下方顯示賬號、姓名、職責（管理員、評審工程師）、郵箱、狀態（啟用為正常狀態，停用為鎖定狀態）、創建時間；操作列可刪除、停用/啟用、重置密碼、更改權限。個人信息頁面可上傳用戶頭像（只能上傳JPG 或PNG 格式的用戶頭像，且不超過500 kB）、填寫姓名且姓名為必填項、職責為新增賬號時設置不可操作、填寫郵箱，可以通過按鈕提交個人信息、清空個人信息；通過修改密碼頁面輸入原密碼、新密碼、確認密碼且都為必填項，可以通過按鈕提交密碼、清空密碼。

5 結束語

本文對同步開發數字化評審流程開展研究，梳理出工藝評審類別與傳統工藝評審間的邏輯結構，并提出了一種將同步工程標準數據轉化為數字化模型的方法。該方法包含5種基本數據模型，可應用于現階段5種類別的同步工程工藝評審，同時也為傳統評審標準數據提供了可復用性，能夠提高工藝評審的效率。基于評審標準數據的數字化，可利用轉化后的模型實現同步工程工藝自動評審，進而大大提高評審工程師的工作效率。