# 加工可靠性综合评价系统：项目成果说明（详细审阅版）

## 一页总结

本项目面向数控机床中试验证与运行数据分析场景，统一保存设备台账、故障与维修记录、退化监测、试验记录和制品抽样数据，并输出服役可靠性分析与加工可靠性综合评价结果。每项结果都可以查到对应的原始记录和评价规则。

系统的核心价值不在于重复实现通用“设备管理”，而在于把设备故障、过程性能退化和最终制品质量连接到同一套评价框架中：既可分析故障间隔与可靠度，也可按设备整机、辅助部分、制品三层指标定位薄弱环节和数据缺口。

当前代码与项目文档可核实的技术实现为 Vue 前端、FastAPI 后端、Pydantic 数据校验、SQLAlchemy 数据模型、PostgreSQL 异步访问，以及 NumPy、SciPy 支持的威布尔分析。项目包含可复现演示案例；尚未发现独立的后端自动化测试文件，关键公式的已知答案测试应作为后续优先完善项。

相较早期以 C# WinForms 为代表的单机桌面方案，本版将采集、分析、配置和数据管理拆分为可通过网络协作的 Web 系统，使现场录入、后台管理和工程分析可以围绕同一数据库并行开展，并为平板、手机等浏览器终端接入提供架构基础。

---

## 1. 项目定位与要解决的问题

### 1.1 业务背景

数控机床的可靠性与加工能力不能只靠“故障次数”或“制品合格率”单独判断：

- 故障记录反映设备或辅助单元的失效与维修情况；
- 精度、刚度、切削力、夹持力等监测数据反映过程能力是否退化或波动；
- 制品抽样数据反映最终加工质量是否稳定、是否满足尺寸和几何要求。

如果这些数据分散在表格、纸质记录或彼此独立的页面中，评价人员很难追溯“总分为什么变化”“问题发生在设备、辅助单元还是制品侧”“缺少什么数据导致无法评价”。

### 1.2 系统目标

系统将上述数据统一保存和计算，提供两类分析：

1. **服役可靠性分析**：基于故障间隔进行 Weibull 拟合，输出形状参数 β、尺度参数 η、MTBF、可靠度、累积故障概率、概率密度和失效率曲线。
2. **加工可靠性综合评价**：按“设备整机—辅助部分—制品”三层体系计算 13 个底层指标，经归一化和分层加权后输出综合得分、准则层得分、单项明细和缺口提示。

### 1.3 目标用户与决策价值

根据系统功能和项目运行逻辑，目标使用者可包括中试验证、设备管理、可靠性工程、工艺与质量分析人员。系统为其提供：

- 故障与维修记录的结构化保存；
- 设备与部件的运行状态和趋势信息；
- 可靠性、可用度、失效率、维修时间等量化结果；
- 从“总分”下钻至“准则层—单指标—原始数据”的问题定位路径；
- 数据不足时的明确缺口与补录指引。

这是一套面向工程评价与决策支持的数据分析软件，而非只用于登记信息的通用后台。

### 1.4 评价算法来源与知识产权边界

系统中的算法需要区分两类来源：

1. **通用可靠性方法**：MTBF、MTTR、可用度、Weibull 分布及其 β、η、可靠度、失效率等，属于可靠性工程中广泛使用的方法。
2. **课题组专利评价方案**：“加工可靠性综合评价”并非把通用指标简单排列，而是课题组共同研发并形成专利成果的一套专门评价方案。其专业性体现在设备整机、辅助部分、制品三层体系，13 项底层指标的数据口径、方向定义、归一化方式、权重结构和逐层汇总关系。

候选人参与了该专利方案的研发及软件实现，但专利所有人并非候选人，不能表述为“独立发明”或“本人拥有该专利”。推荐口径是：

> 参与课题组加工可靠性专利评价方案的研发，并负责/参与将评价指标、数据规则和计算过程写入可配置、结果可追溯的软件系统。

这种贡献同时体现两种能力：一是参与工业评价方法研究，二是将研究方案写成数据模型、计算服务和用户可操作的软件流程。

---

## 2. 差异化价值：为什么不是重复造一个管理系统

系统确实包含设备、用户、配置、故障、制品等管理功能，但这些功能服务于后续的可靠性评价，而非项目终点。

