熟女人妻水多爽中文字幕,国产精品鲁鲁鲁,隔壁的少妇2做爰韩国电影,亚洲最大中文字幕无码网站

　　e-works在線學院邀請我再把2022年《PLC早已不是那個PLC》的課程升級，并和大家作在線分享，目前在線和回放已經有2000人次，且有觀眾提出的20多個問題。我最關注的是觀眾提問，不管是在線的還是線下的，因為人們提出的問題往往會超越演講者思考的視角，這也讓我能夠重新審視和組織內容，因此，本文將對這些問題進行概要性的整理和分享，以期進一步帶領大家思考PLC技術的發展趨勢。文章轉載自“說東道西”微信公眾號。

　　文/宋華振

　　1 PLC是做邏輯控制的嗎

　　即使到了2024年的今天，“PLC是做邏輯控制的”，這一概念似乎對于很多人而言仍是一種根深蒂固的認識，以至于在立志改變世界的人眼里，PLC只能做邏輯控制、不能做高級算法，談及工業總線就是RS485、CAN、Modbus等古董級技術需要被改變……他們甚至認為這意味著巨大的機會。幾年前我經常聽到做工業互聯網的、來自IT的專家們總是強調這些，我就問他們何以如此執念這些說辭——他們說自己也認真學習了大學關于PLC的教材。一聲嘆息，我說：你們看的教材大部分都還停留在20年前。

　　其實，PLC執行計算任務采用高級語言編程，這樣的控制器在30多年前就已經有了。就拿貝加萊的PLC來說，早在80年代就運行OS9基于優先級的一套操作系統，采用MC68000處理器，可以運行BASIC解釋器編寫算法;到了90年代，就已經采用了pSOS+的定性分時多任務操作系統(該技術所在公司被WindRiver收購并融入VxWorks)，之后硬件從MC68K轉到Intel X86，其實這兩個CPU都有對應的協處理器可以處理浮點運算。

　　圖1 貝加萊黑色系列與藍色系列PLC

　　還有就是另一個現在似乎已經銷聲匿跡的公司叫SoftPLC，我記得2003年，和當年的老搭檔Eric為昆山正新橡膠開發過一套超過100多臺硫化機的集群管理項目。當時Eric就用Java編程——使用的CPU印象中是一個Pentium II 266MHz的處理器，這個CPU可以運行JVM(Java Virtual Machine-Java虛擬主機)，想想也是20多年前的工業互聯網項目了。印象中這個公司的介紹還挺拗口的——SoftPLC是SoftPLC公司在SoftPLC平臺上開發的名為SoftPLC的SoftPLC……

　　所以，PLC局限于邏輯任務，從歷史來看，在30年前就已經被改變了。

　　2 PLC的新概念意味著什么

　　世界總是這么有趣的兩極分化，一方面，很多人還認為PLC僅能做邏輯控制，而另一方面，另一批人則開始為新的PLC概念而技術熱情高漲。比如SoftPLC、云PLC、AI PLC、虛擬PLC，甚至有人問有沒有GPT PLC……，這不是正在說明PLC與時俱進地在改變嗎?

　　PLC新概念都在試圖告別傳統PLC，并一致將矛頭對準了原有PLC的各種弊端，比如不能用開放的語言編程，不能進行計算任務，充滿著要與PLC割裂的決心，但又很矛盾，因為他們還叫PLC，只是加了一些前綴。

　　SoftPLC區別于傳統硬PLC的直接硬件資源操作，它出現在CPU、RAM既快又便宜了——配上高精度時鐘，加載實時操作系統以及為系統配置高速高精度時鐘。一種是采用Windows+RT擴展，或直接采用像VxWorks這樣的RTOS，這個架構其實在機器人系統里也比較普遍。在新的CNC架構里也是如此，將傳統的CNC專用型硬件拆解為通用PC+RTOS，如RT-Linux或Windows+RT擴展的方式，代替傳統專用的CNC系統。

