1. 程式人生 > >python工業網際網路應用實戰2—從需求開始

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

用例名稱

托盤入庫用例

前提條件

  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排程相關裝置完成實托盤從入庫站臺搬運到庫存貨位,反饋結果給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. 任務分解:依據物理裝置處理任務的條件,對任務進行分解,任務分解的粒度是裝置能夠識別並執行(動作)
    2. 任務排程:任務排程就是按照順序執行的邏輯,把任務順序和逐一下達給裝置 

  這裡也有幾個基本邏輯就是,裝置在某一個時間點上只能執行一個子任務,只有這個任務執行完畢後方能下達新的子任務。多重任務邏輯只會導致裝置無法完成任務(不知道到底該執行那個動作)。

 4.1. 實體關係

  我們從上面需求分析整理當前至少包括2個實體,包含的屬性(欄位)如下: 

1任務:

任務ID,任務號,源地址(從哪兒),目標地址(到哪兒),開始時間,結束時間,狀態 

2子任務:

子任務ID,任務ID,源地址(從哪兒 上一個子任務的目標地址), 目標地址(到哪兒 下一個子任務的源地址), 執行機構,開始時間,結束時間,狀態

5. 小節

  本章我們從一個需求問題開始,然後經過需求分析,把需求問題分解為功能點和資料實體,實體是下一步我們設計表或ORM model的基礎原型,上面的實體只是一個初步的需求分析主要欄位要求,實體屬性(欄位)會設計時會增加特定的其它屬性(欄位)。 下一章節我們將描繪如何把這個需求逐步演化到模型設計。

 

&n