This commit is contained in:
zxu 2026-03-07 22:31:55 +08:00
commit 4c7d6d1fe0
9 changed files with 866 additions and 0 deletions

View File

@ -0,0 +1,61 @@
# 3月份重点工作计划表
## 项目概述
- **项目名称**: 智能挂车AI-Box Demo开发
- **项目目标**: 验证智能挂车方案原型基于H100核心板实现端侧大模型推理
- **关键约束**: -40℃~85℃工作温度60×60mm尺寸50g重量
## 重点工作及目标
### 1. 需求分析与确认 (3/4-3/8)
- **目标**: 完成正式PRD文档并获得团队确认
- **负责人**: 猪小杰 (产品经理)
- **交付物**: 商用车AI-Box Demo产品需求规格书
- **成功标准**: 所有团队成员确认需求无歧义
### 2. 系统架构设计 (3/9-3/15)
- **目标**: 完成软件和硬件系统架构设计方案
- **负责人**: 孙大圣 (软件架构师) + 孙凯瑾 (硬件专家)
- **交付物**: 系统架构设计方案文档
- **成功标准**: 通过架构评审,满足所有技术约束
### 3. 核心功能开发 (3/16-3/29)
- **目标**: 完成SoC和MCU核心功能模块开发
- **负责人**: 季增超 (SoC工程师) + 刘彬彬 (MCU工程师)
- **交付物**: 核心功能代码 + 单元测试报告
- **成功标准**: 所有核心功能通过单元测试
### 4. 团队协作机制建立 (3/4-3/31)
- **目标**: 建立高效的团队协作流程
- **负责人**: 唐小僧 (项目经理)
- **交付物**:
- 团队分工表
- Defect管理规范
- 项目开发计划
- 沟通管理机制
- **成功标准**: 团队成员清楚职责,协作顺畅
### 5. 配置管理体系建设 (3/4-3/31)
- **目标**: 建立完整的配置管理流程
- **负责人**: 唐小僧 (项目经理)
- **交付物**:
- Gitea仓库结构
- 飞书文档管理规范
- 双轨配置管理策略
- **成功标准**: 所有成果物都有版本控制和备份
## 关键里程碑
- **3/8**: 需求确认完成
- **3/15**: 架构设计完成
- **3/29**: 核心开发完成
- **3/31**: 3月份目标达成评估
## 风险管理
- **技术风险**: 芯片兼容性问题 → 提前技术验证
- **进度风险**: 需求变更 → 建立变更控制流程
- **质量风险**: 极端环境稳定性 → 强化测试覆盖
## 资源需求
- **人力资源**: 开发工程师、测试工程师按计划到位
- **工具资源**: Gitea、飞书、todonow等工具正常使用
- **硬件资源**: H100核心板开发套件及时到位

View File

