python工业互联网应用实战2—从需求开始

前言：随着国家工业2025战略的推进，工业互联网发展将会提速，将迎来一个新的发展时期，越来越多的企业开始逐步的把产线自动化，去年年底投产的小米亦庄的智能工厂就是一个热议的新闻。小米/华为智能工厂只能说是中国制造2025的一个代表，产业转型和制造升级，笔者从事的企业领域就越到越来越多的（制造）企业开始悄悄的自动化/智能化。这里肯定有国家政策推动的大背景，同时，也有着企业自身不断提高生产率的“刚需”。

　　本序列我们也从一个需求问题开始；然后，拆解需求（问题）；其次，解决拆解需求（问题）的点；再次，通过的不断技术摸索和迭代过程找到一个个合理的解决需求的方法和手段，最终，完成了这个需求（问题）的项目实战。我们会在文中描述演化过程、方法论、过程保证机制和实用的工具等，最终带着大家完成这样一个实际项目需求的项目过程。项目涉及的Django的更多基础知识请大家阅读笔者早期的《Python开发入门与实战系列》。

　　本文的过程采用python3.6和django2.1版本

项目需求：这是一个简版物流自动化仓库实例，仓库控制系统（以下简称WCS）需要调度AGV小车运送一个实托盘（搬运单元）从1楼入库站台经由提升机搬运到2楼指定的仓库货位。 

1.需求分析

　　仓库控制系统（以下简称WCS）需要调度AGV小车运送一个实托盘（搬运单元）从1楼入库站台经由提升机搬运到2楼指定的仓库货位。这句简要描述常常是我们在项目URS看到的需求描述，接下来我们需要对拿到的需求进行分析，形成一个个可度量的开发功能点。

1.1.用例说明

　　需求用例说明文档能够很好的对需求进行详细的分析，主要的包含内容包括：前置条件、事件流程和后置条件（执行结果）用例描述如下表，通过用例分析我们能够很好的把握需求的具体事件执行流程，并通过文档清晰的描述出来，便于后期设计编码时作为开发设计人员的指导。

　　经过团队头脑风暴讨论，大家基本上达成了如下表的需求用例说明，我们把这个调度设备的搬运过程设计成一个序列顺序执行的步骤（子任务），这些子任务对应着设备的执行分解动作。

用例编码	1.1	执行角色	WCS
用例名称	托盘入库用例
前提条件	WMS已完成任务货位的分配，任务核心信息：托盘条码、源地址、目标地址； AGV不能跨楼层作业，1楼与2楼分别是不同的AGV小车执行任务；
需求描述	1 WCS分解搬运任务成3个设备作业； 2 调度AGV从入库站台搬运托盘到提升机1楼门口工位； 3 调度提升机到1楼并打开廊门； 4 调度AGV从提升机1楼门口工位到提升机并卸货，返回提升机门口工位； 5 调度提升机1楼提升到2楼并开门； 6 调度AGV进入提升机并载货搬运到2楼门口工位； 7 调度提升机关门； 8 调度AGV从2楼门口工位搬运到库存货位。
备选过程
扩展过程
原始需求描述	参见 《XXX URS》
特殊需求	无
后置条件	WCS调度相关设备完成实托盘从入库站台搬运到库存货位，反馈结果给WMS

2. 需求功能点

　　从上面的用例说明的需求描述事件流程来看，我们需要先把这一趟搬运任务分解成设备子任务，并串行的方式顺序下达到设备执行，任务清单如下表：

序号	作业描述	执行设备
1	调度AGV从入库站台搬运托盘到提升机1楼门口工位	1楼AGV
2	调度提升机到1楼并打开门	提升机
3	调度AGV从提升机1楼门口工位到提升机并卸货，返回提升机门口工位	1楼AGV
4	调度提升机1楼提升到2楼并开门	提升机
5	调度AGV进入提升机并载货搬运到2楼门口工位	2楼AGV
6	调度提升机关门	提升机
7	调度AGV从2楼门口工位搬运到库存货位	2楼AGV

　　也就是说这一趟搬运任务，WCS需要分解成7个设备作业子任务，并顺序下达给相应的执行设备执行，最终完成任务的执行（当前的任务划分粒度实际对接AGV和提升机厂家来说会有调整，最终以上步骤会依赖与实际对接的情况，但是主流程不会有太大变化）。 

 　　经过分析从1楼入库站台运送托盘到二楼某个指定货位这样一个任务，系统需要分解成7个子任务，下达给设备顺序执行。系统活动图如下：

3. 活动图

　　经过分析从1楼入库站台运送托盘到2楼某个指定货位这样一个任务，系统需要分解成7个子任务，下达给设备顺序执行。我们还可以通过UML活动图来进一步详细的描述作业的执行顺序如下图： 

  　　从图中我们可以看出来一次入库任务，系统分解为7个设备子任务（作业）来执行完整的托盘入库流程，只有所有子任务（作业）执行完成，托盘的入库才算完成。

 4. 功能模块

　　对于这样一个看似简单的需求来说，包含两大主要功能模块

1. 1. 任务分解：依据物理设备处理任务的条件，对任务进行分解，任务分解的粒度是设备能够识别并执行（动作）
   2. 任务调度：任务调度就是按照顺序执行的逻辑，把任务顺序和逐一下达给设备 

　　这里也有几个基本逻辑就是，设备在某一个时间点上只能执行一个子任务，只有这个任务执行完毕后方能下达新的子任务。多重任务逻辑只会导致设备无法完成任务（不知道到底该执行那个动作）。

 4.1. 实体关系

　　我们从上面需求分析整理当前至少包括2个实体，包含的属性（字段）如下： 

1任务：

任务ID，任务号，源地址（从哪儿），目标地址（到哪儿），开始时间，结束时间，状态 

2子任务：

子任务ID，任务ID，源地址(从哪儿 上一个子任务的目标地址）， 目标地址（到哪儿 下一个子任务的源地址）， 执行机构，开始时间，结束时间，状态

5. 小节

　　本章我们从一个需求问题开始，然后经过需求分析，把需求问题分解为功能点和数据实体，实体是下一步我们设计表或ORM model的基础原型，上面的实体只是一个初步的需求分析主要字段要求，实体属性（字段）会设计时会增加特定的其它属性（字段）。 下一章节我们将描绘如何把这个需求逐步演化到模型设计。