| 通用管理系统通常解决的问题 | 本项目进一步解决的问题 |
|---|---|
| 记录设备和故障 | 将相邻故障记录转为故障间隔、MTBF、可靠度和失效率 |
| 保存测量数据 | 识别精度、刚度、切削力、夹持力用途，并计算退化率或波动度 |
| 保存制品检验结果 | 将尺寸、几何、粗糙度样本转为合格率和符合率评价 |
| 展示统计报表 | 通过归一化、权重和分层汇总形成综合评价并定位薄弱环节 |
| 表单报错 | 返回缺失指标、配置位置和需要补齐的字段，避免直接给出无依据结论 |

项目的关键设计思想是：**从数据采集、业务配置和确定性计算，到结果展示和问题追溯，使用统一的数据和规则。**

此外，系统并非只调用现成的 Weibull 库，而是将通用可靠性方法与课题组专利评价体系结合：通用方法负责故障规律和寿命分析，专利方案负责把设备状态、过程退化和制品质量组织成面向加工可靠性的综合结论。

---

## 3. 输入、处理与输出

### 3.1 输入数据

| 数据类别 | 代表字段或内容 | 主要用途 |
|---|---|---|
| 设备与基础配置 | 设备编号、设备类型、子系统、部件、故障来源、故障模式、故障原因 | 定义分析对象和故障归属 |
| 故障与维修记录 | 故障开始、故障结束、维修开始、维修结束、设备、子系统、部件 | 计算故障间隔、MTBF、可靠度、可用度、MTTR |
| 退化监测记录 | 测量日期、参数值、可靠性用途标记 | 计算精度、刚度及过程力指标 |
| 制品与生产数据 | 产品、批次、样本总数、合格数、参数样本值 | 计算合格率、粗糙度一致性、几何精度和尺寸公差符合率 |
| 评价配置 | 指标用途、理想值、极端值、上下限、指标权重、准则层权重 | 统一计算口径、归一化和汇总规则 |
| Excel 基础信息 | 子系统、部件、故障来源、故障模式、故障原因、设备等表格 | 同步基础信息，减少手工重复录入 |

### 3.2 核心处理过程

~~~text
业务配置与原始记录
        ↓
字段校验、对象关联、时间排序与用途分类
        ↓
故障间隔 / 退化序列 / 制品样本序列
        ↓
可靠性与质量指标计算
        ↓
归一化、权重汇总、缺失项判断
        ↓
API 返回结构化结果
        ↓
前端图表、明细表、状态与缺口展示
~~~

### 3.3 输出结果

系统可输出：

- 服役可靠性：β、η、MTBF、R²、可靠度曲线、CDF、PDF、失效率曲线；
- 加工可靠性：综合得分、B1/B2/B3 准则层得分、13 个底层指标原值和百分制得分；
- 数据完整性：缺失指标、缺失原因、对应配置页面及所需字段；
- 业务展示：设备状态、故障趋势、最近故障、公告、设备和制品关联信息。

---

## 4. 核心业务逻辑

### 4.1 服役可靠性：故障记录到 Weibull 分析

系统首先按设备和故障时间对记录进行整理，避免把不同设备的累计时间混为同一寿命样本；再计算相邻故障之间的时间间隔。

当有效故障间隔数量达到计算要求后，威布尔分析服务执行：

1. 对故障间隔排序；
2. 以中位秩法构造经验累积故障概率；
3. 通过对数变换和线性回归估计初始参数；
4. 通过最大似然优化 β 与 η；
5. 计算 MTBF、可靠度、累计故障概率、概率密度和失效率。

关键业务含义：

- β 描述失效趋势；
- η 描述特征寿命尺度；
- MTBF 描述平均故障间隔；
- 可靠度 R(t) 描述在规定时间 t 内仍正常工作的概率。

数据不足时，系统通过异常或接口错误提示中断计算，而不是生成伪结果。

### 4.2 加工可靠性：设备—过程—制品的综合评价

加工可靠性模块不只看设备故障，而是组合 13 个底层指标：

