- บทความ | ดร.เอมอัชนา นิรันตสุขรัตน์
- ทีมระบบไซเบอร์-กายภาพ (CPS)
- หน่วยทรัพยากรด้านการคำนวณและไซเบอร์-กายภาพ (NCCPI)
- ศูนย์เทคโนโลยีอิเล็กทรอนิกส์และคอมพิวเตอร์แห่งชาติ (เนคเทค)
- ภาพปก | กรรวี แก้วมูล เรียบเรียง | ศศิวิภา หาสุข
ปัจจุบันเทคโนโลยี Internet of Things ถูกยกให้เป็น “Mega Trend” ที่จะส่งผลมหาศาลต่อธุรกิจทุกๆ ด้าน เราได้เห็นอุปกรณ์หรือ Things ที่สามารถสื่อสารกันผ่านอินเทอร์เน็ตมากขึ้นและเริ่มติดตลาด ตั้งแต่อุปกรณ์ควบคุมอุณหภูมิอัจฉริยะ (Smart Thermostat) ไปจนถึงสายข้อมือตรวจวัดกิจกรรมของผู้สวมใส่ (Fitness Bracelet/Tracker) ความสามารถที่จะเชื่อมต่ออุปกรณ์ทุกประเภททำให้เกิดโมเดลบริการใหม่ๆ และสร้างแรงจูงใจให้ธุรกิจหันมาให้ความสนใจนำเทคโนโลยี IoT มาใช้มากขึ้นเรื่อยๆ และเมื่อพูดถึง IoT ทุกคนมักจะนึกถึงการเชื่อมต่ออุปกรณ์ต่างๆ ให้สื่อสารกันได้ผ่านคลาวด์ ดังนั้นในยุค IoT คลาวด์ได้กลายมาเป็นศูนย์กลางของทุกอย่าง ไม่ว่าจะเป็นการเชื่อมต่อ การเก็บข้อมูล และการประมวลผล จึงไม่น่าแปลกใจที่ปริมาณ Data Center เพิ่มขึ้นเป็นเท่าตัวในแต่ละปี เช่นเดียวกับปริมาณข้อมูลที่วิ่งบนอินเทอร์เน็ต เมื่อถนนทุกสายมุ่งสู่คลาวด์ ผลกระทบที่ตามมาก็คือปัญหาคอขวดทั้งในแง่ของการเก็บข้อมูลและเครือข่ายเข้าออก การเปลี่ยน HDD มาใช้ SSD อาจจะช่วยเพิ่มความเร็วในการเก็บข้อมูลได้บ้าง และหลายคนฝากความหวังว่าการมาถึงของ 5G จะเยียวยาในเรื่องเครือข่าย แต่ทั้งหมดก็เป็นการแก้ปัญหาที่ปลายเหตุ เพราะสิ่งที่ผิดมาแต่ต้นคือสมมติฐานที่ว่า คลาวด์คือคำตอบ (ที่เหมาะสม) ของทุกสิ่ง
เทคโนโลยี Edge Computing หรือเรียกย่อๆ ว่า Edge เป็นวิธีการเลือกใช้หน่วยประมวลผลในคลาวด์ที่อยู่ใกล้กับต้นทางข้อมูลมากที่สุดเพื่อลดเวลาในการเข้าถึงข้อมูล ที่เห็นกันมากคือ Edge ในอุปกรณ์สื่อสารระดับท้องถิ่นจำพวกเกตเวย์หรือเราท์เตอร์ เทคโนโลยี Edge เข้ามาอยู่ในกระแสมากขึ้นในระยะปีสองปีหลังมานี้ เนื่องจากคนเริ่มตระหนักกันแล้วว่า Edge เป็นองค์ประกอบที่จำเป็นของ IoT ที่จะมาช่วยเติมเต็มการทำงานของ Cloud และแก้ปัญหาที่กล่าวมาข้างต้น
คำที่เกี่ยวข้อง
- Cloud Computing
Cloud Computing หรือที่มักเรียกกันโดยย่อว่า Cloud คือโมเดลในการให้บริการทรัพยากรเพื่อการคำนวณซึ่งผู้ใช้บริการสามารถเข้าถึงได้ผ่านเครือข่าย มีโครงสร้างพื้นฐานเป็น Data Center ที่ประกอบด้วยเซิร์ฟเวอร์จำนวนมาก โดยจากมุมมองของผู้ใช้ ทรัพยากรของเซิร์ฟเวอร์เหล่านี้จะหลอมประสานเสมือนใช้งานบนเครื่องเดียว (Virtualized Resources)
จุดเด่นของ Cloud คือความสามารถในการจัดสรรทรัพยากรแบบพลวัต กล่าวคือผู้ใช้งานสามารถเปลี่ยนแปลง เพิ่มลด (scale) ขนาดของโหลดการใช้งานได้ตลอดเวลา ไม่จำเป็นต้องจัดสรรทรัพยากรเผื่อโหลดสูงสุดไว้ล่วงหน้าเมื่อยังไม่ได้ใช้ ค่าใช้บริการ Cloud จึงเป็นแบบจ่ายตามที่ใช้หรือ pay as you go และเป็นเหตุผลหนึ่งที่ทำให้บริการคลาวด์ได้รับความนิยมสูงขึ้นเรื่อยๆ จากรายงานประจำปี 2019 ของ Rightscale (Flexera) พบว่า 94% ของบริษัทที่สำรวจใช้ Cloud และพบว่านอกจากเปอร์เซ็นต์การใช้งานจะเพิ่มขึ้นทุกปีอย่างต่อเนื่องแล้ว แต่ละบริษัทยังมีแนวโน้มใช้งบประมาณไปกับค่า Cloud เพิ่มขึ้นด้วย [1]
- Edge Computing
Edge Computing ในที่นี้ขอเรียกสั้นๆ ว่า Edge คือแนวคิดในการประมวลผลใกล้กับแหล่งกำเนิดข้อมูล แทนที่การส่งข้อมูลทั้งหมดไปประมวลผลที่คลาวด์ โดยตำแหน่งการประมวลผลของเอดจ์สามารถเป็นได้ตั้งแต่บนตัวอุปกรณ์ IoT เองขึ้นไปจนกระทั่งถึงชั้นบนสุดของ Local Area Network (LAN) เช่นอุปกรณ์เกตเวย์ เซิร์ฟเวอร์ของสำนักงานหรือโรงงาน ฯลฯ ดังแสดงในรูปข้างล่าง
แท้จริงแล้วแนวคิด Edge Computing เกิดขึ้นมาก่อนยุค IoT ตัวอย่างชัดๆ คือ Edge ในเครือข่ายอินเทอร์เน็ตเช่น LAN และ Content Delivery Network (CDN) จึงอาจกล่าวได้ว่า Edge มีรากฐานมาจากวิวัฒนาการของเครือข่ายจากการรวมศูนย์แบบ Star topology มาเป็น Tree topology ที่มีการเพิ่มชั้น (Tier) ของโหนดคั่นกลางระหว่างโหนดราก (Root Node) ซึ่งเป็นศูนย์กลางกับโหนดปลายทาง (End Nodes) ดังนั้นหากมองเช่นนี้ คำว่า Edge มีความหมายที่กว้างและสามารถนำไปปรับใช้ได้ในหลายบริบท ต่างจาก Fog Computing หรือ Fogging ซึ่งเกี่ยวข้องกับ IoT โดยตรง และเพิ่งจะถูกนิยามขึ้นในปี 2012 โดยบริษัท Cisco
นัยยะของ Fog Computing ซ้อนทับคาบเกี่ยวกับ Edge Computing มากจนมักเกิดความสับสนว่าทั้งคู่เหมือนหรือต่างกันอย่างไร เหตุการณ์คล้ายกับคราวที่ Cisco นิยามคำว่า “Internet of Everything” ขึ้นมาเพื่อครอบ Internet of Things เพียงแต่ได้ผลลัพธ์ต่างกันคือ Fog Computing ติดกระแส ในขณะที่ Internet of Everything ไม่แพร่หลายมากนัก ส่วนหนึ่งอาจเป็นเพราะ Cisco ได้ก่อตั้ง OpenFog Consortium ตามมาในปี 2015 โดยร่วมมือกับบริษัทและมหาวิทยาลัยระดับชั้นนำในการผลักดันให้ Fog Computing เป็นมาตรฐานให้กับภาคธุรกิจในการสร้าง Edge Computing โดยนอกจาก framework อ้างอิงสำหรับอุปกรณ์ Edge แล้ว กลุ่มจะร่วมกันกำหนดรายละเอียดทางเทคนิคของส่วนอื่นๆ ที่เกี่ยวข้อง ไม่ว่าจะเป็นเครือข่าย การเก็บข้อมูล ความปลอดภัย ฯลฯ กล่าวโดยย่อคือ Edge เป็นแนวคิด ส่วน Fogging เป็นวิธีการ [2]
อย่างไรก็ดี หากสำรวจนิยามของ Edge และ Fogging ในปัจจุบัน จะพบว่ามีความพยายามในการขยับจุดยืนของทั้งสองคำออกจากกันให้เกิดความต่างมากขึ้น ซึ่งมีสองแนวทางหลักๆ คือ
- 1) แบ่งตามตำแหน่งที่ตั้งของการคำนวณในแนวตั้งจากอุปกรณ์สู่คลาวด์ โดย Edge Computing จะครอบคลุมเฉพาะการคำนวณที่เกิดขึ้นภายในอุปกรณ์หรือแหล่งกำเนิดข้อมูลเองหรือในโหนดห่างจากแหล่งกำเนิดข้อมูลไม่เกิน 1 hop ส่วน Fog Computing จะอยู่ในอุปกรณ์เครือข่ายระดับ LAN เช่น Gateway, Router, Access Point
- 2) แบ่งตามการกระจายตัวของการคำนวณในแนวนอน กล่าวคือ Edge หมายถึงการคำนวณที่เกิดขึ้นในโหนดๆ หนึ่งที่อยู่ตำแหน่งใดก็ได้ที่ต่ำกว่า Cloud และใกล้แหล่งข้อมูล และ Fogging หมายถึงการทำให้โหนด Edge หลายๆ โหนดทำงานร่วมกันเป็นคลัสเตอร์หรือที่เรียกว่า Micro Data Center ซึ่งเลียนมาจากแนวคิดของ Cloud แต่อยู่ใกล้พื้นดิน (อุปกรณ์ปลายทาง) มากกว่า ซึ่งหากจะต้องเลือก ผู้เขียนเองโน้มเอียงมาทางนิยามแบบที่สองนี้
ถึงกระนั้น Edge และ Fogging ต่างตั้งอยู่บนเหตุผลและเป้าหมายเดียวกันคือการแบ่งเบาภาระของ Cloud และเครือข่าย เพิ่มประสิทธิภาพให้กับแอปพลิเคชัน IoT และลดค่าใช้จ่ายในการส่งข้อมูลที่ไม่จำเป็น
- ดังนั้นจะเรียกอย่างไรก็ยังไม่สำคัญเท่ากับการนำไปใช้ การพัฒนาระบบ IoT ใดๆ ก็ตามควรพิจารณาถึงความสมดุลในการใช้ Cloud และ Edge เป็นลำดับแรกๆ โดยเริ่มตั้งแต่ขั้นตอนออกแบบ
Cloud vs Edge
ดังที่ได้เกริ่นไปแล้วว่า Cloud และ Edge ไม่ใช่เทคโนโลยีที่เป็นคู่แข่ง หากแต่ช่วยเติมเต็มซึ่งกันและกัน ดังนั้นระบบ IoT หนึ่งๆ อาจใช้ทั้ง Cloud และ Edge ควบคู่กัน แต่ก่อนที่จะตัดสินได้ว่ากระบวนการใดควรเลือกใช้ Cloud หรือ Edge เราควรทราบความสามารถและข้อจำกัดของทั้งคู่เพื่อชั่งเปรียบเทียบ
1. Delay/Response time
เวลา คือข้อได้เปรียบหลักที่ Edge มีเหนือ Cloud จุดมุ่งหมายแรกๆ ของการสร้าง IoT Edge ก็คือเพื่อลดเวลาการตอบสนอง ตัวอย่างที่ชัดเจนที่สุดคือ รถยนต์อัตโนมัติไร้คนขับซึ่งประกอบด้วยเซนเซอร์จำนวนมาก ข้อมูลจากเซนเซอร์จะต้องถูกประมวลผลเพื่อควบคุมอุปกรณ์กลไกต่างๆ ของรถแบบ Real Time การส่งข้อมูลทั้งหมดไปที่ Cloud แล้วรอให้ Cloud ส่งคำสั่งกลับมาที่รถจึงไม่ใช่วิธีการที่เหมาะสม หากจะเปรียบเทียบ ให้คิดถึงเวลาที่เราเปิดเช็คอีเมล์ทั้งหลายที่ให้บริการบนคลาวด์ เราต้องรอโหลดหน้า Inbox อยู่หลายวินาที ดังนั้นถ้ากรณีเป็นตายอย่างการเบรคของรถ ซึ่งไม่ใช่แค่การส่งข้อมูลไปกลับจากคลาวด์เท่านั้น แต่ยังต้องมีการคำนวณว่ามีสิ่งกีดขวางหรือไม่ จำแนกว่าเป็นสิ่งกีดขวางประเภทใด เคลื่อนที่ด้วยความเร็วเท่าไหร่ ต้องเบรคหรือไม่ ฯลฯ ทั้งหมดนี้จะต้องเสร็จในหลักเสี้ยววินาที เราจึงไม่สามารถที่จะรอ Cloud ได้ แต่ก็ไม่ได้หมายความว่ารถยนต์ไร้คนขับจะใช้ Cloud ไม่ได้เลย เพราะยังมีกระบวนการบางอย่างที่ไม่ต้องการความเร่งด่วนในการตัดสินใจ หรืออาจต้องรอเก็บข้อมูลเป็นเวลานานเพื่อดูแนวโน้ม เช่นการตรวจวัดสภาพรถเพื่อแจ้งเตือนการซ่อมแซม กรณีเช่นนี้จะใช้ Cloud ก็มีความเหมาะสม
2. Resource/Computational power
จริงอยู่ว่าอุปกรณ์ Edge ไม่ว่าจะเป็น Microcontroller, Single-board computer ไปจนกระทั่งถึง Mobile device หรือ Personal computer ล้วนมีความสามารถเพิ่มขึ้นเรื่อยๆ แต่ก็ยังเป็นมวยคนละชั้นกับ High-performance servers ที่ทำงานร่วมกันภายใน Data Center ดังนั้น Cloud เป็นตัวเลือกที่เหมาะสมสำหรับกระบวนการที่ต้องมีการคำนวณจำนวนมากและซับซ้อนเช่น Deep Learning หรือมีตัวแปรที่เกี่ยวข้องจำนวนมากเช่น Big Data Analytics แต่ไม่ได้หมายความว่า Edge จะไม่สามารถทำสิ่งเหล่านี้ได้ โดยเฉพาะอย่างยิ่ง Deep Learning/Machine Learning ซึ่งปัจจุบันมี Edge Hardware ที่ออกแบบเฉพาะมาเพื่อรองรับมากมาย เช่น NVIDIA Jetson, Intel Movidius, Google Edge TPU แต่กระนั้นอุปกรณ์เหล่านี้ก็ยังมีขีดจำกัดและไม่สามารถทดแทน Cloud ได้ทั้งหมด วิธีการที่นิยมกันสำหรับ Deep Learning/Machine Learning ใน IoT คือการใช้ทั้ง Cloud และ Edge ควบคู่กัน โดยฝึกหรือ train โมเดลบน Cloud และถ่ายโอนโมเดลที่ฝึกเสร็จมาไว้ที่ Edge เพื่อทำ Inference ช่วยให้ผลลัพธ์ถูกส่งกลับไปที่อุปกรณ์ได้เร็วขึ้น
3. Cost/Expense
เป็นการยากที่เราจะตัดสินแบ่งแยกดำขาวในหัวข้อนี้อย่างชัดเจน เพราะมีปัจจัยปลีกย่อยหลากหลายที่ส่งผลต่องบลงทุนและค่าใช้จ่าย ตัวอย่างได้แก่
- Cloud
- • ประเภทของ Cloud ที่ใช้ Private หรือ Public, On-premise หรือ Off-premise
- • ปริมาณการใช้งานเช่น อัตราส่งข้อมูล ปริมาณข้อมูลที่เก็บ ความถี่การอ่านเขียนข้อมูล การวิเคราะห์ข้อมูล หากใช้แบบ Pay as You Go
- • ประเภทของการเชื่อมต่อ leased line, DSL, 3G/4G, Lora
- Edge
- • เป็น Client-side Edge หรือ Platform-side Edge
- • ค่าพัฒนาโปรแกรม
- • ปริมาณการใช้งานสำหรับ Platform-side Edge
- • ค่าอุปกรณ์และบำรุงรักษา
4. Geographical dispersion of devices
ถ้าต้นกำเนิดข้อมูลที่จะใช้ในการประมวลผลอยู่ในตำแหน่งที่ห่างจากกันมาก (เกินระยะของเครือข่าย LAN) เช่นค่าพลังงานที่วัดจากร้านค้าสาขาในเครือทั่วประเทศ ตำแหน่งของรถบรรทุกสำหรับติดตามและวางแผนการส่งสินค้า สถานะตำแหน่งที่จอดรถในการจัดการเมืองอัจฉริยะ กรณีเช่นนี้การใช้ Cloud ย่อมเหมาะสมมากกว่า Edge อย่างไม่มีข้อกังขา และเมื่อผนวกกับแอปพลิเคชัน IoT ที่ต้องเก็บข้อมูลจากพื้นที่ที่มีอาณาบริเวณกว้างโดยมากมักเป็นลักษณะการติดตามและแสดงผล หรือการวางแผนระยะยาวที่สามารถทนต่อ Delay ยิ่งทำให้เราตัดสินได้ง่ายขึ้น อาจจะมีเพียงส่วนน้อยที่ไม่สามารถทนต่อDelay ได้ เช่น การควบคุม Power Grid ในระดับบน ซึ่งก็มีแนวทางที่จะใช้ Cloud และลดเวลาตอบสนองลง ไม่ว่าจะเป็นการใช้ On-premise, High-Bandwidth Private Cloud หรือ Dedicated Communication Network เป็นต้น แต่แน่นอนว่าทั้งหมดแลกมาด้วยต้นทุนและค่าใช้จ่ายที่สูงขึ้น
5. Internet Connectivity
การใช้ Cloud หมายถึงอุปกรณ์ IoT ต้องเชื่อมต่อผ่านอินเทอร์เน็ต ซึ่งก็ไม่ได้เป็นข้อด้อยอันใด เพราะจริงๆ ในทางทฤษฎีแล้ว IoT คือการเชื่อมต่อสิ่งของต่างๆ ให้สื่อสารและทำงานร่วมกันได้ผ่านอินเทอร์เน็ต แต่ในทางปฏิบัติ การเข้าถึงเครือข่ายอินเทอร์เน็ตในบางกรณีเป็นเรื่องยากหรือมีต้นทุนสูง หากมีความจำเป็นต้องใช้ Computation Resource ขนาดใหญ่จริงๆ เราก็ไม่อาจหลีกเลี่ยงที่จะใช้ Cloud ได้ แต่สำหรับกรณีที่ไม่ได้มีการคำนวณซับซ้อน เช่นแอปพลิเคชันที่ใช้ใน Smart Farm ทั้งหลายที่อุปกรณ์ต่างๆ สื่อสารและควบคุมกันเองอยู่ในวง LAN เดียวกันอยู่แล้ว Edge เป็นทางเลือกที่เหมาะสมด้วยประการทั้งปวง
6. Data Privacy/Security
เมื่อใดก็ตามที่ต้องมีการส่งข้อมูลผ่านอินเทอร์เน็ต เมื่อนั้นก็ยังคงมีความเสี่ยง ต่อให้มีมาตรการป้องกันเข้มแข็งสักเพียงใดก็ตาม เพราะการเชื่อมต่ออินเทอร์เน็ตเหมือนการเปิดประตูบ้าน เราต้องเผชิญความเสี่ยงไม่เฉพาะเพียงจากการส่งข้อมูลออกไปภายนอก แต่ยังมีความเสี่ยงที่ผู้ไม่หวังดีจะบุกรุกเข้ามาภายใน อุปกรณ์ IoT มักปรากฏเป็นข่าวบ่อยครั้งว่ากลายมาเป็นจุดอ่อนในด้านความปลอดภัย เหตุผลส่วนหนึ่งมาจากการที่อุปกรณ์เหล่านี้มักมีกำลังประมวลผลต่ำและหน่วยความจำขนาดเล็ก ทำให้รองรับกลไกความปลอดภัยที่มีประสิทธิภาพสูงๆ ไม่ได้ อีกส่วนหนึ่งมาจากความสะเพร่าหรือความไม่รู้ของผู้พัฒนาอุปกรณ์และผู้ใช้อุปกรณ์เอง ตัวอย่างล่าสุดเมื่อไม่นานมานี้คือกรณีที่ Microsoft ตรวจพบกิจกรรมของกลุ่ม Hacker ชื่อ Strontium ที่มีพฤติกรรมมุ่งโจมตีโทรศัพท์ VOIP เครื่องพิมพ์สำนักงาน และตัวถอดรหัสวิดีโอ เพื่อใช้เป็นทางเข้าไปยังเครือข่ายภายในและขโมยข้อมูลสำคัญขององค์กรหรือบริษัท [3] Microsoft เชื่อว่ากลุ่มดังกล่าวอยู่เบื้องหลังการแฮ็คอีเมล์ของพรรคเดโมแครตในระหว่างการเลือกตั้งประธานาธิบดีสหรัฐฯ ในปี 2016 จึงไม่น่าแปลกใจว่าบางบริษัทถึงขั้นมีกฎห้ามส่งข้อมูลออกนอกเครือข่ายภายในเด็ดขาด เมื่อเป็นเช่นนี้บริษัทไม่มีทางออกอื่นนอกจาก Edge หรือ Private, On-Premise Cloud
จากที่ได้กล่าวมาทั้งหมด หากไม่มีข้อจำกัดที่บังคับให้เราต้องเลือกวิธีหนึ่งเนื่องจากอีกวิธีไม่สามารถใช้งานได้ เราสามารถสรุปแนวทางการเลือกระหว่าง Cloud และ Edge ได้คร่าวๆ ดังรูป โดยพื้นที่สีเทาเป็นบริเวณคาบเกี่ยวที่อาจต้องใช้ปัจจัยอื่นๆ มาช่วยตัดสินเช่นค่าใช้จ่าย
Edge ในภาคอุตสาหกรรม
การพัฒนาระบบ IoT ในภาคอุตสาหกรรมมีข้อที่ต้องพิจารณาซึ่งแตกต่างจากภาคส่วนอื่นๆ ประการแรก ในขณะที่ปัจจุบัน IoT อาศัยการเชื่อมต่อแบบไร้สายแทบจะทั้งหมด เพราะให้ความยืดหยุ่นในการเคลื่อนที่ของอุปกรณ์ แต่สำหรับภาคอุตสาหกรรมเราอาจใช้ตรรกะเดียวกันไม่ได้ ต้องยอมรับว่ากระบวนการในภาคอุตสาหกรรมส่วนใหญ่ต้องการความเชื่อมั่น (Reliability) ที่สูง มาตรฐานการสื่อสารที่ใช้กันอยู่จึงมักเป็นแบบมีสาย เช่น ตระกูล Fieldbus หรือ Ethernet
ประการที่สอง อุปกรณ์เครื่องจักรในโรงงานมักจะมาจากผู้ผลิตที่หลากหลาย มีโพรโตคอลสื่อสารแตกต่างกัน หรือแม้กระทั่งเครื่องจักรเก่าๆ ที่ไม่สามารถสื่อสารใดๆ ได้เลย ทำอย่างไรจึงจะสามารถดึงข้อมูลจากอุปกรณ์เครื่องจักรเหล่านี้ออกมาประมวลผล จากสองประเด็นนี้ Edge จะสามารถก้าวเข้ามามีบทบาทที่สำคัญยิ่ง โดยในเบื้องต้นอุปกรณ์ Edge ควรมีฟังก์ชันที่สามารถแปลงรูปแบบข้อมูลที่แตกต่างจากอุปกรณ์เครื่องจักรที่หลากหลายทั้งเก่าและใหม่ให้อยู่ในรูปแบบกลางเพื่อให้บูรณาการเข้าด้วยกันได้ และจากนั้นจะประมวลผลเลยหรือส่งขึ้นไปยัง Cloud ก็ตามแต่ความเหมาะสม
ประการที่สาม การสังเคราะห์โมเดลจากข้อมูลที่เก็บมาได้เพื่อนำไปใช้ตัดสินในภาคอุตสาหกรรม จะต้องอาศัยองค์ความรู้จากทั้งฝั่ง OT และ IT มาผนวกกัน การซื้อระบบสำเร็จรูปหรือว่าจ้างผู้เชี่ยวชาญมาพัฒนาอาจให้ผลลัพธ์ที่เร็วแต่ไม่ยั่งยืน เปรียบเสมือนการเพาะชำ เพราะสภาวะในโรงงานหรือธุรกิจที่เปลี่ยนแปลงได้ตลอดเวลาเช่น ความต้องการของตลาด สภาวะของอุปกรณ์ตามอายุการใช้งาน เครื่องจักรใหม่ๆ ที่เพิ่มเข้ามาในระบบ หรือการปรับขั้นตอนการผลิต ทั้งหมดล้วนส่งผลให้โมเดลที่ใช้อยู่ใช้ไม่ได้อีกต่อไป
ดังนั้นหากบุคลากรของโรงงานเองไม่มีส่วนร่วมกับการพัฒนาระบบตั้งแต่ต้น ก็เป็นการยากที่โรงงานจะสามารถบำรุงรักษาและปรับแก้ระบบได้เองอย่างเหมาะสม คำถามที่ตามมาคือ ใครควรรับผิดชอบหน้าที่นี้? IT หรือ OT? นำไปสู่บางเสียงที่ไม่เห็นด้วยกับการใช้ Edge ในอุตสาหกรรม และเสนอให้ใช้ Private Cloud แทนเพื่อให้ความรับผิดชอบนี้ตกอยู่กับฝ่าย IT อย่างชัดเจน เมื่อเรามองวัฒนธรรมในโรงงานส่วนใหญ่ จริงอยู่ที่ OT และ IT ทำงานเป็นเอกเทศจากกันมาก และการรวมกันไม่ใช่เรื่องง่ายด้วยพื้นฐาน องค์ความรู้ และโฟกัสที่ต่างกัน แต่เราต้องไม่ลืมว่าการก้าวไปสู่อุตสาหกรรม 4.0 การบูรณาการ OT และ IT เข้าด้วยกันเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ซึ่งไม่ใช่จะบูรณาการเพียงแค่ระบบ แต่ต้องรวมไปถึงคน ดังนั้นโรงงานต้องวางแนวทางปรับตัวหากต้องการพัฒนาไปสู่การเป็นโรงงานที่อัจฉริยะหรือฉลาดขึ้น โดยอาจเริ่มต้นจากตั้งโปรเจ็คพัฒนา Edge เพื่อติดตามหรือควบคุมกระบวนการใดกระบวนการหนึ่ง และผนึกกำลังคนจากทั้งสองฝั่งให้เข้ามามีส่วนร่วม โดย OT มีบทบาทในการถ่ายทอดองค์ความรู้เฉพาะด้าน หาวิธีการดึงข้อมูลที่เกี่ยวข้องจากเครื่องจักร และนำผลลัพธ์ไปปรับปรุงกระบวนการ ขณะที่ฝ่าย IT รับผิดชอบในการสร้างโมเดล พัฒนาโปรแกรม ออกแบบตำแหน่งที่ตั้งภายในเครือข่ายของโรงงาน และดูแลเครือข่ายและหน่วยเก็บข้อมูล
- ถ้าถามต่อไปว่า “…แล้วควรจะเริ่มจากกระบวนการใด?”
หากมองประสิทธิภาพเป็นหลัก เราสามารถจำแนกได้ว่าแอปพลิเคชันใดเหมาะสมกับการใช้ Edge โดยดูจากเวลาและกำลังประมวลผล แต่ภาคอุตสาหกรรมมีความได้เปรียบในแง่ที่ว่าอุปกรณ์ Edge สำหรับโรงงานสามารถมีขนาดใหญ่และมีประสิทธิภาพสูงได้เพราะ
- 1) ไม่จำเป็นต้องเคลื่อนย้าย
- 2) ความต้องการด้านความน่าเชื่อถือ (Reliability) ดังนั้นเกณฑ์ตัดสินจึงเหลือเพียงเวลาตอบสนองเป็นสำคัญ
รูปข้างล่างแสดงความสัมพันธ์ระหว่างเวลาตอบสนองกับประสิทธิภาพของแอปพลิเคชันต่างๆ ในโรงงานอุตสาหกรรม จะเห็นได้ว่าแอปพลิเคชันเที่ควรเป็น Edge อย่างชัดเจนคือการตรวจวัดและแจ้งเตือนความล้มเหลวของอุปกรณ์หรือเครื่องจักร (ควรจะรวมถึงความผิดปกติที่เกี่ยวข้องกับความปลอดภัยเช่น ไฟไหม้ ก๊าซรั่ว ฯลฯ) ซึ่งก็ไปสอดคล้องกับสิ่งที่โรงงานอุตสาหกรรมการผลิตส่วนใหญ่ให้ความสำคัญเป็นอันดับหนึ่งอยู่แล้ว นั่นคือการลด Downtime [4] เนื่องจากส่งผลเสียหายตีมูลค่าเป็นเม็ดเงินได้โดยตรง
มีการทำนายว่าการใช้งาน Edge จะเพิ่มขึ้นเป็น 75% ภายในปี 2025 [4] แต่ไม่ได้หมายความว่า Cloud จะถึงคราวสูญพันธุ์ เพราะไม่ว่าอุปกรณ์ Edge จะมีสมรรถนะแรงขึ้นมากแค่ไหน ก็ยังไม่สามารถทดแทน Cloud ได้ทั้งหมด ดังนั้นหากไม่มีข้อจำกัดในเรื่องกฎเกณฑ์หรือปัญหาการเชื่อมต่ออินเทอร์เน็ต การใช้ Edge และ Cloud ควบคู่กันเป็นแนวทางที่จะก่อให้เกิดประสิทธิภาพสูงสุด
ตัวอย่างแนวทางการพัฒนาระบบ IoT Edge-Cloud ในภาคอุตสาหกรรม
การพัฒนาระบบ IoT ในโรงงานอุตสาหกรรมไม่จำเป็นจะต้องสำเร็จเบ็ดเสร็จในคราวเดียว แต่สามารถค่อยพัฒนาเพิ่มขึ้นทีละขั้น เพื่อให้ผู้ประกอบการได้ประเมินประโยชน์และความคุ้มค่า และให้โอกาสผู้พัฒนาได้ทยอยเก็บข้อมูลเพื่อนำไปสังเคราะห์โมเดลและปรับปรุงระบบให้มีความเป็นอัตโนมัติเพิ่มขึ้นในขั้นต่อไป ตัวอย่างเช่น การพัฒนาระบบตรวจวัดและแจ้งเตือนความล้มเหลวของเครื่องจักรอาจแบ่งการพัฒนาเป็น 5 ขั้นตอนได้แก่
- 1) Visualization
- รวบรวมพารามิเตอร์ต่างๆ จากเครื่องจักร ไม่ว่าจะด้วยการดึงข้อมูลจากเซนเซอร์ที่อยู่ในเครื่องจักรหรือติดตั้งเซนเซอร์ภายนอกเพิ่มเติม จากนั้นส่งไปยังอุปกรณ์ Edge ซึ่งจะทำหน้าที่แสดงค่าให้ผู้ทำงานได้เห็นสถานะของเครื่องจักรแบบเวลาจริง พร้อมๆ กันกับส่งต่อข้อมูลไปเก็บที่คลาวด์
- 2) Fault Detection and Notification
- เมื่อมีปริมาณข้อมูลเพียงพอ เราสามารถใช้วิธีการทางสถิติหรือ Unsupervised Machine Learning ในการจำแนกสภาวะผิดปกติของเครื่องจักรเพื่อส่งสัญญาณแจ้งเตือน โดยการคำนวณสามารถทำได้ที่ Edge และแจ้งเตือนแบบ local เช่นไฟแจ้งเตือน หรือคำนวณที่คลาวด์และแจ้งเตือนผ่านเครือข่ายอินเทอร์เน็ต เช่น Line เป็นต้น โดยในขั้นนี้เราอาจเพิ่มอินพุตจากวิศวกรหรือช่างที่ดูแลเครื่องจักรเข้าสู่ระบบ เช่นให้ระบุชนิดหรือสาเหตุของความผิดปกติเมื่อเกิดการแจ้งเตือน เพื่อใช้เป็น Label ของข้อมูลเตรียมนำไปฝึกสอนโมเดลแบบ Supervised Machine Learning บนคลาวด์สำหรับการพัฒนาขั้นต่อไป
- 3) Fault Identification
- ฝึกสอนโมเดลแบบ Supervised Learning โดยใช้ทรัพยากรบนคลาวด์ ระบบที่เป็นผลลัพธ์จะมีความสามารถแยกแยะชนิดของความผิดปกติได้ละเอียดขึ้นโดยเลียนแบบ domain expert ผู้ label ข้อมูล
- 4) Fault Prediction
- ใช้ข้อมูลช่วงก่อนเกิดสภาวะผิดปกติในการฝึกสอนระบบให้ทำนายความผิดปกติชนิดต่างๆ ล่วงหน้า และแจ้งเตือน ควรให้วิศวกรหรือช่างสามารถอินพุตเฉลย (ผิด/ถูก) เข้าไปในระบบเพื่อให้เกิดการฝึกฝนต่อเนื่องและปรับปรุงความแม่นยำของการทำนาย
- 5) Automatic Fault Prevention
- กำหนด Action ของระบบสำหรับแต่ละสภาวะผิดปกติที่ทำนายเพื่อป้อนกลับไปจัดการเครื่องจักรโดยไม่ต้องรอให้เกิดความผิดปกติหรือรอให้คนมาแก้ไข ดังนั้นการคำนวณ (Inference) ในขั้นนี้จำเป็นที่จะต้องเกิดที่ Edge เพื่อการตอบสนองที่รวดเร็ว
ตัวอย่างข้างต้นแสดงแนวทางการพัฒนาแบบขั้นบันไดที่แต่ละขั้นเป็นฐานให้กับขั้นถัดไป สิ่งที่สำคัญคือระบบผลลัพธ์ในแต่ละขั้นต้องพร้อมใช้และสร้างคุณค่าเพิ่มให้กับโรงงานได้ในตัวมันเอง ดังนั้นแม้ว่าผู้ประกอบการตัดสินใจหยุดการพัฒนาที่ขั้นใดขั้นหนึ่งไม่ไปต่อจนสุดทาง โรงงานจะยังคงได้รับประโยชน์จากเทคโนโลยี IoT-Edge-Cloud โดยมีระบบเข้ามาช่วยปรับปรุงกระบวนการไว้ใช้ ภายใต้เงื่อนไขการลงทุนที่ผู้ประกอบการเห็นว่าคุ้มค่าเหมาะสม
เอกสารอ้างอิง
- [1] Flexera, “Cloud Computing Trends:2019 State of the Cloud Survey”, https://www.flexera.com/blog/cloud/2019/02/cloud-computing-trends-2019-state-of-the-cloud-survey/, February 27, 2019.
- [2] David Linthicum, Cisco, “Edge Computing vs. Fog Computing: Definitions and enterprise uses”, https://www.cisco.com/c/en/us/solutions/enterprise-networks/edge-computing.html
- [3] Microsoft, “Corporate IoT – a path to intrusion”, https://msrc-blog.microsoft.com/2019/08/05/corporate-iot-a-path-to-intrusion/, August 2019.
- [4] Bryan Tantzen, Cisco, “Connected Machines: Reducing Unplanned Downtime and Improving Service”, https://blogs.cisco.com/manufacturing/connected-machines-reducing-downtime, October 2015.
ดาวน์โหลดเอกสาร