　　云PLC將PLC部署在云端、虛擬PLC借助于今天高性能處理器的多核及軟件部署，可以把Runtime運行在多個核上——這兩者其實都是考慮了性價比的問題。因為云資源的確成本低，而把多個Runtime部署在一個多核處理器，本身也是一個好辦法——但是，這里主要考慮的還是可靠與穩定性問題。關于這個問題，之前和e-works黃博士交流過虛擬PLC這一趨勢，我也向彭瑜老師請教過，他覺得技術上當然是可行的，也具有經濟性，但這又意味著把所有雞蛋放在同一個籃子里;而設計分布式系統時，就考慮過降低系統風險而采用了分布式。因此，在計算任務上，這樣的處理方式可以被理解，但當出現強實時性時，這種架構就會變得有風險。

　　圖2 虛擬PLC架構

　　AI PLC其實也是同樣道理，增強PLC的AI能力，這個也是可以實現的——既然PLC都已經并不局限于嵌入式本身，而可以將SoftPLC運行在PC的Windows+實時擴展或RT-Linux上，那么，在這個架構上增強AI能力——因為AI就其實現而言，就是軟件，也并不是不可以的。例如，把AI加速器部署在PCIe的插槽上，可以用Linux任務對其進行處理——而實時任務與非實時任務結合，這個在底層硬件上可以通過CPU多核間的虛擬以太網來實時完成通信，調度機制則由操作系統來實現。

　　周期性任務與事件驅動型任務，在這里完全可以被耦合——這通過開發工具平臺的配置即可完成，也是工業軟件里的一個重要環節，包括像Portal、Automation Studio、TwinCAT、Logix等。

　　這些PLC的新概念主要還是聚焦了數據類任務的處理需求上，但是，這些與實時任務完全可以通過現有的架構硬件擴展或通信接口連接的軟方式來實現。對于傳統PLC廠商而言，這些都已經在研發或實際應用中。這里需要提醒的是，傳統PLC廠商從來沒有停下來發展的腳步，只不過似乎聲音沒有IT廠商那么大，因為，解決問題是第一要務。

　　3 IEC61499會取代61131嗎

　　盡管我對IEC61499不是那么了解，但在2018年，交大的戴老師作為這項IEC標準的制定專家之一，曾經滔滔不絕地給我描述過IEC61499的好處，作為邊緣計算的一個實現方案，IEC61499的確在這個層級的業務編排方面有很大的優勢。

　　IEC61499并非設計為取代IEC61131，IEC61499是一種面向事件驅動型任務的系統建模語言，側重于定義每個結構組件中的語義。IEC61131更多在集中式控制的周期性任務編程語言方面。因此，這種“取代”在邏輯意義上無從談起——可以理解為IEC61131組成的機器，在構成一個產線這一層的時候，標準語言是缺乏的，因此，才產生了IEC61499這樣的需求。任何技術都得看需求來源，IEC61499更多來自于集成后對全局性的協作任務處理的需求。而IEC61131主要由PLC作為集中控制中心，把單機內部進行了全局的控制協作，而機器之上的產線級又需要另一種編程語言來實現。

　　這兩者更多是互補的關系，IEC61499的協作用于調度任務的編排，然后有了協作的“結果”輸出，這些可以發送給下面的機器執行，因此，IEC61499和IEC61131之間也可以通過OPC UA來交互任務，這樣可以實現計算任務和控制任務的融合——它們不是取代關系，而是更好的協作關系。

　　當然了，無論是IEC61131-3，還是IEC61499，都不是唯一性的選擇。編程并非不是IEC61131、就是IEC61499，比如即使在IEC61131較多應用的時候，還是有工程師更愿意用C/C++編程。這很正常，不用IEC61499，也可以用Java、Python……這種技術的標準，它是一個生態的問題，如果生態里大家都用這個規范，那對應這方面的人才就比較多，支持的廠商也比較多，就會比較經濟。當然了，工業標準都來自于工業領域的企業根據自身的特殊場景而設計的——對于適配性就會更好，但也不意味著對用戶而言，就是唯一的選擇。