| 评价层 | 指标 | 主要数据来源 |
|---|---|---|
| 机床整机 B1 | 可靠度、可用度、精度波动度、精度退化率、刚度退化率 | 故障记录、维修时间、退化监测 |
| 辅助部分 B2 | 失效率、平均修复时间、切削力波动度、夹持力波动度 | 辅助单元故障与维修记录、过程监测 |
| 制品 B3 | 合格率、粗糙度一致性、几何精度符合率、尺寸公差符合率 | 批次与抽样检测数据 |

每个指标先按其业务公式计算，例如：

- 可靠度：根据观察期运行时间和 MTBF 计算；
- 可用度：MTBF / (MTBF + MTTR)；
- 精度退化率：首末精度值相对初值的变化；
- 刚度退化率：首末刚度值相对初值的下降；
- 过程力波动度：标准差与均值之比；
- 合格率：合格数 / 总样本数。

随后系统按正向或逆向指标进行 Min-Max 归一化，统一到百分制；再使用配置化的指标权重和准则层权重，先得到 B1、B2、B3 得分，最后汇总为加工可靠性综合得分。

### 4.3 数据缺口提示

评价并不假设所有数据都齐全。针对每个指标，系统配置数据来源和所需字段；当无法计算时，返回：

- 缺失的指标；
- 无法计算的原因；
- 应前往的配置或采集页面；
- 需要补充的字段。

这使输出不仅有“结果”，还有结果成立所依赖的数据条件。

---

## 5. 软件架构与代码导航

### 5.1 架构概览

~~~text
Vue 前端
  ├─ 数据采集、故障录入、设备台账、系统配置
  ├─ 服役可靠性、退化、制品、加工可靠性分析页面
  └─ 调用后端 REST API 并展示图表/表格
        ↓
FastAPI 后端
  ├─ routers：按设备、故障、退化、制品、分析、配置等领域提供接口
  ├─ schemas：Pydantic 请求/响应数据校验
  ├─ services：Weibull 分析与 Excel 基础信息同步
  ├─ models：SQLAlchemy ORM 实体与关系
  └─ core：配置、异步数据库连接、事务提交与回滚
        ↓
PostgreSQL
  └─ 设备、故障、退化、制品、试验、配置、用户、状态日志等数据
~~~

### 5.2 关键功能的定位示例

| 需求或页面 | 前端位置 | 后端接口/逻辑 | 数据支撑 |
|---|---|---|---|
| 故障录入与关闭 | fault-entry 页面 | fault 路由 | FaultRecord、设备状态日志 |
| 设备台账与配置 | equipment-ledger 页面 | equipment 路由 | Equipment、子系统、部件配置 |
| 退化数据采集与趋势 | data-collection / degradation 页面 | degradation、analysis 路由 | DegradationRecord、DegradationValue、参数与指标绑定 |
| 服役可靠性分析 | reliability 页面 | analysis 路由、WeibullAnalyzer | 故障记录、故障间隔 |
| 加工可靠性评价 | simulation 或分析页面 | analysis 路由中的综合评价逻辑 | 故障、退化、制品、配置与权重 |
| 基础信息导入 | 运维/初始化脚本 | base_info_sync 服务 | Excel 与基础配置表 |

### 5.3 分层原因

- 前端负责采集和呈现，避免在页面中直接实现复杂公式；
- 路由层负责接收请求、查询数据和组织响应；
- 业务服务或计算函数负责确定性公式，便于单独检查；
- 数据模型层描述实体、字段与关系；
- 数据库层保存可追溯的原始记录和配置。

这种分层使一个指标变更可以沿“页面—接口—计算—模型—数据”路径定位影响范围。

### 5.4 从 C# WinForms 单机方案转向 Web 架构

根据项目开发经历，早期方案采用以 C# WinForms 为代表的桌面程序形态。这类方案适合单机离线运行、直接连接本地仪器或在固定工位使用，但用于跨岗位的数据协同时存在明显限制：

- 软件和数据容易绑定在某一台电脑上，现场采集后仍需导出、搬运或二次整理；
- 录入、分析和管理难以同时进行，容易形成串行工作流程；
- 软件升级需要逐台客户端处理，版本一致性和数据口径更难管理；
- 管理人员和分析人员无法随时从其他终端查看同一批最新数据；
- 本地文件容易形成多个副本，增加数据重复、遗漏和追溯困难。

本项目的核心任务并非直接控制某一台机床或采集卡，而是组织多来源试验与运行数据、执行评价计算并共享结果，因此采用浏览器/服务器模式更符合业务目标。

