项目统筹与系统集成负责人：角色定位
该角色负责维护系统边界、工作分解、接口基线、版本关系、集成计划与交付证据。其职责不是替代各专业负责人作出技术判断，而是确保每项判断具有明确负责人、输入来源、输出格式、验证方式和变更记录。
| 类别 | 内容 | 验收方式 |
|---|---|---|
| 输入 | 硬件接口表、模型数据契约、软件 API 与页面需求、实验计划、用户研究证据、竞赛规则 | 来源、版本、负责人和更新时间完整 |
| 输出 | 系统架构图、责任矩阵、接口登记表、里程碑、决策记录、风险清单、集成测试记录和最终成果索引 | 每项输出可追溯到原始文件和审查结论 |
| 责任边界 | 组织跨模块决策和验收，不代替建模负责人定义公式，不代替硬件负责人确认电气安全，不代替商业负责人形成用户结论 | 专业判断由对应负责人签署 |
| 关键协作 | 协调字段、单位、坐标系、时间戳、状态码、模型版本和实测/预测标识 | 端到端样例能够通过集成测试 |
预习成果与验收标准
工程团队协作的关键不是每个人都懂所有细节，而是每个人理解整体系统、清楚自己的输入输出，并能用文件和数据让其他人继续工作。
学习目标
- 能够用两分钟准确介绍 AeroGuard 的问题、边界、技术链与价值。
- 知道每个角色负责什么、需要谁提供输入、最终向谁交付。
- 能按统一命名、版本和审查流程管理数据、图纸、代码与报告。
- 理解试验使用清水、安全染色液和低压平台的基本安全边界。
- 完成开营评审所需的五类预习成果。
1. 核心知识：团队责任与系统接口
五人团队采用项目统筹、物理与实验、嵌入式硬件、产品与软件、商业与传播五类责任。每名成员理解系统全貌；每项交付设置唯一负责人和至少一名审查者。责任矩阵用于识别决策权、交付权和审查权，避免版本与完成标准无人确认。
| 角色 | 主要责任 | 需要的输入 | 核心输出 | 审查重点 |
|---|---|---|---|---|
| 项目统筹 | 问题定义、计划、接口、风险与最终叙事 | 各模块状态和证据 | 系统图、里程碑、决策记录、成果目录 | 边界是否一致，承诺是否有证据 |
| 物理与实验 | 模型定义、实验矩阵、标定、验证与误差 | 硬件测量能力、产品输出需求 | 模型文档、数据集、接口样例、验证报告 | 变量、单位、适用域与独立验证 |
| 嵌入式硬件 | 传感器、电路、PCB、RS485、泵阀控制与调试 | 模型输入、实验平台要求 | 图纸、BOM、固件、校准记录、设备协议 | 可靠性、安全状态、可维护性 |
| 产品与软件 | 后台数据链、Model Adapter、看板、回放与报告 | 设备接口、模型输入输出、用户任务 | 数据契约、API、PWA、测试、演示流程 | 数据来源标签、离线状态、可解释性 |
| 商业与传播 | 访谈、客户细分、竞争、价值验证与展示材料 | 技术边界、实验结果、产品原型 | 访谈证据、Lean Canvas、网站文案、路演材料 | 是否避免夸大，是否区分事实和假设 |
2. 开营前必须提交的预习成果
预习成果以“可审查”为要求，初稿允许存在待确认项。导师依据这些文件识别定义差异，不以完成页数评价学习质量。每份成果控制为一页或一个结构清晰的文件，并注明作者、日期、版本和状态。
| 成果编号 | 成果 | 最低内容 | 主责角色 |
|---|---|---|---|
| PRE-01 | 项目两分钟介绍 | 问题、对象、技术链、系统边界、验证方式和价值假设 | 全员，各自准备 |
| PRE-02 | 系统闭环图 | 采集、预处理、模型、平台、控制、验证及数据方向 | 项目统筹 |
| PRE-03 | 模型输入输出表 | 字段、单位、来源、频率、直接输出/平台输出和缺失处理 | 物理与软件共同 |
| PRE-04 | 硬件接口图 | 传感器、MCU、RS485、供电、阀驱动和安全状态 | 嵌入式硬件 |
| PRE-05 | 基础实验矩阵 | 研究问题、自变量、因变量、控制变量、重复和测量方法 | 物理与实验 |
| PRE-06 | 实时看板线框图 | 地图、遥测、风险、建议、时间轴以及数据来源标记 | 产品与软件 |
| PRE-07 | 商业验证画布 | 客户细分、痛点、替代、价值假设、访谈问题和商业风险 | 商业与传播 |
文件命名示例：PRE-03_model-interface_v0.1_2026-07-16.xlsx。版本 0.x 表示草案，1.0 表示经过团队审查并冻结的接口。修改冻结接口必须附变更原因和影响范围。
3. 三次嵌入式硬件加课安排
硬件学习不单独讲一套电子学百科，而是围绕 AeroGuard 控制板形成三次递进课程。每次建议 2 小时，包含讲解、读图、动手和可验收输出。
第一次：系统架构、传感器与测量链
从药液管路和模型输入开始，识别风速风向、温湿度、压力、流量、位置和阀状态的测量方式。比较模拟电压、4–20 mA、脉冲、I²C、UART 和 RS485。学生阅读至少两份真实数据手册，完成传感器接口清单和数据质量状态设计。
- 课堂动手：读取一个数字传感器和一个模拟/脉冲输入，观察采样波动与滤波效果。
- 输出：硬件系统框图、传感器选型表、校准计划。
- 验收：能解释每个传感器的数据如何进入模型，并用量程、精度、采样率和校准方法说明选型依据。
第二次：原理图与 PCB 设计
按电源、MCU、通信、模拟采集和执行器驱动分区阅读原理图。重点理解防反接、保险/限流、稳压、去耦、RS485 收发、电流采样、MOSFET 驱动与续流保护。随后在 EDA 工具中创建原理图、分配封装、进行 ERC，并完成 PCB 功能布局与 DRC。
- 课堂动手：画出 RS485 接口和单路电磁阀驱动，检查器件额定值与接口丝印。
- 输出：原理图 v0.1、PCB 功能分区、初始 BOM。
- 验收：能说明大电流回路、保护器件和调试点为什么这样放置。
第三次：RS485、Modbus RTU 与整机联调
连接主控、收发器和一个或多个工业传感器，设置地址和串口参数，读取寄存器并校验 CRC。随后把传感数据封装成统一 JSON，通过串口或网络送入后台。最后测试断线、错误地址、超时和传感器异常，确认系统不会把错误数据当成正常数值。
- 课堂动手：完成一次请求—响应抓包，并把寄存器原始值换算为工程单位。
- 输出：设备协议表、读取日志、故障测试记录、后台样例数据。
- 验收：实现“真实传感器→MCU→数据对象→看板”最小闭环。
4. 文件、代码和数据如何协作
项目仓库建议按 docs、hardware、firmware、backend、frontend、model、experiments 和 assets 分区。原始实验数据只追加、不覆盖；处理后的数据写明脚本版本；大文件与隐私信息遵守仓库规则。每项修改通过小型提交记录原因，不把“final_final_v3”当作版本管理。
建议的工作流
- 提出任务：写清目标、背景、约束和完成标准。
- 定义接口：在动手前确定输入、输出、单位和负责人。
- 小步实现：先完成最小可测试链路，再扩大范围。
- 交叉审查：输出者之外至少一人检查定义、证据和可复现性。
- 冻结版本：被其他模块依赖的接口标记版本并记录变更。
- 集成验证：使用真实样例从传感器或数据文件贯通到看板。
- 复盘：记录失败原因、未知问题和下一步，而不是只保存成功截图。
| 目录 | 内容 | 禁止做法 |
|---|---|---|
| docs/ | 系统、接口、决策和使用文档 | 复制多份互相冲突的同名文件 |
| hardware/ | 原理图、PCB、BOM、数据手册索引 | 只提交截图，不提交源文件 |
| firmware/ | 设备驱动、采集、协议和控制逻辑 | 在代码中散落未记录的校准常数 |
| model/ | 模型文档、参考实现、版本和测试样例 | 覆盖旧模型导致历史结果无法复现 |
| experiments/raw/ | 原始传感数据、图片和日志 | 手工修改原始值或删除失败实验 |
| experiments/processed/ | 清洗、转换和分析结果 | 没有脚本与参数说明的手工表格 |
| frontend/backend/ | 平台代码、测试和接口 | 前端硬编码虚假模型结果作为演示结论 |
5. 安全、伦理与合规边界
预习和基础实验使用清水或经导师批准的安全染色液，不使用真实农药。电路实验从低电压、限流电源开始，泵和阀使用防水接头并设置漏液托盘；通电前检查极性、短路和额定电流；旋转部件、压力管路和激光/高温设备不在本项目第一阶段范围内。
硬件安全
- 泵、阀和电源线按最大电流选择，首次通电使用限流。
- 液体区与裸露电路分开，断电后再调整管路。
- 压力测试设置上限与泄压方式，不堵死出口强行升压。
- 故障状态默认关闭阀和泵；云端或无线断开不影响本地停止。
数据与表达伦理
- 访谈前说明用途，个人信息最小化收集并去标识化。
- 失败实验、异常样本和不支持假设的结果也要保留。
- 预测图必须标记为预测，不能伪装为实测。
- 未经验证不得写“降低污染 X%”“节省农药 X%”或“符合所有法规”。
- 引用论文、法规、图片和数据时记录来源与访问日期。
无人机与农药
真实无人机飞行、购买、测试场地、植保作业和农药使用受到地区、设备与用途相关的规则约束。本手册不提供法律意见。任何实飞或施药必须由导师在实施前核查当地要求、场地许可、保险、原厂条款和安全方案。
6. 开营第一天如何评审预习成果
建议用 90 分钟完成评审，不做长篇汇报。每人两分钟介绍项目，再把五类成果铺在同一面墙或白板上。团队寻找定义冲突：风向含义是否一致、压力单位是否统一、模型和平台是否重复计算、看板是否区分预测与实测、商业价值是否超出技术证据。
| 评审项 | 通过标准 | 常见问题 |
|---|---|---|
| 问题定义 | 明确聚焦喷洒结果、质量和风险，不改写飞控 | 又回到航路自动修正或泛化环保平台 |
| 系统闭环 | 每个模块有输入输出和验证方式 | 硬件、模型、看板只是并列模块 |
| 模型接口 | 单位、坐标、版本和缺失处理清楚 | 只列 coverage、risk 等模糊名词 |
| 实验计划 | 变量可控、可重复、能产生验证数据 | 依赖真实无人机才能开始 |
| 产品页面 | 用户任务优先，实测与预测分层 | 漂亮但充满虚假 KPI |
| 商业假设 | 客户细分、替代和验证计划具体 | 把所有农户都当付费者 |
评审结束只冻结三件事：V1 系统边界、模型输入输出接口、第一轮实验研究问题。其他页面、商业模式和扩展功能保持可变。过早冻结全部方案会阻止团队根据证据调整。
7. 项目最终成果地图
AeroGuard 的最终成果不是一个软件演示，而是一组彼此支持的工程证据。硬件证明能可靠采集与控制；实验数据证明测量可复现；模型证明在明确范围内有预测能力；看板证明用户能理解和使用；商业研究证明所选客户场景值得继续投入。
8. 核心术语
| 术语 | 本项目中的含义 |
|---|---|
| Spray Deposition 喷雾沉积 | 液滴到达并留在指定表面或空间网格中的量或相对强度。 |
| Spray Drift 喷雾漂移 | 喷洒液滴在输送过程中偏离目标区域的运动与非目标沉积现象。 |
| Coverage 覆盖率 | 达到预定义沉积或剂量阈值的目标区域比例；必须说明阈值。 |
| Calibration 标定 | 利用已知标准或实验数据确定传感器/模型参数的过程。 |
| Validation 验证 | 使用未参与调参的数据检验模型表现。 |
| Ground Truth 实测真值 | 用于比较预测的实验测量结果；它也有测量误差。 |
| RS485 | 适合差分、多点通信的电气物理层，不规定寄存器含义。 |
| Modbus RTU | 常运行于串行链路上的主从请求—响应协议。 |
| Model Adapter | 把统一平台接口转换为具体模型调用，并统一返回格式的适配层。 |
| PWA | 可安装、可缓存基础资源并适配多设备的 Web 应用形式。 |
| Decision Support | 向用户提供依据与建议，不等同于自动接管飞控或安全决策。 |
| Traceability 可追溯性 | 从报告结论返回任务配置、模型版本、原始数据和处理过程的能力。 |
9. AeroGuard 中的应用与案例推演：接口单位与方向定义冲突
案例条件
压力传感器协议以 bar 输出数值，模型输入接口规定为 MPa；硬件文档将风向定义为“风来自的方向”，模型实现却按“风吹向的方向”计算。单模块测试均能返回数值，但端到端结果出现压力放大十倍、漂移方向旋转 180° 的系统性错误。
案例推演
- 冻结当前版本：暂停使用存在歧义的数据包，保存错误样例、模型版本和页面截图。
- 定位接口差异：对照传感器协议、数据契约和模型实现，确认单位与方向约定的冲突位置。
- 确定唯一标准：系统内部压力统一为 MPa；风向字段拆分为
wind_from_deg或wind_to_deg，禁止使用含义不明的wind_direction。 - 实施转换：转换集中在设备适配层，模型层只接收标准单位和标准坐标定义。
- 建立回归样例：加入已知压力和四个正交风向的固定测试数据，验证后台、模型和地图箭头的一致性。
- 记录变更：更新接口版本、影响模块、迁移说明和审查结论。
接口规范
| 接口对象 | 必须记录 | 变更触发条件 | 验证证据 |
|---|---|---|---|
| 字段定义 | 名称、类型、单位、方向、坐标系、允许范围 | 含义、单位或数据类型变化 | 接口样例与 schema 校验 |
| 版本关系 | 硬件协议、固件、模型、API、前端和实验数据版本 | 任一依赖项发布新基线 | 兼容矩阵与发布记录 |
| 异常状态 | 缺失、超量程、陈旧、未校准、模型超域和通信故障 | 新增故障模式或处理策略 | 故障注入测试记录 |
| 决策记录 | 问题、备选方案、选定方案、理由、负责人和日期 | 跨模块设计发生改变 | 审查签字或会议结论 |
| 集成测试 | 输入样例、预期结果、实际结果、容差和结论 | 接口、模型或适配层修改 | 自动测试与端到端日志 |
常见错误
- 接口表只列字段名称，没有单位、方向和坐标系。
- 通过口头消息修改冻结接口，没有更新版本与影响分析。
- 各模块分别进行隐式单位换算，导致同一字段被重复转换。
- 集成测试只验证页面出现数值，没有使用可预测结果的固定样例。
- 项目报告引用最新图表，但无法确定对应的模型和数据版本。
本章总结
系统集成的目标是使跨模块信息在传递后保持含义、单位、状态和版本一致。责任矩阵确定“谁作出判断”，接口基线确定“交付什么”，集成测试确定“交付是否一致”，变更记录确定“结论如何演进”。这四类机制共同构成 AeroGuard 的工程可追溯性。
10. 预习任务与完成标准
最终预习检查
- 完成 PRE-01 至 PRE-07，并放入团队统一目录。
- 每人录制或现场完成两分钟项目介绍，陈述问题、边界、接口和验证方法。
- 全员检查五个关键定义：风向、高度、流量、覆盖率、非目标沉积。
- 列出三项已知事实、三项待验证假设、三项当前版本不支持的功能。
- 建立一份接口登记表，至少覆盖硬件→后台、后台→模型、模型→平台三个接口。
- 准备一个当前证据尚不能回答的问题，作为开营第一轮讨论输入。
完成标准
团队能够从系统图追踪一条数据如何被测量、传输、建模、显示、验证并关联用户价值，同时能指出其中的假设、版本和限制；各角色提交物可通过接口登记表相互衔接。
自测题
- 为什么每项关键交付需要唯一负责人和独立审查者？
- 字段名称相同是否足以证明两个模块兼容？
- 模型接口冻结后，哪些变化必须触发版本更新？
- 集成测试为什么需要固定输入和明确容差？
- 报告中的一张风险热力图至少应追溯到哪些版本与数据？