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 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. 功能模組
對於這樣一個看似簡單的需求來說,包含兩大主要功能模組
-
- 任務分解:依據物理設備處理任務的條件,對任務進行分解,任務分解的粒度是設備能夠識別並執行(動作)
- 任務調度:任務調度就是按照順序執行的邏輯,把任務順序和逐一下達給設備
這裡也有幾個基本邏輯就是,設備在某一個時間點上只能執行一個子任務,只有這個任務執行完畢後方能下達新的子任務。多重任務邏輯只會導致設備無法完成任務(不知道到底該執行那個動作)。
4.1. 實體關係
我們從上面需求分析整理當前至少包括2個實體,包含的屬性(欄位)如下:
1任務:
任務ID,任務號,源地址(從哪兒),目標地址(到哪兒),開始時間,結束時間,狀態
2子任務:
子任務ID,任務ID,源地址(從哪兒 上一個子任務的目標地址), 目標地址(到哪兒 下一個子任務的源地址), 執行機構,開始時間,結束時間,狀態
5. 小節
本章我們從一個需求問題開始,然後經過需求分析,把需求問題分解為功能點和數據實體,實體是下一步我們設計表或ORM model的基礎原型,上面的實體只是一個初步的需求分析主要欄位要求,實體屬性(欄位)會設計時會增加特定的其它屬性(欄位)。 下一章節我們將描繪如何把這個需求逐步演化到模型設計。