~~~text
传统单机模式
现场记录 → 本地文件/桌面软件 → 人工导出 → 回到办公室分析 → 再整理报告

本项目 Web 模式
现场浏览器录入 ─┐
后台配置与清洗 ─┼→ 集中数据库 → 统一计算服务 → 多角色查看与分析
工程评价与展示 ─┘
~~~

### 5.5 各项技术选择及原因

| 技术或设计 | 选择原因 | 解决的问题 |
|---|---|---|
| 前后端分离 | 数据采集界面、业务计算和数据库职责不同，需要分别迭代 | 避免公式、页面和数据访问混在一起；便于定位影响范围 |
| Vue 3 + Vite | 适合构建表单、台账、配置页和多页面单页应用，组件可复用、开发反馈快 | 统一现场录入、后台配置和分析展示体验 |
| Element Plus | 提供成熟的表格、表单、对话框、分页和校验组件 | 降低工业管理页面重复开发成本，保持交互一致 |
| ECharts | 适合趋势、可靠度曲线、状态与统计图表 | 将计算结果转为工程人员可快速理解的可视化 |
| FastAPI | 与 Python 科学计算生态衔接自然，并提供参数校验、异步接口和 API 文档能力 | 将数据查询、评价计算与前端解耦，便于复用分析接口 |
| Pydantic | 对请求和响应字段进行结构化校验 | 减少前后端字段类型不一致和无效输入 |
| SQLAlchemy | 用模型与关系组织设备、故障、退化、制品和试验数据，并管理事务 | 降低手写 SQL 的重复与关联维护成本 |
| PostgreSQL | 适合多用户集中访问、事务处理、关联查询和持续积累历史数据 | 替代分散本地文件，形成统一数据源和可追溯记录 |
| NumPy + SciPy | 提供数组、回归、优化、Gamma 函数等可靠科学计算能力 | 避免重复实现成熟数值算法，支撑 Weibull 分析 |
| REST API | 前端、未来移动端或其他系统可通过统一接口访问能力 | 为多终端、系统集成和后续扩展保留边界 |

### 5.6 多角色协作与移动化价值

前后端分离加集中数据库使不同角色能够围绕同一数据源并行工作：

- 现场人员可录入故障、维修、退化监测和制品检测数据；
- 配置或管理人员可维护设备、部件、指标、阈值和数据质量；
- 可靠性或质量人员可读取最新数据并进行计算与分析；
- 管理人员可通过仪表盘查看状态、趋势和薄弱环节。

前端代码包含响应式布局规则，因此具备适配不同屏幕的实现基础；浏览器架构也允许部署后从电脑、Pad 或手机访问。需要准确说明的是：**多终端访问是当前架构支持的能力，完整移动端体验仍需经过具体页面适配、网络部署、权限和现场环境验证。**

### 5.7 架构优势总结

这次技术迁移解决的不是“把 C# 换成 Python”这样单纯的语言替换，而是把单机工具升级为可协作的数据平台：

- 从本地数据副本转向集中、统一、可追溯的数据源；
- 从采集后再分析的串行流程转向多岗位并行协作；
- 从固定电脑使用转向浏览器和多终端访问；
- 从界面、计算、数据耦合转向可分别维护和扩展的分层架构；
- 从一次性结果计算转向可以持续积累、复算和比较的工程历史数据。

---

## 6. 数据存储与业务实体

### 6.1 主要实体关系

~~~text
设备 Equipment
 ├─ 故障记录 FaultRecord
 ├─ 退化记录 DegradationRecord
 │    └─ 退化测量值 DegradationValue
 ├─ 制品记录 ProductRecord
 │    └─ 制品样本值 ProductSampleValue
 ├─ 生产计划 ProductionPlan
 └─ 状态日志 EquipmentStatusLog

基础配置
 ├─ 子系统 SubSystem → 部件 Part
 ├─ 故障来源 / 模式 / 原因
 ├─ 退化指标 DegradationMetric → 参数 DegradationParam
 └─ 制品参数 ProductParam → 产品参数配置 ProductParamConfig

试验数据
 ├─ 整机试验配置与记录
 └─ 部件试验配置与记录
~~~