　　4 PLC與DCS有哪些主要區別

　　其實，PLC與DCS不大容易被混淆——實際上，PLC是一套嵌入式系統，即，開發主機和運行對象并不是在一個平臺，而DCS的開發和運行其實是可以在一套系統里的(如開發在Linux，運行在Linux)。嵌入式系統自己就有操作系統，也有BIOS處理，以及自己的任務調度和處理機制。而DCS一般運行在Windows/Unix/Linux系統上，DCS更多的是指軟件層面，包括開發的工程服務器、數據服務器、操作員站、現場控制器——儀表采集、DCS的閉環處理、到現場的調節閥、執行機構的執行等。

　　DCS主要處理的是連續型任務的流程工業，它的Know-How包括工藝閉環控制，都在主機上，而且在多回路間的相互關系也在主機上進行解耦……。DCS一樣需要針對具體的應用場景做工藝的迭代，使得其能夠響應環境變化，確保控制的精度、響應。但是PLC實際上也可以在流程工業中被應用，因為流程工業領域并不完全是流程處理，包括現場執行器也有很多離散執行的場景，還有很多前道流程、后道離散的場景。

　　4 如何看待開源PLC

　　有朋友問：如何看待開源PLC的現狀和前景?是否在可預見的未來以閉源為主?——開源的PLC主要指的是借助于開源社區資源來構建PLC的技術架構，這里包括以下幾個層面：

　　(1)開源硬件，比如Ardino、樹莓派這類開源硬件：是否可用，當然對于IIoT非實時控制我想目前沒有問題，至于是否可以被應用于控制器，那就滿足控制器在穩定可靠方面的設計需求，認證通過即可;

　　(2)開源RTOS，像RT-Linux，但這會需要根據實際需求來裁剪;

　　(3)開源的開發平臺，像Eclipse，可以作為一個開源的工程平臺來集成各種應用;

　　(4)開源的應用類軟件，如ROS、openCV視覺方面的庫，這方面繼承開源思想的主體IT企業可能在HMI設計、機器視覺方面會有開源的資源可用，但在垂直行業的應用方面，仍然需要自己來封裝。

　　開源還是閉源，這里有個關鍵問題是“責任問題”，如果開源給你用，那代碼的提供者就不需要承擔因此造成的安全、穩定性方面的風險了。而自動化企業可以借助于開源技術，但當你開發成為商業產品進行銷售時，在法律意義上，你就需要承擔因此帶來的后果，例如造成宕機、故障所需的服務，總不能說我用了開源技術，所以，我不承擔這個后果——那你就別當做產品銷售。

　　第二個問題是“商業保密”，如果工業Know-How都開源，那企業自身的商業價值是什么?因此，開源PLC，只是說它采用了開源技術，但不代表它的技術也是開源的。

　　5 PLC如何與5G技術結合

　　5G技術與PLC的融合方式，如果在PLC集成5G模塊，顯然會增加PLC的成本，因此，在IEEE的方案就是采用TSN作為前傳網絡。目前，在歐洲由3GPP和IEC等組織在進行著5G與TSN網絡的融合方案，5G將作為TSN的虛擬橋進行設備的連接。

　　圖3 5G與TSN網絡的時鐘同步計算架構

　　圖3為5G/TSN的時鐘同步方案架構，對于通信而言，5G需要解決包括帶寬、丟包率、抖動、時鐘同步及精度等一系列問題。因此，由ACIA組織來自移動通信、自動化領域、用戶端的廠商共同推進5G的傳輸方案。移動網絡的優勢和缺點其實是一樣的明顯，因此，必須結合工業場景，在控制系統中集成5G，另外成本的經濟性也是需要跨越的。