@ -0,0 +1,92 @@
# 智能挂车AI-Box项目配置管理规范
## 1. 总体配置策略
### 双轨存储原则
- **飞书云文档**: 主要设计文件、需求文档、项目管理资料
- **Gitea (47.253.94.217:3000/zxu/its-gen1)**:
- 源代码主要存储位置
- 设计文件备份位置
- 所有技术资产的版本控制
### 访问信息
- **Gitea地址**: http://47.253.94.217:3000
- **仓库名称**: zxu/its-gen1
- **账号**: zxu / zxu123456
## 2. 仓库目录结构
```
its-gen1/
├── docs/ # 文档目录
│ ├── specs/ # 需求规格文档(已存在)
│ ├── architecture/ # 系统架构文档(已存在)
│ ├── design/ # 详细设计文档
│ └── project/ # 项目管理文档
│ └── CONFIGURATION_MANAGEMENT.md
├── design/ # 设计文档备份(已存在)
├── src/ # 源代码目录(待创建)
│ ├── drivers/ # 驱动层代码
│ ├── framework/ # 框架层代码
│ ├── applications/ # 应用层代码
│ └── utils/ # 工具类代码
├── scripts/ # 构建和部署脚本(待创建)
├── configs/ # 配置文件(待创建)
└── README.md # 项目说明(已存在)
```
## 3. 提交规范
### 文件命名规范
- 文档: `功能名_版本号.md` 或使用现有命名规范
- 代码: 遵循各语言的命名规范
- 配置: `环境_功能.conf`
### 提交信息格式
```
[类型] 简要描述
详细说明(可选)
关联任务ID可选
```
类型包括: feat(新功能), fix(修复), docs(文档), style(格式), refactor(重构), test(测试), chore(构建)
## 4. 分支管理策略
### 主要分支
- **main**: 生产发布分支,受保护
- **develop**: 开发集成分支
- **feature/**: 功能开发分支
- **hotfix/**: 紧急修复分支
## 5. 角色职责
### 产品经理 (emb-system/猪小杰)
- 需求文档在飞书归档后同步备份到Gitea `/docs/specs/`
- 需求变更需同时更新两个位置
### 软件架构师 (emb-arch/孙大圣)
- 架构设计方案在飞书发布后备份到Gitea `/docs/architecture/`
- 提供详细的接口定义和模块说明
### 项目经理 (emb-pm/唐小僧)
- 维护配置管理规范
- 监督配置纪律执行
- 协调配置相关问题解决
### 开发团队
- 代码提交到对应src子目录
- 遵循分支管理和提交规范
- 及时更新相关设计文档
## 6. 同步机制
### 设计文档同步
- 飞书文档更新后24小时内同步到Gitea对应目录
- 以飞书为主版本Gitea为备份版本
### 代码提交
- 所有代码必须通过Pull Request流程
- 重要功能必须有对应的文档更新

View File

@ -0,0 +1,131 @@
# AI-Box项目Defect管理规范
## 1. 标签体系设计
### 1.1 按模块分类
- `mcu`: MCU软件相关问题
- `soc`: SoC软件相关问题
- `f1-npu`: Fellow 1 NPU芯片相关问题
- `power-management`: 电源管理模块问题
- `communication`: 通信协议和接口问题
### 1.2 按类型分类
- `bug`: 缺陷和错误
- `feature`: 新功能需求
- `enhancement`: 功能改进
- `documentation`: 文档相关
### 1.3 按严重程度分类
- `critical`: 系统崩溃、数据丢失等严重问题
- `high`: 主要功能不可用
- `medium`: 次要功能问题
- `low`: 界面优化、文案修正等
### 1.4 按状态分类
- `in-review`: 待评审
- `in-progress`: 开发中
- `testing`: 测试中
- `resolved`: 已解决
## 2. Issue模板
### 2.1 Defect报告模板
```
## 问题描述
[简要描述问题]
## 重现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]
## 环境信息
- 硬件平台: H100核心板
- 温度环境: [实际温度]
- 软件版本: [版本号]
## 预期结果
[期望的行为]
## 实际结果
[实际的行为]
## 附件
[截图、日志等]
```
### 2.2 Feature请求模板
```
## 业务价值
[说明此功能的业务价值]
## 功能描述
[详细功能描述]
## 技术方案
[建议的技术实现方案]
## 验收标准
- [标准1]
- [标准2]
- [标准3]
```
### 2.3 任务模板
```
## 任务描述
[任务详细描述]
## 负责人
[负责人姓名]
## 截止日期
[YYYY-MM-DD]
## 依赖关系
- [依赖任务1]
- [依赖任务2]
## 验收标准
[具体的验收标准]
```
## 3. 工作流程规范
### 3.1 Defect创建和分配流程
1. 任何人发现Defect都可以创建Issue
2. 项目经理根据模块标签分配给相应负责人
3. 负责人确认后更新状态为`in-progress`
### 3.2 状态转换规则
- `in-review``in-progress`: 负责人开始处理
- `in-progress``testing`: 开发完成,提交代码
- `testing``resolved`: 测试通过,问题解决
### 3.3 代码提交关联规范
- 提交信息必须包含Issue编号格式: `fix #123`
- 相关代码文件必须有适当的注释说明
### 3.4 评审和关闭标准
- Critical/High级别Defect必须经过代码评审
- 所有Defect必须有对应的测试用例
- 关闭前必须验证在极端环境(-40℃~85℃)下的稳定性
## 4. 团队协作要求
### 4.1 新成员培训
- 入职时必须学习本规范
- 第一个任务必须在导师指导下完成
### 4.2 日常维护
- 每日站会检查高优先级Defect状态
- 每周清理已解决的Issue
- 每月回顾Defect趋势优化开发流程
### 4.3 质量保证
- Critical Defect 24小时内响应
- High Defect 3天内解决
- Medium/Low Defect 在下一个里程碑前解决
---
**本规范自发布之日起生效,所有团队成员必须遵守。**

View File

@ -0,0 +1,122 @@
# AI-Box设计评审流程规范
## 1. 设计评审适用范围
### 必须进行正式设计评审的重要设计结果:
- **系统架构设计方案** (孙大圣负责)
- **产品需求规格书(PRD)** (猪小杰负责)
- **核心模块详细设计文档**
- **接口定义和协议规范**
- **电源管理策略设计**
- **安全性和可靠性设计方案**
### 可以简化评审的常规设计:
- **工具脚本和辅助程序**
- **非核心功能模块设计**
- **文档格式和排版调整**
## 2. 飞书审批流集成方案
### 2.1 审批流配置需求
由于当前飞书应用权限限制,需要申请以下审批流相关权限:
- `approval:approval_instance` - 审批实例管理
- `approval:approval_template` - 审批模板管理
### 2.2 临时审批流程(当前可用)
在获得完整审批权限前,采用以下临时流程:
#### 步骤1: 文档创建与初审
- 设计者在飞书云文档中创建设计文档
- 在文档开头添加 **【设计评审】** 标识
- @相关评审人员进行初步技术评审
#### 步骤2: 评审会议组织
- 在 **04 项目会议** 文件夹中创建评审会议
- 邀请所有相关干系人参加
- 会议议程包含:设计介绍、问题讨论、决策确认
#### 步骤3: 评审结果记录
- 在会议文档中记录评审结论
- 明确标注:**通过/有条件通过/不通过**
- 列出所有需要修改的问题项和负责人
#### 步骤4: 文档更新与确认
- 设计者根据评审意见修改文档
- 在文档修订历史中记录修改内容
- 评审人员确认修改后,在评论区回复 **【确认通过】**
### 2.3 正式审批流流程(权限开通后)
一旦获得审批流权限,将升级为正式审批流程:
#### 自动化审批触发
- 设计文档保存时自动触发审批流
- 系统自动识别文档类型并分配相应审批人
- 审批流包含:技术评审 → 架构评审 → 项目经理确认 → 最终批准
#### 审批状态跟踪
- 实时显示审批进度
- 超时自动提醒审批人
- 审批历史完整记录
## 3. 评审角色与职责
### 3.1 评审委员会组成
| 角色 | 人员 | 职责 |
|------|------|------|
| **技术评审员** | 孙大圣 | 技术可行性、架构合理性 |
| **产品评审员** | 猪小杰 | 需求符合度、用户体验 |
| **项目经理** | 唐小僧 | 进度影响、资源协调 |
| **质量保证** | 测试团队 | 可测试性、质量标准 |
### 3.2 评审标准
- **技术先进性**: 是否采用合适的技术方案
- **需求符合度**: 是否完全满足产品需求
- **可实施性**: 开发团队是否具备实施能力
- **可维护性**: 后续维护和扩展的便利性
- **风险可控性**: 技术风险是否在可接受范围内
## 4. 评审流程执行细节
### 4.1 评审准备
- **提前通知**: 评审前至少24小时通知评审人员
- **材料准备**: 提供完整的背景资料和参考文档
- **环境准备**: 确保演示环境和测试数据就绪
### 4.2 评审会议
- **时间控制**: 单次评审会议不超过2小时
- **议题聚焦**: 严格按照议程进行,避免偏离主题
- **记录完整**: 指定专人记录会议要点和决策
### 4.3 评审后续
- **问题跟踪**: 所有问题必须有明确的解决计划
- **状态更新**: 每周更新评审问题的解决进度
- **闭环验证**: 问题解决后必须进行验证确认
## 5. Gitea与飞书协同机制
### 5.1 双向同步规则
- **飞书为主**: 设计文档以飞书版本为准
- **Gitea备份**: 评审通过的最终版本必须同步到Gitea
- **版本对应**: 飞书文档版本号与Gitea提交哈希对应
### 5.2 同步时机
- **评审前**: 在飞书创建和编辑文档
- **评审后**: 评审通过24小时内同步到Gitea
- **重大变更**: 任何重大修改都需要重新评审
## 6. 应急处理机制
### 6.1 紧急设计决策
对于紧急情况下的设计决策:
- **快速通道**: 项目经理可授权临时决策
- **事后补审**: 72小时内必须补办正式评审
- **风险评估**: 必须记录决策的风险和应对措施
### 6.2 评审争议处理
当评审出现重大分歧时:
- **升级机制**: 提交给更高层级决策
- **专家咨询**: 邀请外部专家提供意见
- **原型验证**: 通过快速原型验证方案可行性
---
**本规范自发布之日起生效,所有重要设计结果必须遵循此评审流程。项目经理负责监督执行,并根据实际运行情况进行优化调整。**

View File

@ -0,0 +1,22 @@
# 智能挂车AI-Box详细项目开发计划
## 项目概述
开发商用车AI-Box Demo验证智能挂车方案原型。
## 关键里程碑
- **M1-需求确认**: 3/8 - 正式PRD文档
- **M2-架构完成**: 3/15 - 系统架构方案
- **M3-核心开发**: 3/29 - 核心功能模块
- **M4-集成测试**: 4/5 - 集成测试报告
- **M5-Demo交付**: 4/12 - AI-Box Demo
## 主要任务分配
- **猪小杰**: 需求定义和PRD管理
- **孙大圣**: 软件架构设计和实现
- **季增超**: SoC软件开发和测试
- **刘彬彬**: MCU软件开发和测试
- **丁海军**: MCU代码评审支持
- **孙凯瑾**: 硬件架构和系统设计
- **唐小僧**: 项目管理和协调
完整详细计划请参考飞书文档: https://feishu.cn/docx/LYvHd7ejUo2EDdxEsBKcZ17Snya

View File

@ -0,0 +1,156 @@
# 智能挂车AI-Box团队文化与开发规范
## 1. 新成员入门知识
### 1.1 必须了解的项目背景
- **项目目标**: 开发商用AI-Box Demo验证智能挂车方案原型
- **硬件平台**: H100核心板深明奥思Fellow 1芯片132TOPS算力
- **工作温度**: -40℃ ~ 85℃ 极端环境适应性要求
- **尺寸限制**: 60mm × 60mm重量50g的严格约束
### 1.2 核心配置工具
- **飞书云文档**: 需求文档、设计文档、项目管理资料主存储
- 共享文件夹: https://mcn7kggf4yn0.feishu.cn/drive/folder/ZICnfWaY7lc5Nrdh8qic9Y7Dnkb
- 主要目录: 01管理/02系统/04软件/05测试
- **Gitea代码仓库**: 源代码和设计文件备份
- 地址: http://47.253.94.217:3000/zxu/its-gen1
### 1.3 团队成员角色
- **产品经理**: 猪小杰 (emb-system) - 需求定义和PRD管理
- **软件架构师**: 孙大圣 (emb-arch) - 技术架构和设计方案
- **项目经理**: 唐小僧 (emb-pm) - 项目协调和进度管理
- **开发团队**: 功能开发和代码实现
- **测试团队**: 质量保证和验证测试
### 1.4 历史知识获取路径
1. **飞书共享文件夹**: 查看现有需求和设计文档
2. **Gitea仓库**: 查看代码历史和设计文件备份
3. **工作群消息**: 了解项目讨论和决策过程
4. **项目配置规范**: 阅读《项目配置目录结构和管理规范》
## 2. 开发流程规则与设计指导
### 2.1 双轨配置管理规则
- **设计文档**: 飞书为主Gitea为备份24小时内同步
- **源代码**: Gitea为主存储必须有完整版本控制
- **需求变更**: 必须同时更新飞书和Gitea两个位置
### 2.2 代码开发规范
- **分支策略**:
- main: 生产发布分支(受保护)
- develop: 开发集成分支
- feature/*: 功能开发分支
- **提交规范**:
- 格式: `[类型] 描述` (feat/fix/docs/style/refactor/test/chore)
- 关联任务ID和详细说明
- **代码评审**: 所有代码必须通过Pull Request评审才能合并
### 2.3 设计指导原则
- **极端环境适应性**: 所有设计必须考虑-40℃~85℃工作环境
- **资源优化**: 在60×60mm/50g限制下做极致优化
- **多框架兼容**: 支持TensorFlow/PyTorch/ONNX/OpenAI API
- **电源管理**: 实现四种电源模式(运行/待机/低功耗/关机)
- **实时性要求**: 大模型推理必须满足低时延需求
### 2.4 文档编写标准
- **格式**: Markdown为主便于版本控制
- **内容**: 必须包含接口定义、模块说明、使用示例
- **更新**: 代码变更必须同步更新相关文档
- **归档**: 按照Gitea目录结构规范存放
## 3. 详细开发计划与风险管理
### 3.1 项目里程碑计划
#### 第一阶段需求与架构1周
- **任务**: PRD确认 + 系统架构设计
- **负责人**: 猪小杰 + 孙大圣
- **交付物**: 正式PRD + 架构设计方案
- **风险管控**: 需求变更控制,架构评审
#### 第二阶段核心开发2周
- **任务**: 驱动层 + 框架层开发
- **负责人**: 开发团队 + 孙大圣
- **交付物**: 核心功能模块 + 单元测试
- **风险管控**: 技术难点攻关,代码质量保证
#### 第三阶段集成测试1周
- **任务**: 系统集成 + 端到端测试
- **负责人**: 开发团队 + 测试团队
- **交付物**: 集成测试报告 + Bug修复
- **风险管控**: 集成问题快速定位,回归测试
#### 第四阶段Demo交付1周
- **任务**: Demo优化 + 客户演示准备
- **负责人**: 全体团队
- **交付物**: AI-Box Demo + 演示文档
- **风险管控**: 演示稳定性,客户反馈处理
### 3.2 分工与职责矩阵
| 任务 | 产品经理 | 架构师 | 项目经理 | 开发 | 测试 |
|------|----------|--------|----------|------|------|
| 需求分析 | ✓ 主导 | ✓ 评审 | ✓ 协调 | | |
| 架构设计 | ✓ 评审 | ✓ 主导 | ✓ 协调 | | |
| 代码开发 | | ✓ 指导 | ✓ 跟踪 | ✓ 主导 | |
| 测试验证 | ✓ 验收 | ✓ 评审 | ✓ 协调 | ✓ 配合 | ✓ 主导 |
| 文档编写 | ✓ 需求 | ✓ 架构 | ✓ 计划 | ✓ 技术 | ✓ 测试 |
| 风险管理 | ✓ 识别 | ✓ 技术 | ✓ 全面 | ✓ 执行 | ✓ 质量 |
### 3.3 风险识别与应对策略
#### 技术风险
- **芯片兼容性问题**: 提前进行技术验证,准备备选方案
- **极端温度稳定性**: 增加环境测试,强化错误处理机制
- **性能不达标**: 优化算法,合理分配计算资源
#### 进度风险
- **需求变更频繁**: 建立变更控制流程,评估影响后再实施
- **人员技能不足**: 提供技术培训,安排经验丰富的开发者指导
- **外部依赖延迟**: 提前识别依赖项,制定应急计划
#### 质量风险
- **代码质量不高**: 严格执行代码评审,增加自动化测试
- **测试覆盖不足**: 制定详细的测试计划,确保关键路径覆盖
- **文档缺失**: 将文档作为交付物的一部分,纳入验收标准
### 3.4 进度管理机制
#### 日常机制
- **每日站会**: 上午9:3015分钟同步进展和阻塞问题
- **进度跟踪**: 使用飞书表格实时更新任务状态
- **问题升级**: 阻塞问题2小时内升级到项目经理
#### 周度机制
- **周计划评审**: 每周一制定本周详细计划
- **周进度汇报**: 每周五总结本周完成情况
- **风险评估**: 每周识别和评估新风险
#### 里程碑机制
- **里程碑评审**: 每个阶段结束进行正式评审
- **质量门禁**: 达到质量标准才能进入下一阶段
- **客户同步**: 重要里程碑向客户汇报进展
## 4. 团队协作文化
### 4.1 核心价值观
- **客户导向**: 始终以客户需求和体验为中心
- **技术卓越**: 追求高质量的技术实现和创新
- **透明沟通**: 信息及时共享,问题主动暴露
- **责任担当**: 对自己的工作负责,对团队目标负责
### 4.2 协作原则
- **尊重专业**: 充分信任各领域专家的专业判断
- **主动沟通**: 发现问题立即沟通,不等待问题恶化
- **互相支持**: 团队成员互相帮助,共同解决问题
- **持续改进**: 从每个任务中学习,不断优化流程
### 4.3 沟通规范
- **工作群**: 日常沟通和紧急问题
- **文档**: 正式决策和详细说明
- **会议**: 重要讨论和决策制定
- **一对一**: 敏感问题和深度技术讨论
---
**本规范自发布之日起生效,所有团队成员必须遵守。项目经理负责监督执行,并根据项目实际情况进行适时调整。**

View File

@ -0,0 +1,54 @@
# 商用车AI-Box系统需求规格说明书
## 1. 核心目标
### 1.1 低功耗设计
- **整机功耗**≤15W待验证
- **休眠功耗**≤2W
- **电源管理**:支持多级休眠模式(深度休眠/待机/工作)
### 1.2 国产化适配
- **主控芯片**瑞芯微RK3588/RK3568优先或华为昇腾310
- **操作系统**OpenHarmony 4.0+ 或 麒麟V10
- **AI框架**MindSpore Lite 或 Paddle Lite
### 1.3 高集成度
- **接口密度**单设备支持≥8路视频输入
- **扩展能力**预留CAN总线、4G/5G模组、GNSS接口
- **结构设计**IP67防护等级-40℃~85℃工作温度
## 2. 功能需求
### 2.1 视频处理
- 支持H.265/H.264编码
- 实时视频分析ADAS/DSM/DMS
- 事件触发录像(碰撞/急刹/车道偏离)
### 2.2 通信能力
- 4G/5G远程数据传输
- V2X通信预留DSRC/C-V2X接口
- 蓝牙/WiFi近场配置
### 2.3 数据存储
- 本地存储≥64GB eMMC
- 循环覆盖策略保留最近7天数据
- 加密存储国密SM4算法
## 3. 非功能需求
### 3.1 可靠性
- MTBF ≥50,000小时
- 抗振动符合ISO 16750-3标准
- 电磁兼容GB/T 18655 Class 3
### 3.2 环境适应性
- 工作温度:-40℃ ~ +85℃
- 存储温度:-40℃ ~ +95℃
- 湿度范围5%~95% RH无凝露
### 3.3 安全性
- 启动安全Secure Boot
- 运行安全TEE可信执行环境
- 数据安全国密SM2/SM9证书体系
## 4. 验证标准
- 符合JT/T 1076-2016《道路运输车辆卫星定位系统车载终端技术要求》
- 通过CCC认证及EMC测试
- 满足GB/T 28046.1-2019道路车辆电气电子环境要求

View File

@ -0,0 +1,155 @@
# 商用车AI-Box Demo - 产品需求规格书v2.0
**版本**v2.0
**日期**2026-03-04
**产品经理**:猪小杰
**项目经理**:徐工
**对接人**:孙凯瑾
---
## 1. 文档修订记录
| 时间 | 版本 | 作者 | 变更内容 |
|------|------|------|----------|
| 2026-03-04 | v1.0 | 猪小杰 | 初稿整合飞书需求、Gitea架构、IPCL通信、电源设计文档 |
| 2026-03-04 | v2.0 | 猪小杰 | **重大更新**移除F1本地大模型调整为云端API + Trailer Agent架构 |
## 2. 项目背景
### 2.1 产品目标
打造一款面向商用车场景的AI域控制器Demo聚焦**低功耗、低成本、高集成度、国产化适配**四大核心目标。
### 2.2 技术架构调整
- **原架构**MCU + SoC + F1本地大模型推理
- **新架构**MCU + SoC + 云端大模型API
- **核心组件**Trailer Agent挂车数据专家本地部署
- **协同模式**本地Trailer Agent与云端AI协同实现挂车本地化智能化管理
### 2.3 技术平台
- **核心芯片**SoC具体型号待确认
- **系统架构**双核异构MCU电源管理 + SoC逻辑控制
- **工作温度**-40℃ ~ 85℃
- **物理规格**60mm × 60mm50g
## 3. 功能需求
### 3.1 核心功能(优先级排序)
#### 🔴 P0 - 传感器数据融合(优先实现)
- **传感器接入**:支持多种传感器数据采集
- **数据融合**:多源传感器数据融合处理
- **云端上传**:将融合数据上传到云端服务器
- **展示接口**通过web和app展示数据结果
#### 🟡 P1 - 图像识别
- **摄像头接入**:连接摄像头,采集图像
- **物体识别**CNN模型识别物体类型
- **数据通路**演示传感器数据通路及CNN模型
#### 🟢 P2 - Trailer Agent挂车数据专家
- **本地部署**在AI-Box SoC上部署Trailer Agent
- **数据专家**:作为挂车领域数据专家,处理本地智能决策
- **云端协同**与云端大模型API协同工作
- **智能管理**:实现挂车的本地化智能化管理
#### 🔵 P3 - 云端大模型API集成
- **API接入**通过网络API调用云端大模型服务
- **数据同步**:与云端保持数据同步
- **智能增强**:利用云端大模型能力增强本地智能
### 3.2 系统服务
- **电源管理**:四级电源模式(运行/休眠/低功耗/关机)
- **健康监控**SoC状态监测异常自动复位
- **故障恢复**通信失效时GPIO强制复位
## 4. 系统架构
### 4.1 分层架构
```
┌─────────────────┐
│ 应用层 │ ← Trailer Agent、传感器融合、图像识别、云端API
├─────────────────┤
│ 框架层 │ ← 通信中间件、推理引擎、模型管理
├─────────────────┤
│ 驱动层 │ ← MCU电源管理、SoC Linux驱动
└─────────────────┘
```
### 4.2 芯片间通信
- **MCU ↔ SoC**SPI(10Mbps) + UART(1Mbps) + GPIO(复位)
- **SoC ↔ 云端**网络API4G/5G/WiFi/Ethernet
## 5. 通信协议规范
### 5.1 SPI通信协议
- **速率**≥10Mbps
- **包长**≤512字节
- **校验**CRC校验
- **命令类型**
- `0x01` POWER_MODE_REQ电源模式请求
- `0x02` POWER_MODE_ACK电源模式确认
- `0x03` DATA_TRANSFER数据传输
- `0x05` STATUS_REPORT状态报告
### 5.2 UART通信协议
- **速率**≥1Mbps
- **用途**SoC健康状态监测CPU/内存/外设状态)
- **超时机制**3个周期无响应 → GPIO强制复位
### 5.3 GPIO通信协议
- **信号**RESET_N低电平有效
- **持续时间**≥100ms
- **使用场景**SPI/UART失效、SoC无响应、严重故障
## 6. 电源管理策略
### 6.1 四级电源模式
| 模式 | SoC状态 | MCU状态 | 功耗 | 唤醒时间 |
|------|---------|---------|------|----------|
| 运行模式 | 全功率运行 | 正常监控 | ~10W | 0ms |
| 休眠模式 | 降频运行 | 正常监控 | ~2W | 100ms |
| 低功耗模式 | 深度睡眠 | 低功耗监控 | ~0.5W | 500ms |
| 关机模式 | 完全关闭 | 超低功耗 | ~0.1W | 2000ms |
### 6.2 唤醒源管理
- **最高优先级**:钥匙启动(关机模式唤醒)
- **高优先级**:远程唤醒(所有模式)
- **中优先级**:传感器触发(休眠/低功耗模式)
- **低优先级**:定时唤醒(休眠/低功耗模式)
## 7. 验收标准
### 7.1 功能验收
- [ ] 传感器数据融合:多源数据融合准确率 ≥ 95%
- [ ] 图像识别:物体识别准确率 ≥ 95%
- [ ] Trailer Agent本地智能决策响应时间 ≤ 100ms
- [ ] 云端API大模型API调用成功率 ≥ 99%
- [ ] 电源切换:四级模式切换成功率 100%
### 7.2 性能验收
- [ ] 工作温度:-40℃ ~ 85℃稳定运行
- [ ] 功耗指标:各模式功耗符合设计规格
- [ ] 通信可靠性SPI/UART误码率 ≤ 10⁻⁶
- [ ] 网络延迟云端API响应时间 ≤ 500ms
### 7.3 可靠性验收
- [ ] 故障恢复SoC异常复位时间 ≤ 3秒
- [ ] 环境测试通过高低温、振动、EMC车规级测试
## 8. 后续工作计划
- [ ] 3月10日前完成详细接口规范定义重点传感器融合接口
- [ ] 3月20日前驱动开发和调试MCU-SoC通信驱动
- [ ] 3月25日前Trailer Agent原型开发
- [ ] 3月30日前传感器数据融合功能实现
- [ ] 4月10日前云端API集成和端到端系统联调
---
> **备注**:本文档基于以下资料整合:
> 1. 《商用车AI-Box Demo开发需求》飞书文档v2.0
> 2. 《AI-Box智能终端IPCL设计文档》
> 3. 《AI-Box智能终端电源设计文档》
> 4. 客户最新需求澄清云端大模型API + Trailer Agent架构

View File

@ -0,0 +1,73 @@
# 智能挂车AI-Box团队成员分工表
## 团队角色与职责
### 真人成员
| 成员 | 角色 | 主要职责 | 协作方式 |
|------|------|----------|----------|
| 徐祖龙 | 产品线总监 | 总体管理,监控监督交付 | 决策审批,进度监督 |
| 孙凯瑾 | 硬件专家 | 系统架构和硬件设计 | 技术方案,硬件验证 |
| 季增超 | SoC软件工程师 | SoC软件设计和编码测试 | SoC开发集成测试 |
| 刘彬彬 | MCU软件工程师 | MCU软件设计和编码测试 | MCU开发电源管理 |
| 丁海军 | 软件工程师 | 评审和支持刘彬彬的开发工作 | 代码评审,技术支援 |
| 潘定海 | 研究院院长 | 代表公司和董事会进行技术决策 | 重大决策,技术方向 |
### AI Agent成员
| Agent | 角色 | 主要职责 | 协作方式 |
|-------|------|----------|----------|
| 唐小僧 (emb-pm) | 项目经理 | 项目交付管理,协调资源和分工,管控开发进度 | 项目协调,进度跟踪,风险管理 |
| 猪小杰 (emb-system) | 产品经理 | 产品定义和需求开发,回答需求问题 | 需求管理PRD编写需求澄清 |
| 孙大圣 (emb-arch) | 软件架构师 | 软件架构设计和实现 | 架构设计,技术方案,代码指导 |
## 协作机制
### 沟通渠道
- **飞书工作群**: 日常沟通和紧急问题 (chat_id: oc_429193eeffe847ff7bc2da2f062d640e)
- **Gitea Issues**: 任务跟踪和Defect管理
- **飞书文档**: 计划、规范和成果物归档
- **Agent-to-Agent**: AI agent间的技术讨论
### 工作流程
1. **需求阶段**: 猪小杰收集需求 → 徐祖龙确认 → 孙大圣架构设计
2. **开发阶段**: 季增超(SoC) + 刘彬彬(MCU)开发 → 丁海军评审支持
3. **测试阶段**: 全体参与集成测试 → 孙凯瑾硬件验证
4. **交付阶段**: 唐小僧协调Demo准备 → 潘定海技术决策
### 决策机制
- **技术决策**: 孙凯瑾(硬件) + 孙大圣(软件) + 相关工程师
- **需求决策**: 猪小杰 + 徐祖龙
- **项目决策**: 唐小僧 + 徐祖龙
- **重大决策**: 潘定海院长最终决定
## 关键协作原则
### 透明沟通
- 所有讨论和决策都要有记录
- 问题要及时暴露,不隐瞒
- 信息要在团队内充分共享
### 高效协作
- AI agent提供7x24执行能力
- 真人员工提供专业判断和深度技术能力
- 人机协同,发挥各自优势
### 质量保证
- 所有代码必须通过评审
- 所有设计必须通过评审
- 所有成果物必须及时归档
## 联系方式
### 飞书账号
- 所有AI agent都借用徐祖龙的飞书账号
- 真人员工使用各自的飞书账号
### 紧急联系
- **项目阻塞问题**: 立即联系唐小僧(项目经理)
- **需求问题**: 联系猪小杰(产品经理)
- **技术问题**: 联系孙大圣(架构师)或相关工程师
---
**本分工表自发布之日起生效,所有团队成员必须遵守。如有疑问,请及时与项目经理唐小僧沟通。**