同步开发数字化评审流程研究

武翔宇 王梦琦

（中汽信息科技（天津）有限公司, 天津 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种类别的同步工程工艺评审，同时也为传统评审标准数据提供了可复用性，能够提高工艺评审的效率。基于评审标准数据的数字化，可利用转化后的模型实现同步工程工艺自动评审，进而大大提高评审工程师的工作效率。