　　把5G集成到PLC上，還是說用一個盒子(交換機)，將TSN有線和5G發射集成在一起，作為一個“橋”——可能更多的人還是愿意選擇一個盒子，畢竟很多個PLC作為終端節點匯集到TSN/5G交換機，這樣就一個車間一個5G節點，否則，每個PLC帶一個5G通信口，這樣成本還是有點高。

　　5 PLC可以與AI集成嗎

　　顯然，這是可以的，對于PLC來說，AI與PLC的集成，訓練和推理是兩件事情，訓練仍然需要較大的算力，但部署算法則并不需要較大的算力。

　　之前，個人認為AI需要大算力，在工業里缺乏經濟性，但是，記得幾年前在家附近園區里散步，晚上總看到一個在做測試的移動臺子，就很感興趣地和一個工程師聊，他說在做安防系統的夜間視覺測試，我想那些攝像頭才200塊錢，怎么就這么智能呢?他告訴我這個訓練是要大數據訓練，但形成的判斷模型則不需要較大的算力，普通攝像頭就可以了。這個事情讓我茅塞頓開，訓練與推理自然是可以被分離的，當然，這需要離線升級算法包。

　　那么，對于PLC與AI結合的算力考慮就可以放在本地推理上的算力需求上。而在實際的自動化系統里，目前視覺的數據量較大——那么AI的問題就簡化為對視覺的處理。這個處理方案有兩種，一種是基于PC的圖像處理，就是把PC的算力用來進行信息處理。另一個就是直接在視覺上嵌入AI能力，以硬件方式來處理數據，采用FPGA或專用的AI芯片——這里的問題就是視覺處理與自動化系統的集成問題。

　　在貝加萊的機器視覺中，即將推出的就是采用了26TOPS的AI處理器，內置深度學習模型，以及快速的處理信號，并可以將分析結果與自動化系統通過實時通信來實現同步。

　　6 PLC與邊緣計算能夠集成嗎

　　邊緣計算的概念慢慢的火起來了——這里指的不僅僅是概念，而是現實應用的需求真正出現了。

　　既然我們認為PLC已經可以做高級算法，又有大的數據處理能力——那么，作為一個嵌入式邊緣節點也是可以的。另外如果PC+PLC被集成在一起，那作為一個邊緣節點也可以。如果一個PC服務器作為邊緣計算節點，那它也需要與現場任務進行交互，采集數據并下發指令。

　　因此，AI PLC、云PLC、虛擬PLC都是為了能夠將AI的計算任務與控制的實時任務相結合。由于AI、云PLC設計思想都是在邊緣側，通常邊緣計算主要處理全局性的協作類、優化、調度、策略性任務，因此，以PLC、SoftPLC、云PLC、虛擬PLC作為一個邊緣計算的實現方案，也并非不可以。

　　7 PLC最新技術趨勢有哪些

　　PLC本身來自于需求的演變和橫向技術的融合——這也是系統創新的兩個“抓手”。要了解技術的趨勢，其實，關注市場的需求、橫向科技的發展則更為關鍵。

　　從需求側來說，未來控制器更為強調開放性，這在過去的數十年均是如此——它主要源于整個制造的集成度更高的發展需求。因此，必須打破縱向邊界，讓PLC融入到數字化的系統中，但是，PLC是一個非常關鍵的數據節點，它作為機器控制的中心，也是一個數字化系統架構的數據節點。

　　(1)通信增強數字化融合能力

　　PLC本身的通信能力集成，使得分布式架構更為通暢，OPC UA FX扮演了這個重要的角色，無論PLC的控制部分被部署在嵌入式對象上，還是PC、云端、虛擬架構下，那么，它對于通信的能力就會增強。OPC UA FX解決了同聲翻譯的問題，FX包括TSN/5G/WIFI-6，它解決的是“同聲”，而OPC UA則解決語義互操作中的“同語言”的問題。

　　圖4 OPC UA FX保障數據的高速傳輸

