一、背景说明
1.1 研发背景
随着公司市场的不断扩展，项目部署上对自动门改造的需求越来越多。我们所有有自动门改造需求的项目均以非标项目导入，解决方案也因人员差异而略有不同。造成每个项目均需投入新的人力资源，形成新的开发工作量。同时自动门改造的项目特殊性，在制定方案阶段，需求信息采集困难。
同时客户对柔性物流整体解决方案的需求也越来越强烈。考虑到后期业务增长的需求，以及降低人力和沟通成本的需求。故有必要推出一款标准的自动门解决方案。
目前自动门改造过程中的主要问题和难点如下：
| 序号 | 问题说明 |
|---|---|
| 1 | 有自动门改造需求的项目越来越多，占用大量人力资源 |
| 2 | 自动门改造多为现场改造，实施方案在公司无法验证，问题也难以复现 |
| 3 | 实施现场多为客户车间，由于保密性要求，无法携带手机等通讯设备，沟通困难 |
| 4 | 自动门改造现场项目人员经常变动，自动门改造经验未有效共享，造成重复工作 |
| 5 | 项目实施需要我司、客户、自动门维保单位、自动门原厂技术人员等多方沟通确认。信息传递不及时，不准确，信息有偏差，沟通效率低下，沟通时间久 |
| 6 | 现场自动门改造人员多为非专业人员，出现异常无法及时给出解决方案，项目进度拖沓 |
| 7 | 项目导入后各方边界，需求信息不明确，项目进度难以把控 |
| 8 | 项目结束后无反馈，无复盘，问题未记录。没有形成后期可执行的经验 |
1.2 情景说明
在车辆部署现场，往往出现 AGV 需要通过自动门进入车间的情况。考虑到工厂自动化及降低人力成本，客户往往会提出新需求，即 AGV 在到达自动门区域时实现自主通过自动门。这样就要求我们 AGV 及中控系统需要与自动门控制器建立连接，实现自主开门和自主关门功能。
1.3 研发依据
根据以往自动门改造项目的改造需求、改造方案及项目需求，整理出市场上自动门主流的控制方式和客户自动门改造的普遍需求。并依据客户需求及方案，结合项目实际经验整理出一个通用性较高的标准方案。
可参考项目如下：
| 序号 | 项目名称 | 备注 |
|---|---|---|
| 1 | ||
| 2 |
1.4 研发目标
根据以往自动门改造经验，整理出一个通用性较高的标准方案，作为自动门改造的模板项目。并将相关资料有形化，实现零沟通，降低沟通成本。
尽可能整理出项目实施过程中可能出现的风险及其他可行性方案，并将相关资料有形化，作为项目实施的参考文件。
与软件部门协同设计，完成一套标准的中控程序开发。通过参数配置，实现不同方案的状态切换，减少中控系统开发工作量，降低资源投入。
在方案可行和风险可控的前提下，尽可能的降低 BOM 成本。
1.5 参与团队
由技术负责人统筹管理项目进度及计划，项目核心团队由开发团队和QA团队组成。
核心开发工作由电气工程师及软件工程师完成。QA团队负责项目方案的落地实施和执行，并通过方案执行过程及结果进行问题反馈，支撑开发团队进行方案迭代。
支撑团队协助开发团队及QA团队推进项目进度，保障项目落地交期。
二、设计方案
2.1 系统拓扑图
3.2 现场需求
- 客户现场搭载可满足项目需求的服务器
- 车辆部署区域需满足全区域局域网覆盖
- 自动门厂商可进行自动门改造，并提供相应的技术支持
- 自动门控制方式需满足我们改造方案的要求
3.3 交互信号
| 序号 | 信号名称 | 信号类型 | 信号收发 | 备注 | | —- | —- | —- | —- | —- | | 1 | 开门请求 | 持续 | AGV → 自动门 | AGV请求自动门开门的信号 | | 2 | 关门请求 | 持续 | AGV → 自动门 | AGV请求自动门关门的信号 | | 3 | 开门到位 | 持续 | 自动门 → AGV | 自动门开门到位后的反馈信号 | | 4 | 关门到位 | 持续 | 自动门 → AGV | 自动门关门到位后的反馈信号 |
3.4 动作流程
3.5 注意事项
3.5.1 必要条件
- ✅AGV 信号具有最高优先级
- ✅所有交互信号必须是保持信号
- ✅自动门不可以自动延时关门
- ✅所有交互信号缺一不可
3.5.2 建议条件
- ✅不建议人机混用
- ✅建议增加光栅保护
四、方案实施
五、风险分析
5.1 情况一
事故原因：1. AGV 信号不是最高优先级
2. 自动门自动延时关门
事故分析：在开门请求信号存在的情况下，延时时间到，自动门仍然关闭。
5.2 情况二
事故原因：1. AGV 信号不是最高优先级
2. 存在人机混用的情况
事故分析：在开门请求信号存在的情况下，手动按下关门按钮，自动门仍然关闭
若有收获，就点个赞吧
0 人点赞
