简介：这是一套面向计算机、自动化等专业学生与从业者的SPC产品质量在线分析系统C#完整源码，可直接用于毕业设计、期末课程设计或课程大作业，也可作为质量管理类桌面应用的入门参考。项目基于Visual Studio 2013与SQL Server 2012开发，内置admin/admin登录账号，功能覆盖员工、产品、车间、工序、设备等信息维护，以及分类搜索、控制图判异准则设置、测量数据备注与失控受理处理等模块，并实现Xbar-R、Xmedian-R、X-Rs、X控制图、直方图和Cpk图等统计过程控制图表。压缩包共165个文件，以79个png界面截图、36个cs源码、12个resx与12个resources资源文件为主，另含config配置、exe可执行文件、dll与sln解决方案等，整体约3.02MB，结构完整便于二次开发。该资源已有202人学习下载，评审分达95分且调试运行正常，读者可据此掌握SPC判异逻辑、控制图绘制与数据库交互的完整实现思路。
1. 从一张失控的质检报表说起：SPC 在线分析系统到底解决什么问题
车间里最常见的场景是这样的：早班交接时，质检员把一叠手写的测量记录交给工艺员，工艺员再敲进 Excel，等算出均值、极差、控制限，往往已经过去两三个小时。如果这批产品其实在上午十点就已经开始偏移，等报表出来时，可能已经堆了几百件超差品。基于 SPC 的产品质量在线分析系统要干的事，就是把这段延迟压到秒级——测量数据一进系统，控制图立刻更新，判异规则实时触发，异常在变成批量废品之前就被拦下来。
这个标题里几个词各有分量。SPC 是统计过程控制，核心不是画图，而是用控制限区分「正常波动」和「异常波动」；在线意味着数据采集、计算、判异、报警形成闭环，而不是事后补录；C# 完整源码说明这是一套可编译、可二次开发的桌面或服务端程序，常见形态是 WinForm/WPF 上位机加数据库，对接量具、PLC 或扭矩枪这类采集源。适合谁看？做计算机毕业设计想找一个有真实业务逻辑、能讲清楚算法又不太虚的题目的人；工厂里想自己搭一套轻量质检看板的设备或工艺工程师；以及刚学完c#入门、想找一个完整项目练手的开发者。它不追求大而全的 MES，而是把 SPC 这一件事做透。
2. 拆解 SPC 在线分析系统的技术骨架：从采集到判异的数据流
2.1 为什么选 C# 做上位机而不是脚本语言
工业现场的上位机软件，选型时绕不开三个现实约束：要能稳定对接串口、网口、OPC、数据库，要能长时间运行不崩，要能打包成一个双击就能跑的 exe 交给产线。C# 在这三点上都很顺手。.NET 的System.IO.Ports处理串口、System.Net.Sockets处理 TCP、System.Data.SqlClient或 EF Core 处理数据库，都是成熟方案；WinForm/WPF 做界面，工艺员上手成本低。相比之下，Python 写采集脚本快，但打包成独立 exe 体积大、依赖多，产线电脑装环境容易翻车；C++ 性能好但开发效率低，毕业设计周期内很难既做界面又做算法。
另一个常被忽略的点是c#上位机生态里现成的工业控件和通信库很多，比如做扭矩采集时对接c#读power focus 6000扭矩值这类设备，厂商通常提供 .NET 的 SDK 或示例，直接调用比从零写协议解析省事得多。所以这套系统的技术栈我一般会定成：C# + WinForm（或 WPF）+ SQLite/SQL Server + 自研 SPC 计算模块。数据库选 SQLite 适合单机部署和毕业设计演示，选 SQL Server 适合多工位联网。
2.2 数据模型：一张测量表要存哪些字段
SPC 系统的地基是数据表设计。很多同学一上来就建一张大宽表，结果做控制图时发现分组、子组、时间戳全乱。正确的做法是按「产品-特性-子组-测量值」四层建模。下面是最小可用的建表脚本，用 SQLite 语法，SQL Server 稍作类型调整即可。
-- 产品表：一个产品有多个质量特性 CREATE TABLE Product ( ProductId INTEGER PRIMARY KEY AUTOINCREMENT, ProductCode TEXT NOT NULL UNIQUE, -- 产品编号，如 "AX-2024" ProductName TEXT NOT NULL ); -- 质量特性表：每个特性对应一张控制图 CREATE TABLE Characteristic ( CharId INTEGER PRIMARY KEY AUTOINCREMENT, ProductId INTEGER NOT NULL, CharName TEXT NOT NULL, -- 如 "外径" USL REAL, -- 上规格限 LSL REAL, -- 下规格限 Target REAL, -- 目标值 SubgroupSize INTEGER DEFAULT 5, -- 子组大小 n FOREIGN KEY (ProductId) REFERENCES Product(ProductId) ); -- 测量明细表：每条记录是一次测量 CREATE TABLE Measurement ( MeasId INTEGER PRIMARY KEY AUTOINCREMENT, CharId INTEGER NOT NULL, SubgroupNo INTEGER NOT NULL, -- 子组序号，同组共享 MeasValue REAL NOT NULL, MeasTime TEXT NOT NULL, -- ISO8601 时间戳 Operator TEXT, FOREIGN KEY (CharId) REFERENCES Characteristic(CharId) ); -- 控制图参数表：缓存当前控制限，避免每次重算 CREATE TABLE ControlLimit ( CharId INTEGER PRIMARY KEY, XbarUCL REAL, XbarLCL REAL, XbarCL REAL, RUCL REAL, RLCL REAL, RCL REAL, CalcTime TEXT, FOREIGN KEY (CharId) REFERENCES Characteristic(CharId) );逻辑说明：SubgroupSize决定子组大小，Xbar-R 图常用 4~5，Xbar-S 图用 10 以上。SubgroupNo是关键字段，同一子组的多条测量共享同一个编号，计算均值时按它分组。ControlLimit表做缓存是因为控制限在数据量稳定后不需要每次刷新，实时判异时直接读缓存能省掉大量重复计算。参数上，USL/LSL是客户规格限，和后面算出来的控制限 UCL/LCL 是两回事，新手最容易把这两个概念混在一起——规格限是「产品合不合格」，控制限是「过程稳不稳定」，判异只看控制限。
2.3 采集层：串口、TCP 和文件三种接入方式
在线系统的「在线」体现在采集。常见接入方式有三种，按现场条件选：
| 接入方式 | 适用场景 | C# 关键类 | 注意点 |
|---|---|---|---|
| 串口 | 卡尺、千分尺、老式量具 | SerialPort | 波特率/校验位要和量具一致 |
| TCP | 扭矩枪、PLC、智能仪表 | TcpClient | 注意粘包，要按协议分帧 |
| 文件/数据库 | 已有系统导出、离线补录 | FileSystemWatcher | 注意文件占用和编码 |
串口采集的最小实现如下，重点是开一个后台线程持续读，读到完整帧再解析，不要在主线程里ReadLine阻塞界面。
private SerialPort _port; private void StartSerial(string portName, int baud) { _port = new SerialPort(portName, baud, Parity.None, 8, StopBits.One); _port.DataReceived += OnDataReceived; // 事件在后台线程触发 _port.Open(); } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { try { string line = _port.ReadLine(); // 假设量具以换行结尾 if (double.TryParse(line.Trim(), out double value)) { // 交给业务层，注意跨线程更新 UI 要用 Invoke _buffer.Enqueue(new MeasRecord { Value = value, Time = DateTime.Now }); } } catch (TimeoutException) { /* 读超时忽略，继续等下一帧 */ } }参数说明：baud必须和量具手册一致，常见 9600 或 19200；ReadLine依赖设备发送换行符，如果设备是定长帧，要改用Read配合字节计数。DataReceived在非 UI 线程触发，直接更新控件会抛跨线程异常，这是新手第一个必踩的坑。TCP 接入时，TcpClient的NetworkStream是字节流，一次Read可能拿到半帧或多帧，必须自己维护缓冲区按协议头尾切分，不能假设一次读到一条完整数据。
3. 把控制图算对：Xbar-R 的公式、代码与三个必调参数
3.1 Xbar-R 控制限的计算逻辑
控制图种类很多，计量型数据最常用的是 Xbar-R（均值-极差）图。它的思路是：子组内变异用极差 R 衡量，子组间变异用均值 Xbar 衡量，分别对两者设控制限。公式不复杂，但系数容易记错。
设子组大小 n，第 i 个子组的均值为 Xbar_i，极差为 R_i，共 k 个子组：
- 总均值 Xbar̄ = (Σ Xbar_i) / k
- 平均极差 R̄ = (Σ R_i) / k
- Xbar 图控制限：UCL = Xbar̄ + A2·R̄，LCL = Xbar̄ − A2·R̄
- R 图控制限：UCL = D4·R̄，LCL = D3·R̄
A2、D3、D4 是随 n 变化的常数，n=5 时 A2=0.577、D3=0、D4=2.114。这些系数必须查表，不能自己推。下面用 C# 实现核心计算。
// 控制图常数表：n -> (A2, D3, D4) private static readonly Dictionary<int, (double A2, double D3, double D4)> Coef = new Dictionary<int, (double, double, double)> { {2, (1.880, 0, 3.267)}, {3, (1.023, 0, 2.574)}, {4, (0.729, 0, 2.282)}, {5, (0.577, 0, 2.114)}, {6, (0.483, 0, 2.004)}, {7, (0.419, 0.076, 1.924)}, {8, (0.373, 0.136, 1.864)}, {9, (0.337, 0.184, 1.816)}, {10,(0.308, 0.223, 1.777)} }; public ControlLimit CalcXbarR(List<double[]> subgroups) { int n = subgroups[0].Length; var (a2, d3, d4) = Coef[n]; double xbarBar = subgroups.Average(g => g.Average()); double rBar = subgroups.Average(g => g.Max() - g.Min()); return new ControlLimit { XbarCL = xbarBar, XbarUCL = xbarBar + a2 * rBar, XbarLCL = xbarBar - a2 * rBar, RCL = rBar, RUCL = d4 * rBar, RLCL = d3 * rBar }; }逻辑说明：subgroups是已经按SubgroupNo分好组的二维结构，每组长度必须等于 n，否则系数取错、控制限全废。xbarBar用所有子组均值的平均，不是所有测量值的平均——当各子组大小相等时两者相等，但子组大小不等时结果不同，SPC 标准做法要求子组大小一致。参数上，n 必须落在系数表范围内，n=1 时不能用 Xbar-R 图，要改用单值-移动极差（I-MR）图，这是选型边界。
3.2 判异规则：八条准则里哪几条必须实现
控制图画出控制限只是第一步，真正报警靠判异准则。国标和 AIAG 手册里列了八条，实际系统里我建议至少实现前四条，因为后四条对数据量要求高、误报也多。
| 准则 | 含义 | 实现难度 | 建议 |
|---|---|---|---|
| 1 | 1 点超出 A 区（超控制限） | 低 | 必做 |
| 2 | 连续 9 点在中心线同侧 | 低 | 必做 |
| 3 | 连续 6 点递增或递减 | 低 | 必做 |
| 4 | 连续 14 点上下交替 | 中 | 建议做 |
| 5 | 连续 3 点中 2 点在 A 区或以外 | 中 | 选做 |
| 6 | 连续 5 点中 4 点在 B 区或以外 | 中 | 选做 |
| 7 | 连续 15 点在 C 区以内 | 中 | 选做 |
| 8 | 连续 8 点在中心线两侧但无人在 C 区 | 高 | 选做 |
准则 1 的实现最简单，遍历每个点判断是否越界。准则 2 和 3 需要滑动窗口，写一个通用窗口检查函数即可。下面给出准则 2 的实现，其余同理。
// 判断最近 9 点是否都在中心线同侧 public bool Rule2_Shift(List<double> values, double cl, int window = 9) { if (values.Count < window) return false; var recent = values.Skip(values.Count - window).ToList(); return recent.All(v => v > cl) || recent.All(v => v < cl); }参数说明：window默认 9，是准则 2 的标准值，不要随意改小，改小会显著增加误报。cl传中心线值。注意判异要基于「当前最新点」触发，即每次新数据进来后检查以它为结尾的窗口，而不是全量重扫，否则同一异常会反复报警。实际系统里我会给每条准则加一个「报警冷却时间」，比如同一特性 5 分钟内只报一次，避免产线被刷屏。
3.3 过程能力指数 Cp/Cpk 的在线计算
控制图看稳定性，过程能力指数看满足规格的能力。Cp 衡量潜在能力，Cpk 衡量实际能力，公式：
- Cp = (USL − LSL) / (6σ)
- Cpk = min((USL − Xbar̄) / (3σ), (Xbar̄ − LSL) / (3σ))
σ 的估计用 R̄/d2，d2 也是随 n 变化的常数，n=5 时 d2=2.326。在线计算时要注意：Cp/Cpk 只有在过程受控（控制图无异常）时才有意义，如果过程本身在漂移，算出来的 Cpk 是假的。所以系统里我会把 Cpk 显示和判异状态绑定，有未处理异常时 Cpk 标灰并提示「过程未受控，能力指数仅供参考」。这个细节在毕业设计答辩时是加分项，因为它体现了对 SPC 逻辑的理解，而不只是套公式。
4. 避坑与排查：这套系统上线后最容易翻车的五个地方
4.1 现象：控制图一打开就满屏红点
原因：把规格限 USL/LSL 当成了控制限 UCL/LCL 来判异。规格限通常比控制限宽，用规格限判异会漏报；反过来如果误把控制限当规格限，又会把正常波动判成超差。更隐蔽的情况是子组划分错误，比如把不同班次、不同设备的数据混进同一个子组，导致组内变异被人为放大，控制限算得过宽。
解决：在Characteristic表里明确区分规格限和控制限字段，界面上用不同颜色标注。子组划分要绑定「班次+设备+时间窗」三个维度，采集时自动打标签，不要靠人工事后分组。上线前用一批已知稳定的历史数据验证控制限，看是否和历史结论一致。
4.2 现象：数据明明在采集，界面就是不刷新
原因：跨线程更新 UI。串口或 TCP 的接收回调在后台线程执行，直接给TextBox.Text或DataGridView.DataSource赋值，WinForm 会抛InvalidOperationException，但异常常被吞掉，表现为「没反应」。另一个原因是DataReceived事件里做了耗时计算，阻塞了后续数据接收。
解决：所有 UI 更新走Control.Invoke或BeginInvoke，把计算和界面分离，接收线程只负责入队，另起一个消费线程或定时器做计算和刷新。下面是一个安全的更新封装。
private void SafeUpdate(Action action) { if (this.InvokeRequired) this.BeginInvoke(action); // 异步，不阻塞采集线程 else action(); } // 调用：SafeUpdate(() => chart1.Series[0].Points.AddY(value));4.3 现象：控制限每次刷新都在变，图看起来在「漂移」
原因：每次新数据进来都全量重算控制限，导致控制限随数据滚动。SPC 的标准做法是控制限一旦建立就固定，除非过程发生已知的永久性变化（如换料、换模）才重新计算。滚动重算会让判异失去基准，异常永远追不上。
解决：控制限分两阶段。第一阶段（试运行）用 20~25 个子组建立初始控制限，存入ControlLimit表；第二阶段（受控运行）控制限冻结，只做判异不做重算。需要重算时由工艺员手动触发，并记录重算原因和时间。这个「控制限冻结」机制是很多自制系统忽略的关键点。
4.4 现象：Cpk 算出来 2.0 以上，但客户投诉不断
原因：σ 的估计方法用错。有人直接用所有测量值的标准差，而不是用 R̄/d2 或 S̄/c4 估计。当过程存在特殊原因波动时，整体标准差会被放大，Cpk 反而偏小；反过来如果数据是挑选过的「好数据」，整体标准差偏小，Cpk 虚高。另外，Cpk 计算前没有确认过程受控，也是常见错误。
解决：统一用组内变异估计 σ，即 R̄/d2（Xbar-R 图）或 S̄/c4（Xbar-S 图）。计算前先跑判异，有异常先处理异常，再谈能力。界面上把「过程受控」作为 Cpk 显示的前置条件。
4.5 现象：数据库越跑越慢，几个月后查询要等十几秒
原因：Measurement表只增不删，没有索引，判异时又频繁按CharId + SubgroupNo查询。数据量到百万级后，全表扫描拖垮性能。另一个原因是每次判异都从数据库拉全量历史，而不是只拉最近窗口。
解决：在Measurement表的(CharId, SubgroupNo)上建复合索引；判异只查最近 N 个子组（N 取判异窗口最大值加缓冲，比如 30）；历史数据按时间分区或定期归档到历史表。如果用的是 SQLite，注意它写操作会锁库，采集写入和查询要错开或用 WAL 模式。
5. 让系统真正好用：实时报警推送与二次开发接口
5.1 报警不能只靠界面变红
产线工人不会一直盯着屏幕，报警必须主动推送。最轻量的做法是本地声音加弹窗，进阶做法是推送到车间看板或企业微信/钉钉机器人。C# 里发 HTTP 请求很简单，下面是一个推送到 webhook 的最小实现，注意异常要吞掉，不能因为推送失败影响主流程。
private static readonly HttpClient _http = new HttpClient(); public async Task PushAlarm(string charName, string rule, double value) { try { var payload = new { msgtype = "text", text = new { content = $"SPC报警：{charName} 触发{rule}，当前值 {value:F3}" } }; var json = JsonSerializer.Serialize(payload); await _http.PostAsync("https://your-webhook-url", new StringContent(json, Encoding.UTF8, "application/json")); } catch (Exception ex) { // 推送失败只记日志，不影响判异主流程 Log.Warn($"报警推送失败: {ex.Message}"); } }参数说明：webhook 地址按实际平台填，请求体格式各平台不同，这里用通用的 text 类型。HttpClient要静态复用，不要每次 new，否则连接池耗尽。推送频率要限流，同一特性同一准则在冷却期内不重复推。
5.2 留出二次开发接口，别把逻辑焊死在界面里
毕业设计常见的问题是所有逻辑写在 Form 的按钮事件里，想换个控制图类型就得改界面代码。正确做法是把 SPC 计算、判异、采集都抽成独立的类库，界面只做展示和调用。这样后续想加 Xbar-S 图、加新的判异准则、换数据库，都只动类库不动界面。我一般会定义这样的接口：
public interface IControlChart { string ChartType { get; } // "Xbar-R" / "Xbar-S" / "I-MR" ControlLimit Calculate(List<double[]> subgroups); List<Alarm> Judge(List<double> points, ControlLimit limit); } public interface IDataCollector { event Action<MeasRecord> OnDataReceived; void Start(); void Stop(); }有了这层抽象，采集层可以今天用串口、明天换 TCP，控制图可以今天用 Xbar-R、明天加 Xbar-S，互不影响。这也是这套源码值得二次开发的价值所在——它不是一次性演示，而是一个能长大的骨架。
5.3 验证系统算得对不对：三个自检方法
写完不能只看界面好看，要验证算法。第一，用手算数据对拍：取 25 个子组、n=5 的标准数据集，手算 Xbar̄、R̄、UCL、LCL，和程序输出比对，误差应在小数点后三位内。第二，用已知判异案例测试：构造一组「连续 9 点同侧」的数据，看系统是否准确触发准则 2，且不误触发其他准则。第三，做边界测试：子组大小 n=1、n=11（超出系数表）、数据量不足 25 组时，系统应给出明确提示而不是崩溃或算出错误控制限。
我自己的习惯是，每加一条判异准则，就先写一组能触发它的最小数据做单元测试，跑通了再接进主流程。血泪经验是，判异逻辑的 bug 往往不是算错，而是窗口边界处理错——比如数据刚好 9 个点时该不该触发、最新点算不算在窗口内，这些边界不测，上线后就是玄学报警。这套系统值不值得做？如果你需要一个能讲清楚统计原理、又能真实跑起来的项目，它比增删改查的管理系统有含量得多。希望帮到你。
本文还有配套的精品资源，点击获取
)