　　因為云PLC、虛擬PLC、AI PLC各種新概念的出現，它依然依賴于連接從底層傳感器到云端的鏈路，這時無論是采用有線的TSN，還是無線的WIFI6/7，或5G，都是需要通信提供連接支持的。而另一方面，為了在軟件層面實現數字化設計、運行、分析與決策系統的端到端連接，語義交互的規范接口也是必須的，因此，OPC UA FX正是為了這類場景而設計的。

　　(2)AI加持讓機器更“聰明”

　　AI的意義在于它會讓機器更“聰明”——這與基于規則和安全值的控制不同，傳統機器設計了簡單的控制規則，包括過去大規模生產下，對于工藝參數本身都是通過“試湊”的方式來進行。但當個性化需求越來越普遍、頻繁的更換作業時，就會遇到參數如何降低開機浪費的問題，那么就需要通過物理建模構建整個控制策略，但對于模型的精度而言，需要數據來收斂，這就可以基于歷史數據來分析并做出收斂，來獲得參數的最優組合。機器會不斷去訓練，它會越來越“聰明”。

　　(3)編程語言的演進

　　PLC作為一種設備，它的開發必須響應快速的變化。因此，它本身作為一個設備，對它的應用開發工具而言，越簡單越好，至于是用低代碼，還是生成式編程，都是可以作為選項去不斷發展成熟的。

　　在未來，可以想象，并不需要采用IEC61131，你可以采用更為靈活的編程語言，甚至自然語言的編程，也并非不可能——因此，這些需求結合橫向技術，為PLC賦予了更多的可能性——至于它是否還叫PLC，則并不重要。

　　8價值競爭，才是自動化的關鍵

　　歸根結底，自動化的價值并不在PLC本身，而是加載在PLC上的工程集成能力、工藝Know-How封裝，以及由此帶來的機器和產線的品質、效率與快速交付能力。因此，討論PLC本身孰優孰劣本身的意義并不大，縱觀整個自動化業界的競爭力，在多年以來都已經不在產品本身，而在于整體工程能力。

　　產品之外的價值更為重要，對于自動化廠商而言，競爭力來自以下幾個方面：

　　(1)平臺的能力

　　不管誰家的PLC，其實都是需要由平臺來對對象進行集成，并根據機器的開發流程來進行全流程的服務集成。這就需要平臺具有高的開放性，PLC向云、AI方向發展，是讓開放世界的更多資源能夠被高效地與控制相集成。

　　今天，人們討論工業軟件時，主要聚焦在CAD/CAE上，其實，集成開發平臺像Automation Studio、Portal、Logix、TwinCAT等，同樣是非常關鍵的工業軟件。只是這容易被忽視，但它關乎集成的難易度、深度(算法設計)、廣度(開放資源的集成度)等多個維度的考量。并且，作為一種持續的創新平臺工具，它會將歷史積累的知識以APP形式封裝，被調用——這是PLC真正的價值所在。工業軟件的本質就是知識的復用，而這才是核心中的核心。

　　(2)工程能力

　　PLC廠商單純依靠銷售產品已經不再能夠成為企業的競爭力。通過工程集成將機電對象組織為一個高效的機器，這種結合傳動、邏輯、工藝算法、AI的算法集成，其中包括從建模仿真、代碼開發、測試驗證、遠程診斷與維護等，整個完整的工程服務能力，才是現在自動化廠商的核心競爭力。

　　(3)工程師的競爭

　　而在這些軟件、工程能力的背后，則是人才的競爭。無論前端的銷售，還是研發的工程師、應用開發、現場調試、維護——工程師在其中的角色已經不是過去PLC僅做邏輯年代那么簡單。控制系統的復雜性來自于機器和制造本身的復雜性。工程師的認知、規劃與設計、動手能力、協作、溝通能力，成為了項目實施的基礎保障。

　　因此，PLC早已不是那個PLC，自動化行業也早已不是大家理解中的自動化行業——它已成為了關乎整個產業高效發展的重要一環。