### 6.2 配置化设计

项目不是把所有指标名称和阈值硬编码在页面中，而是通过退化指标用途、制品参数用途、阈值、理想值、极端值、权重等配置关联到计算逻辑。

这样做的作用是：

- 同一计算框架可以适配不同设备、部件、制品或参数；
- 原始数据和评价口径可以分别维护；
- 分析结果能够回溯到具体参数和数据来源；
- 新增指标时可优先通过配置扩展，而非重复复制页面逻辑。

---

## 7. 可验证性、当前边界与后续改进

### 7.1 已有的可靠性措施

代码与文档显示系统已具备：

- Pydantic 对接口输入输出的结构化约束；
- 数据不足、对象不存在、除数无效等条件判断；
- 数据库会话异常时的回滚逻辑；
- 威布尔分析失败时的接口错误提示；
- 演示案例数据和运行逻辑说明，用于复核数据来源、指标公式和展示结果；
- 从 Excel 同步基础信息的服务逻辑。

### 7.2 当前不应夸大的部分

- 尚未发现独立的后端自动化测试文件，因此不能表述为“已建立完善自动化测试体系”；
- 现有案例得分属于演示数据验证结果，不应表述为真实客户生产绩效；
- 未发现可靠性系统目录中的本地 Git 元数据，不能用提交历史证明每次改动的完整责任链；
- 是否已实际生产部署、服务具体组织或通过正式标准认证，当前材料不足以确认。

### 7.3 优先改进建议

1. 为 MTBF、威布尔可靠度、精度退化率、综合评分建立已知答案测试；
2. 为数据不足、时间顺序错误、单位异常、首值为零建立边界测试；
3. 增加统一的运行说明、数据字典、接口说明和版本记录；
4. 用 Git 管理后续每次 AI 辅助修改，保留需求、diff 和验证证据；
5. 在展示环境中保留一套可复现演示数据与预期结果。

---

## 8. 候选人的项目所有权与 AI 辅助边界

以下口径应以候选人实际经历为准，并作为后续面试准备重点：

- 候选人负责提出数控机床可靠性评价的业务需求，梳理故障、退化、试验和制品数据的输入输出关系；
- 候选人参与课题组加工可靠性专利评价方案的研发，并参与将三层指标体系、计算口径和权重汇总逻辑转化为软件功能；
- 候选人参与定义指标用途、评价口径、异常条件、页面流程和演示验收要求；
- AI 编程工具用于加速代码实现、调试、文档整理和迭代；
- 候选人应能够解释核心计算过程、审查改动范围，并通过数据案例验证结果。

推荐表达：

> 项目采用 AI 辅助开发。我围绕数控机床中试验证场景梳理可靠性与加工质量评价需求，参与定义数据字段、计算规则、异常条件和验收案例，并使用 AI 工具加速后端、前端和数据分析功能的实现与迭代。

涉及专利时推荐补充：

> 加工可靠性综合评价算法来源于课题组共同研发的专利方案，我参与了方案研发和软件实现；专利权归属不属于个人。

---

## 9. 面试时的三分钟讲解结构

1. **问题**：传统故障、过程监测和制品检测数据往往分散，无法直接形成设备加工可靠性结论。
2. **方案**：系统提供服役可靠性和加工可靠性两类分析；前者使用 MTBF、Weibull 等通用方法，后者按照课题组专利方案，对设备、辅助部分和制品三个层面的 13 个指标进行综合评价。
3. **实现**：前端负责数据采集和展示，FastAPI 接收请求并组织数据，计算层完成 Weibull 与指标计算，PostgreSQL 保存原始记录、配置和结果关联。
4. **结果**：用户不只得到一个总分，还能看到三层得分、单项指标、公式依据和缺口提示，从而定位问题在哪一层。
5. **所有权**：我参与课题组专利评价方案研发，并将其中的数据结构、计算过程和页面流程写入软件；项目使用 AI 辅助实现，我负责业务规则、数据口径、验收逻辑和迭代方向。

---

## 10. 审阅结论

该项目最适合突出“把工业测试数据做成可使用评价软件的能力”。后续压缩为简历时，应保留业务问题、两类分析、技术架构、配置化评价、结果可追溯和验收方式；删除过细的接口名、全部实体名和演示案例数值。
