python⼯业互联⽹应⽤实战2—从需求开始
前⾔：随着国家⼯业2025战略的推进，⼯业互联⽹发展将会提速，将迎来⼀个新的发展时期，越来越多的企业开始逐步的把产线⾃动化，去年年底投产的⼩⽶亦庄的智能⼯⼚就是⼀个热议的新闻。⼩⽶/华为智能⼯⼚只能说是中国制造2025的⼀个代表，产业转型和制造升级，笔者从事的企业领域就越到越来越多的（制造）企业开始悄悄的⾃动化/智能化。这⾥肯定有国家推动的⼤背景，同时，也有着企业⾃⾝不断提⾼⽣产率的“刚需”。
本序列我们也从⼀个需求问题开始；然后，拆解需求（问题）；其次，解决拆解需求（问题）的点；再次，通过的不断技术摸索和迭代过程找到⼀个个合理的解决需求的⽅法和⼿段，最终，完成了这个需求（问题）的项⽬实战。我们会在⽂中描述演化过程、⽅、过程保证机制和实⽤的⼯具等，最终带着⼤家完成这样⼀个实际项⽬需求的项⽬过程。项⽬涉及的Django的更多基础知识请⼤家阅读笔者早期的《系列》。 本⽂的过程采⽤python3.6和django2.1版本
项⽬需求：这是⼀个简版物流⾃动化仓库实例，仓库控制系统（以下简称WCS）需要调度AGV⼩车运送⼀个实托盘（搬运单元）从1楼⼊库站台经由提升机搬运到2楼指定的仓库货位。
1.需求分析
仓库控制系统（以下简称WCS）需要调度AGV⼩车运送⼀个实托盘（搬运单元）从1楼⼊库站台经由提升机搬运到2楼指定的仓库货位。这句简要描述常常是我们在项⽬URS看到的需求描述，接下来我们需要对拿到的需求进⾏分析，形成⼀个个可度量的开发功能点。1.1.⽤例说明
需求⽤例说明⽂档能够很好的对需求进⾏详细的分析，主要的包含内容包括：前置条件、事件流程和后置条件（执⾏结果）⽤例描述如下表，通过⽤例分析我们能够很好的把握需求的具体事件执⾏流程，并通过⽂档清晰的描述出来，便于后期设计编码时作为开发设计⼈员的指导。
经过团队头脑风暴讨论，⼤家基本上达成了如下表的需求⽤例说明，我们把这个调度设备的搬运过程设计成⼀个序列顺序执⾏的步骤（⼦任务），这些⼦任务对应着设备的执⾏分解动作。⽤例编码⽤例名称
1.1
托盘⼊库⽤例
1. WMS已完成任务货位的分配，任务核⼼信息：托盘条码、源地址、⽬标地址；2. 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
前提条件
原始需求描述特殊需求
后置条件WCS调度相关设备完成实托盘从⼊库站台搬运到库存货位，反馈结果给WMS
2. 需求功能点
从上⾯的⽤例说明的需求描述事件流程来看，我们需要先把这⼀趟搬运任务分解成设备⼦任务，并串⾏的⽅式顺序下达到设备执⾏，任务清单如下表：
序号123
作业描述
调度AGV从⼊库站台搬运托盘到提升机1楼门⼝⼯位调度提升机到1楼并打开门
调度AGV从提升机1楼门⼝⼯位到提升机并卸货，返回提升机门⼝⼯位
1楼AGV提升机1楼AGV
执⾏设备
34567
调度AGV从提升机1楼门⼝⼯位到提升机并卸货，返回提升机门⼝⼯位调度提升机1楼提升到2楼并开门
调度AGV进⼊提升机并载货搬运到2楼门⼝⼯位调度提升机关门
调度AGV从2楼门⼝⼯位搬运到库存货位
1楼AGV提升机2楼AGV提升机2楼AGV
也就是说这⼀趟搬运任务，WCS需要分解成7个设备作业⼦任务，并顺序下达给相应的执⾏设备执⾏，最终完成任务的执⾏（当前的任务划分粒度实际对接AGV和提升机⼚家来说会有调整，最终以上步骤会依赖与实际对接的情况，但是主流程不会有太⼤变化）。
经过分析从1楼⼊库站台运送托盘到⼆楼某个指定货位这样⼀个任务，系统需要分解成7个⼦任务，下达给设备顺序执⾏。系统活动图如下：
3. 活动图
经过分析从1楼⼊库站台运送托盘到2楼某个指定货位这样⼀个任务，系统需要分解成7个⼦任务，下达给设备顺序执⾏。我们还可以通过UML活动图来进⼀步详细的描述作业的执⾏顺序如下图：
从图中我们可以看出来⼀次⼊库任务，系统分解为7个设备⼦任务（作业）来执⾏完整的托盘⼊库流程，只有所有⼦任务（作业）执⾏完成，托盘的⼊库才算完成。
4. 功能模块
对于这样⼀个看似简单的需求来说，包含两⼤主要功能模块
1. 任务分解：依据物理设备处理任务的条件，对任务进⾏分解，任务分解的粒度是设备能够识别并执⾏（动作）2. 任务调度：任务调度就是按照顺序执⾏的逻辑，把任务顺序和逐⼀下达给设备
这⾥也有⼏个基本逻辑就是，设备在某⼀个时间点上只能执⾏⼀个⼦任务，只有这个任务执⾏完毕后⽅能下达新的⼦任务。多重任务逻辑只会导致设备⽆法完成任务（不知道到底该执⾏那个动作）。 4.1. 实体关系
我们从上⾯需求分析整理当前⾄少包括2个实体，包含的属性（字段）如下：
1任务：
任务ID，任务号，源地址（从哪⼉），⽬标地址（到哪⼉），开始时间，结束时间，状态 2⼦任务：
⼦任务ID，任务ID，源地址(从哪⼉ 上⼀个⼦任务的⽬标地址）， ⽬标地址（到哪⼉ 下⼀个⼦任务的源地址）， 执⾏机构，开始时间，结束时间，状态
5. ⼩节
本章我们从⼀个需求问题开始，然后经过需求分析，把需求问题分解为功能点和数据实体，实体是下⼀步我们设计表或ORM model的基础原型，上⾯的实体只是⼀个初步的需求分析主要字段要求，实体属性（字段）会设计时会增加特定的其它属性（字段）。 下⼀章节我们将描绘如何把这个需求逐步演化到模型设计。
