Unticha-Thesis

Unticha-Thesis.md

ผลวิเคราะห์แบบไม่ใช้เครื่องมือรอบที่หนึ่ง

AOBJ-1 วิเคราะห์ว่าแนวทางการออกแบบในอดีตถูกนำมาประเมินอย่างไร

การประเมิน

มีการศึกษาและประเมินระบบเกษตรอัจฉริยะในอดีตว่ามักประสบปัญหาเรื่องระยะการส่งสัญญาณที่ไม่ครอบคลุมพื้นที่การเกษตรขนาดใหญ่

การปรับปรุง

จึงนำเทคโนโลยี LoRa มาใช้เพื่อแก้ปัญหาการส่งข้อมูลในระยะไกลที่มีสิ่งกีดขวาง (เช่น ต้นทุเรียน) แทนการใช้ Wi-Fi หรือ Bluetooth แบบเดิม

AOBJ-2 สรุปข้อมูลด้านประสิทธิภาพ

ระยะทาง

ระบบถูกออกแบบและทดสอบให้ส่งสัญญาณได้ครอบคลุมระยะ 400 เมตร ในพื้นที่จริงที่มีสิ่งกีดขวาง

อัตราการส่งข้อมูล

ใช้แบนด์วิดท์ ขนาด 125 kHz โดยมีความแรงสัญญาณที่รับได้ อยู่ที่ประมาณ -40.8 dBm ซึ่งเพียงพอต่อการรับส่งค่าจากเซ็นเซอร์ ความแม่นยำ เซ็นเซอร์ทุกตัวผ่านการสอบเทียบ เพื่อให้ค่าที่อ่านได้มีความคลาดเคลื่อนน้อยที่สุดก่อนนำไปใช้งานจริง

AOBJ-3 รายละเอียดด้านต้นทุน (Equipment, Installation, Maintenance)

ค่าอุปกรณ์ เลือกใช้ไมโครคอนโทรลเลอร์ ESP32S และโมดูล LoRa SX1278 ซึ่งเป็นอุปกรณ์ที่มีราคาประหยัดแต่ประสิทธิภาพสูง การติดตั้ง ออกแบบระบบให้ใช้พลังงานต่ำ ทำให้ประหยัดงบประมาณด้านระบบจ่ายไฟและง่ายต่อการวางตำแหน่งโหนดในฟาร์ม R2-E1-Q4 ข้อมูลด้านความเชื่อถือได้ ความเชื่อถือได้ มีการคำนวณกำลังสัญญาณทั้งหมดและการสูญเสียข้อมูล ระบบจะสามารถสื่อสารได้โดยไม่ขาดหายแม้จะมีสภาพแวดล้อมที่แปรปรวน ความทนทาน มีการใช้เสาอากาศแบบสปริงและแบบแท่งเพื่อความทนทานในการติดตั้งภายนอกอาคารและรับสัญญาณได้ดีในพื้นที่สวน R2-E1-Q5 แนวทางการบำรุงรักษา ความยากง่าย ระบบถูกออกแบบแยกส่วน ระหว่าง Node และ Gateway ทำให้ง่ายต่อการตรวจซ่อมเมื่อจุดใดจุดหนึ่งเสีย การอัปเดต ใช้การจัดการผ่าน Node-RED ทำให้สามารถปรับแต่งการไหลของข้อมูลได้ง่ายโดยไม่ต้องเขียนโค้ดซับซ้อนใหม่ทั้งหมด R2-E1-Q6 ความสามารถในการขยายขนาด การขยายระบบ โครงสร้างระบบรองรับการเพิ่มจำนวน LoRa Node ได้ในอนาคต หากต้องการขยายพื้นที่ฟาร์มเพิ่มเติม การเพิ่มฟังก์ชัน หน้าเว็บแอปพลิเคชันพัฒนาด้วย NuxtJS ทำให้สามารถเพิ่มเมนูหรือฟีเจอร์การแสดงผลใหม่ ๆ ได้ตามความต้องการของผู้ใช้ R2-E1-Q7 มาตรฐานความปลอดภัย การเข้ารหัส มีระบบสมาชิก ผ่าน Firebase เพื่อควบคุมสิทธิ์การเข้าถึงข้อมูลและการสั่งงานระบบ การป้องกัน ข้อมูลถูกจัดเก็บอย่างปลอดภัยบนระบบ Cloud (InfluxDB และ Google Sheets) ป้องกันการสูญหายของข้อมูลที่จัดเก็บในตัวอุปกรณ์ R2-E1-Q8 ความซับซ้อนในการพัฒนาและการบูรณาการ การบูรณาการ มีความซับซ้อนในระดับปานกลางเนื่องจากต้องเชื่อมโยงเทคโนโลยีหลายส่วนเข้าด้วยกัน (Hardware -> LoRa -> Node-RED -> Cloud -> Web Application) ความท้าทาย ต้องมีการประสานงานระหว่างซอฟต์แวร์ และระบบหลังบ้านเพื่อจัดระเบียบข้อมูลอนุกรมเวลา ให้แสดงผลได้อย่างรวดเร็ว

อุปกรณ์ Bill Of Material (BOM) Description Part Price(Unit/THB) โมดูล LoRa Lora Module SX1278 175 เสาอากาศ Antenna 5 dBi Antenna 433 MHz 120 Microcontroller ESP32S 200 เซ็นเซอร์วัดอุณหภูมิ ความชื้น และความดัน BME 280 200 เซ็นเซอร์วัดอุณหภูมิในอากาศ SHT 30 100 เซ็นเซอร์วัดอุณหภูมิภายในดิน 7 in 1 Soil Sensor 1500 แผงโซลาเซลล์ 6 v 6 w 300 โซลาเซลล์ชาร์จ PWM 30A 150 เซ็นเซอร์วัดความเร็วลม WSS004 1800 วงจรปรับแรงดัน 5V เป็น 12V MT3608 50 โมดูลแปลงข้อมูล แบบ Isolated UART TTL to RS485 RS485 Module 50 แบตเตอรี่ 18650 3.7v 12.7Ah 400

โครงสร้างการรับ-ส่งข้อมูลด้วยเทคโนโลยี LoRa เทคโนโลยี LoRa ถูกนำมาใช้เป็นสื่อกลางหลักในการส่งข้อมูลจากโหนดเซ็นเซอร์ไปยังเกตเวย์ เนื่องจากคุณสมบัติการใช้พลังงานต่ำและความสามารถในการส่งสัญญาณระยะไกล โดยมีรายละเอียด

• 	ความถี่ 433MHz
  

• 	อัตราการส่งข้อมูล 125 kHz
  

• 	แบนด์วิดท์ (Bandwidth) กำหนดค่าตามความเหมาะสมของปริมาณข้อมูลเซ็นเซอร์
  

• 	พลังงานและอัตราแก้ไขข้อผิดพลาด (Transmit Power & Coding Rate)
  Link Budget Calculation = - 40.8 dBm
  

  Path Loss Model ​= 67.2dB Time on Air (ToA) ≈ 0.3495 sec Symbol Rate = 30.5175 symbols/sec Bit Rate = 366.211 bits/sec E = 0.138402 Joules V = 3.3V I = 0.12A P = 0.396W

ขั้นตอนการทำงานของโหนดส่งและโหนดรับ (Packet Transmission) การสื่อสารในระบบจะถูกจัดการในรูปแบบ Packet Transmission แบ่งออกเป็น 2 ส่วน

1.  โหนดส่ง (LoRa Node - Sensor Node)  ทำหน้าที่รวบรวมข้อมูลจากเซ็นเซอร์ (อุณหภูมิ, ความชื้น, ความดัน) แล้วจัดรูปแบบข้อมูล (Data Formatting) เช่น "temp:25.4,hum:60" ก่อนส่งออกไปยังเกตเวย์
   

2.  โหนดรับ (LoRa Gateway)  ทำหน้าที่รับข้อมูลจาก LoRa Node ประมวลผลเบื้องต้น และส่งข้อมูลต่อไปยังเซิร์ฟเวอร์ผ่านระบบอินเทอร์เน็ต
   

การเชื่อมต่อและโพรโทคอลการส่งข้อมูลไปยังเซิร์ฟเวอร์ เมื่อเกตเวย์ได้รับข้อมูล จะทำการส่งต่อข้อมูลไปยังเซิร์ฟเวอร์ผ่านเครือข่ายอินเทอร์เน็ต (Wi-Fi/Ethernet/Cellular) โดยรองรับโพรโทคอลมาตรฐาน

1.  MQTT (Message Queuing Telemetry Transport) ใช้สำหรับการส่งข้อมูลแบบเรียลไทม์ผ่าน Broker (เช่น Mosquitto หรือ HiveMQ) ซึ่งเหมาะสำหรับระบบ IoT ที่ต้องการความเร็วสูงและใช้แบนด์วิดท์ต่ำ
   

2.  HTTP/HTTPS (REST API)  ใช้คำสั่ง POST/GET เพื่อส่งข้อมูลไปยัง API ของเซิร์ฟเวอร์ในกรณีที่ต้องการความปลอดภัยสูงหรือส่งข้อมูลเป็นระยะ
   

การจัดการข้อมูลปลายทาง (Data Management and Visualization) ข้อมูลที่ถูกส่งไปยังเซิร์ฟเวอร์จะถูกดำเนินการตามขั้นตอน

1.  การบันทึกข้อมูล ข้อมูลจะถูกจัดเก็บลงในฐานข้อมูล Google Sheets เพื่อความสะดวกในการจัดการและเรียกดูย้อนหลัง
   

2.  การแสดงผล เว็บแอปพลิเคชันจะดึงข้อมูลจาก Google Sheets มาประมวลผลและแสดงผลในรูปแบบ Dashboard (Line Notify, Firebase)เพื่อให้ผู้ใช้งานสามารถติดตามสถาพแวดล้อมในสวนผลไม้ได้แบบเรียลไทม์
   

ผู้ออกแบบต้องเผชิญกับข้อจำกัดหรือปัญหา ดังตาราง หมวดหมู่ อุปสรรคที่พบหน้างาน ผลกระทบต่อความสำเร็จของโครงการ โครงสร้างพื้นฐาน (Infrastructure) การขัดข้องของเซิร์ฟเวอร์: เซิร์ฟเวอร์ล่มบ่อยครั้งและขาดระบบสำรองข้อมูล ข้อมูลไม่เป็นปัจจุบัน (Stale Data) ส่งผลให้การแจ้งเตือนผิดพลาดและผู้ใช้ขาดความเชื่อถือในระบบ สภาพแวดล้อมเชิงปฏิบัติการ (Operational Context) การถอดสายไฟโดยผู้ใช้: เกษตรกรถอดปลั๊กหรือสายไฟเกตเวย์เนื่องจากความไม่เข้าใจในระบบ ระบบหยุดทำงานโดยสมบูรณ์ (Total System Downtime) และเสี่ยงต่อการเกิดความเสียหายทางกายภาพของพอร์ตเชื่อมต่อ ส่วนต่อประสานผู้ใช้ (User Interface) ช่องว่างทางทักษะดิจิทัล: ผู้ใช้งานไม่คุ้นเคยกับ Web Application แม้ระบบจะแสดงผลได้ถูกต้อง ระบบไม่ถูกนำไปใช้งานจริง (System Rejection) เนื่องจากการเข้าถึงข้อมูลมีความซับซ้อนเกินกว่าทักษะของผู้ใช้ การจัดการความรู้ (Knowledge Management) ขาดคู่มือและสัญลักษณ์: ไม่มีการสื่อสารหน้าที่ของอุปกรณ์ผ่านป้ายเตือนหรือคู่มือที่เข้าใจง่าย เกิดความเข้าใจผิดในการดูแลรักษาอุปกรณ์พื้นฐาน (Maintenance Error) จากตัวผู้ใช้งานเอง

2.บูรณาการและวิพากษ์การวิเคราะห์เชิงปฏิบัติการ (Operational Analysis) และกระบวนการ Validation การประยุกต์ใช้หลักการวิศวกรรมระบบ (Systems Engineering) เพื่อวิเคราะห์ความสอดคล้องระหว่างการออกแบบทางเทคนิคกับความต้องการใช้งานจริง โดยอ้างอิงกรอบแนวคิด Arcadia และมาตรฐานสากล ISO/IEC/IEEE 15288 วิพากษ์สถาปัตยกรรมระดับการวิเคราะห์เชิงปฏิบัติการ (Operational Analysis - Arcadia Layer 1) ความสำคัญของการเข้าใจบริบทผู้ใช้ ข้อมูลจากอุปสรรคหน้างานชี้ให้เห็นว่า แม้ระบบจะใช้เทคโนโลยี LoRa SX1278 ที่สามารถทำ Link Budget ได้ดีถึง -40.8 dBm และส่งสัญญาณได้ไกลกว่า 400 เมตร แต่หากวิศวกรละเลยการวิเคราะห์พฤติกรรมผู้ใช้ (เช่น เกษตรกรถอดสายไฟเนื่องจากไม่ทราบหน้าที่ของอุปกรณ์) จะส่งผลให้ระบบล่ม (System Downtime) โดยสมบูรณ์ และระบบเดิมมีความซับซ้อนในการจัดการสูง ผู้ใช้ต้องใช้ความรู้ทางเทคนิคมากเกินไปและเสียเวลาในการเรียนรู้ระบบ ส่งผลให้ "ภาระงานไม่ลดลง" เกษตรกรยังคงต้องควบคุมงานซ้ำๆ ด้วยตนเอง ซึ่งขัดกับหลักการของระบบอัตโนมัติที่ควรลดภาระและช่วยให้การตัดสินใจเร็วขึ้น การบูรณาการความเข้าใจเชิงปฏิบัติการในระดับ Layer 1 ของ Arcadia วิศวกรต้องเปลี่ยนมุมมองจาก "ระบบต้องส่งข้อมูลอะไร" เป็น "ผู้ใช้ต้องการบรรลุภารกิจใด" เช่น ภารกิจการดูแลทุเรียนอย่างแม่นยำ ซึ่งต้องการข้อมูลที่ต่อเนื่อง (Availability) ดังนั้นการออกแบบจึงต้องบูรณาการระบบสำรองไฟ หรือการออกแบบโครงสร้างกายภาพแบบป้องกันการรบกวน (Tamper-proof) ตั้งแต่ขั้นตอนนี้ กระบวนการยืนยันความถูกต้อง (Validation Process) ตามมาตรฐาน ISO/IEC/IEEE 15288 เพื่อให้มั่นใจว่าวิศวกรรมระบบจะส่งมอบผลลัพธ์ที่เป็นประโยชน์สูงสุด ขั้นตอนการ Validation จะต้องดำเนินการดังนี้ Context-Aware Validation ทดสอบความทนทานต่อความเข้าใจผิดของผู้ใช้ โดยประเมินผลจากการใช้ป้ายเตือนและกล่องหุ้มอุปกรณ์ที่ออกแบบใหม่ ว่าสามารถลดอัตราการถอดสายไฟได้จริง Reliability Validation ยืนยันความต่อเนื่องของข้อมูลผ่านระบบ Cloud และ Firebase เพื่อให้มั่นใจว่าเกษตรกรจะได้รับข้อมูลที่ทันสมัย (Real-time) แม้ระบบเครือข่ายบางส่วนจะขัดข้อง Usability Validation ประเมินความพึงพอใจและการเข้าถึงข้อมูลผ่านช่องทางที่ผู้ใช้ได้ใช้งาน เช่น Line Notify เพื่อลดอุปสรรคด้านทักษะดิจิทัล และสร้างการยอมรับในตัวระบบอย่างยั่งยืน Future-Proofing & Scalability ออกแบบโครงสร้างระบบให้รองรับการเพิ่มเติมเซ็นเซอร์และการบำรุงรักษาที่ง่าย เพื่อเพิ่มมูลค่าทางวิศวกรรมและงานวิจัย Educational & Knowledge Transfer Validation จัดทำคู่มือและป้ายสัญลักษณ์ที่ชัดเจนเพื่อลดความผิดพลาดจากมนุษย์ (Human Error) และทำให้ระบบสามารถขยายขีดความสามารถหรือต่อยอดการศึกษาได้ในอนาคต

3.ผลการวิเคราะห์แบบไม่ใช้เครื่องมือรอบที่สอง (Refined Mission and Operational Analysis) ในการวิเคราะห์รอบที่สองนี้ เป็นการเปลี่ยนผ่านจากปัญหาหน้างาน (Pain Points) ไปสู่การกำหนดภารกิจเชิงวิศวกรรม (Engineering Missions) โดยมุ่งเน้นไปที่การสร้างคุณค่าและ "ประโยชน์ที่ตั้งใจไว้ของผู้ใช้" (Intended Benefits) เพื่อแก้ปัญหาความล้มเหลวที่พบในระบบเดิม 3.1 การวิเคราะห์ภารกิจของผู้ออกแบบ (Mission Analysis) จากอุปสรรคที่รวบรวมมาข้างต้น ผู้ออกแบบในกระบวนการวิศวกรรมย้อนกลับต้องกำหนดขอบเขคใหม่เพื่อตอบโจทย์ผู้ใช้งานจริง ดังนี้ ด้านการลดภาระงานและเพิ่มความคุ้มค่า (Labor Reduction Mission) ระบบต้องถูกออกแบบมาเพื่อลดภาระงานซ้ำๆ ของเกษตรกร ไม่ใช่เพิ่มภาระในการเรียนรู้เทคนิคที่ซับซ้อน ดังนั้นภารกิจหลักคือการสร้างระบบอัตโนมัติที่ช่วยลดเวลาเดินทางไปหน้างาน และให้ผลตอบแทนที่คุ้มค่าเมื่อเทียบกับต้นทุนอุปกรณ์ ด้านการตัดสินใจที่แม่นยำ (Actionable Insight Mission) เปลี่ยนจากการแสดงผล "ข้อมูลดิบ" ที่อ่านยากและล่าช้า ให้กลายเป็นการแสดง "แนวโน้มและคำแนะนำ" (Trends and Recommendations) เพื่อป้องกันความเสียหายต่อผลผลิต เช่น การแจ้งเตือนทันทีเมื่อค่า pH ตก หรือระบบปั๊มน้ำขัดข้อง ด้านความเชื่อมั่นและเสถียรภาพ (System Trustworthiness Mission) แก้ไขปัญหาการหยุดชะงักของระบบและการล่มของเซิร์ฟเวอร์ โดยการออกแบบสถาปัตยกรรมที่มีความเสถียร (Stability) และมีการเชื่อมต่อที่สมบูรณ์ระหว่างฮาร์ดแวร์ คลาวด์ และส่วนติดต่อผู้ใช้ (UI) เพื่อสร้างความมั่นใจในการพึ่งพาระบบอัตโนมัติ

3.2 ตารางสรุปภาระงานและภารกิจก่อนเริ่มงานของนักออกแบบ (Pre-development Mission Matrix) เพื่อให้เห็นภาพรวมของสิ่งที่นักออกแบบต้องเผชิญและต้องจัดการก่อนเริ่มงานพัฒนาจริง สามารถสรุปได้ดังตารางต่อไปนี้

ภารกิจหลัก (Core Missions) อุปสรรคที่ต้องจัดการ (Obstacles to Overcome) ผลลัพธ์เชิงปฏิบัติการที่ต้องการ (Operational Outcomes)

1. Operational Simplicity ความซับซ้อนในการจัดการ, ทักษะเทคนิคสูง, UI สื่อสารไม่ลื่นไหล ผู้ใช้ควบคุมระบบได้โดยไม่ต้องอาศัยทักษะสูง และใช้เวลาเรียนรู้น้อยที่สุด
2. Real-time Response การรับรู้ปัญหาล่าช้า, การเข้าถึงข้อมูลระยะไกลถูกจำกัด ระบบแจ้งเตือนเหตุผิดปกติได้ทันที และตรวจสอบสถานะแบบ Real-time ได้จากทุกที่
3. Academic Integrity การพิสูจน์แนวคิดล้มเหลว, ข้อมูลไม่แม่นยำ, งานวิจัยขาดความน่าเชื่อถือ ข้อมูลมีความแม่นยำสูงพอที่จะสร้างแบบจำลองทางวิชาการและใช้จบการศึกษาได้
4. Future-Proofing จำกัดการขยายขีดความสามารถ, ความล้าหลังทางเทคนิค สถาปัตยกรรมรองรับการเพิ่มเซ็นเซอร์และการต่อยอดวิจัยในอนาคตได้ง่าย
5. Environmental Resilience ระบบล่มบ่อยในสภาพจริง, ข้อจำกัดทางภูมิศาสตร์ ระบบทำงานได้ต่อเนื่องแม้ในพื้นที่ห่างไกลหรือสภาพแวดล้อมที่ไม่แน่นอน

3.3 สรุปผลการวิเคราะห์รอบที่สองในทิศทางวิศวกรรมระบบ ผลจากการวิเคราะห์รอบนี้ชี้ให้เห็นว่า นักออกแบบมีภารกิจที่สำคัญที่สุดคือ "การเปลี่ยนระบบจาก Lab Prototype ให้เป็น Operational Product" วิศวกรต้องไม่เพียงแค่ทำให้เซ็นเซอร์อ่านค่าได้ แต่ต้องทำให้ระบบสามารถ "รักษาหน้าที่ (Function)" ของมันไว้ได้ภายใต้ความไม่แน่นอนหน้างาน ปัญหาความเข้าใจทางวิศวกรรมที่จำกัดในอดีตต้องถูกแทนที่ด้วยการออกแบบที่เน้นความแม่นยำในการวิเคราะห์ และการลดภาระงานจริงของเกษตรกร ซึ่งหัวใจสำคัญเหล่านี้จะถูกนำไปกำหนดเป็น "ข้อกำหนดความต้องการระบบ (System Requirements)" ในหัวข้อถัดไป เพื่อให้มั่นใจว่างานวิจัยจะมีความสมบูรณ์ทางวิชาการและใช้งานได้จริงอย่างยั่งยืน 4.บูรณาการและวิพากษ์การวิเคราะห์ระบบและข้อกำหนดความต้องการระบบ ในหัวข้อนี้เป็นการนำผลการวิเคราะห์เชิงปฏิบัติการมาแปลงเป็นข้อกำหนดเชิงวิศวกรรม เพื่อใช้ในการปรับปรุงและแก้ปัญหาระบบเดิมให้มีความสมบูรณ์ทางวิชาการและใช้งานได้จริง 4.1 นิยามกระบวนการตามมาตรฐาน ISO/IEC/IEEE 15288 ตามมาตรฐาน ISO/IEC/IEEE 15288 กระบวนการ System Requirement & Architecture มีเป้าหมายเพื่อกำหนดความสามารถของระบบที่ต้องมีเพื่อให้ตอบสนองต่อความต้องการของผู้ใช้ โดยต้องมีความชัดเจน วัดผลได้ และสามารถนำไปสร้างเป็นสถาปัตยกรรม (Architecture) ได้จริง วิพากษ์ปัญหาจากอดีต ในวิทยานิพนธ์ฉบับเดิม ข้อกำหนดความต้องการ (Requirements) มักถูกระบุเพียงในเชิงเทคนิค เช่น ต้องส่งข้อมูลผ่าน LoRa ได้ หรือ ต้องแสดงผลบนหน้าเว็บได้ แต่ขาดการวิเคราะห์ Non-functional Requirements เช่น ความเสถียร (Reliability), ความง่ายในการใช้งาน (Usability) และความต่อเนื่องของข้อมูล (Availability) ส่งผลให้ระบบล้มเหลวเมื่อเผชิญกับสภาพการณ์จริง 4.2 วิพากษ์สถาปัตยกรรมระดับการวิเคราะห์ระบบ (System Analysis - Arcadia Layer 2) ในระดับ Layer 2 ของ Arcadia ระบบต้องทำอะไร เพื่อตอบโจทย์ภารกิจในชั้น Operational Analysis โดยเราสามารถวิพากษ์และร่างข้อกำหนดใหม่สำหรับนักวิจัยได้ดังนี้

1. ข้อกำหนดด้านความพร้อมใช้และความต่อเนื่อง (Availability & Continuity) ข้อกำหนดใหม่ ระบบต้องมีกลไกจัดการข้อมูลค้าง (Data Buffering) และรองรับการสลับไปใช้เซิร์ฟเวอร์สำรองอัตโนมัติเมื่อเซิร์ฟเวอร์หลักขัดข้อง เพื่อรับประกันว่าข้อมูลที่แสดงผลจะเป็นข้อมูลปัจจุบัน (Real-time) ตลอดเวลา เหตุผล เพื่อแก้ปัญหา "การล่มของเซิร์ฟเวอร์" และ "การรับรู้ปัญหาล่าช้า" ที่พบในระบบเดิม

2. ข้อกำหนดด้านความทนทานต่อการใช้งาน (Robustness & Human Error Handling) ข้อกำหนดใหม่ ระบบต้องมีการออกแบบส่วนเชื่อมต่อทางกายภาพ (Physical Interface) ที่ป้องกันการถอดสายโดยไม่ตั้งใจ และต้องมีระบบแจ้งเตือน (Alert) เมื่อแหล่งจ่ายไฟหลักถูกตัดการเชื่อมต่อ เหตุผล เพื่อแก้ปัญหา "ผู้ใช้ถอดสายไฟเกตเวย์" เนื่องจากความไม่เข้าใจ

3. ข้อกำหนดด้านความง่ายและการตีความข้อมูล (Usability & Data Actionability) ข้อกำหนดใหม่ ส่วนติดต่อผู้ใช้ (UI) ต้องสรุปข้อมูลดิบให้เป็นรูปแบบ "แนวโน้ม (Trend)" หรือ "สถานะแจ้งเตือน (Alarm)" เช่น การใช้สัญลักษณ์สี (เขียว/เหลือง/แดง) แทนการแสดงเพียงตัวเลข เพื่อให้ผู้ใช้ตัดสินใจได้ทันทีโดยไม่ต้องมีความรู้ทางเทคนิคสูง เหตุผล เพื่อแก้ปัญหา "ความซับซ้อนในการจัดการ" และ "การตีความข้อมูลยาก"

4. ข้อกำหนดด้านการเชื่อมต่อและการขยายระบบ (Connectivity & Scalability) ข้อกำหนดใหม่ สถาปัตยกรรมซอฟต์แวร์ต้องเป็นแบบ Modular ที่แยกส่วนการรับข้อมูล (Data Acquisition) ออกจากส่วนแสดงผล (Visualization) เพื่อให้รองรับการเพิ่มเซ็นเซอร์ชนิดใหม่ได้ในอนาคตโดยไม่ต้องแก้ไขโครงสร้างหลัก เหตุผล เพื่อแก้ปัญหา "การจำกัดการขยายขีดความสามารถ" และ "ความล้าหลังทางเทคนิค" 4.3 สรุปข้อกำหนดความต้องการระบบสำหรับงานวิจัยใหม่ เพื่อให้งานวิจัยมีความสมบูรณ์ทางวิชาการและผ่านเกณฑ์การประเมิน วิศวกรต้องกำหนดความต้องการระบบที่ครอบคลุมมิติต่างๆ ดังนี้: หมวดหมู่ความต้องการ ข้อกำหนดที่ต้องปฏิบัติ (System Requirements) การตอบโจทย์วิศวกรรมย้อนกลับ Functional ระบบต้องแสดงสถานะการทำงานของปั๊มน้ำและค่า pH แบบ Real-time ผ่าน Line Notify ลดภาระงานและเพิ่มความเร็วในการตอบสนอง Reliability อัตราความสำเร็จในการส่งข้อมูล (Packet Delivery Ratio) ต้องไม่ต่ำกว่า 95% ในระยะ 400 เมตร สร้างความเชื่อมั่นในการพึ่งพาระบบอัตโนมัติ Maintainability ระบบต้องรองรับการอัปเดตซอฟต์แวร์และตรวจสอบสถานะอุปกรณ์จากระยะไกล (Remote Monitoring) ลดการเดินทางไปหน้างานและค่าใช้จ่ายแฝง Academic Quality ข้อมูลที่จัดเก็บใน Database ต้องมีความละเอียดและแม่นยำเพื่อใช้สร้างแบบจำลองแนวโน้มได้ เพิ่มความน่าเชื่อถือและความสมบูรณ์ทางวิชาการ

5. ผลการวิเคราะห์แบบไม่ใช่เครื่องมือรอบที่ 3 (Technical & Requirement-Based Analysis) ในรอบที่ 3 นี้ เป็นการประเมินระบบเชิงลึกโดยใช้ข้อมูลทางเทคนิคที่ปรากฏในผลงานเดิม มาตรวจสอบร่วมกับข้อกำหนดความต้องการระบบ (System Requirements) ที่ได้วิเคราะห์ไว้ในหัวข้อก่อนหน้า เพื่อหาคำตอบว่าระบบตอบสนองวัตถุประสงค์เชิงวิศวกรรมได้เพียงใด 5.1 การตอบวัตถุประสงค์การวิเคราะห์เชิงเทคนิคอ้างอิงข้อกำหนดระบบ หัวข้อประเมิน ข้อมูลเชิงเทคนิค (Technical Evidence) การตอบสนองต่อ System Requirements

6. ประสิทธิภาพ (Performance) จากการทดสอบพบว่า LoRa SX1278 ทำค่า RSSI ได้ -40.8 dBm ที่ระยะ 400 เมตร บนแบนด์วิดท์ 125 kHz ผ่านเกณฑ์: ตอบโจทย์ด้านความครอบคลุมพื้นที่เกษตรกรรม (Connectivity Requirement) แม้จะมีสิ่งกีดขวางเป็นต้นทุเรียน

7. ความเชื่อถือได้ (Reliability) ใช้ ESP32S ควบคุม และมีระบบ Sleep Mode เพื่อประหยัดพลังงาน กึ่งผ่านเกณฑ์: ฮาร์ดแวร์มีความเสถียรแต่ยังขาดการจัดการ Data Buffering เมื่อเซิร์ฟเวอร์ล่มตามที่ระบุในข้อกำหนด Reliability

8. ต้นทุน (Cost) ใช้ BOM (Bill of Materials) ราคาประหยัด และลดต้นทุนระบบจ่ายไฟด้วยการออกแบบ Low Power ผ่านเกณฑ์: ตอบโจทย์ด้านการลงทุนที่คุ้มค่า (Economic Requirement) สำหรับเกษตรกรรายย่อย

9. ความง่ายในการบำรุงรักษา (Maintainability) ปัจจุบันยังต้องเข้าหน้างานเพื่อแก้ไข Code หรือถอดอุปกรณ์ลงมา ไม่ผ่านเกณฑ์: ขัดกับข้อกำหนดด้าน Remote Monitoring ที่ระบุไว้ในข้อ 4 ทำให้มีภาระงานในการบำรุงรักษาสูง

10. ความปลอดภัย (Security) ข้อมูลถูกส่งไปยัง Firebase และ Line Notify ผ่านการจัดการสิทธิ์สมาชิก ผ่านเกณฑ์: ตอบโจทย์ด้านความเป็นส่วนตัวของข้อมูลผู้ใช้เบื้องต้น แต่อาจต้องเพิ่มการเข้ารหัสในระดับ Node

11. ความขยายระบบ (Scalability) โครงสร้างซอฟต์แวร์ปัจจุบัน (NuxtJS/Firebase) ยังผูกติดกันแน่น ไม่ผ่านเกณฑ์: ไม่ตอบโจทย์ข้อกำหนดด้าน Modular Design ทำให้การเพิ่มเซ็นเซอร์ชนิดใหม่ทำได้ยากและซับซ้อน

12. การตอบสนองเชิงปฏิบัติการ (Operational Response) การรับรู้ปัญหาล่าช้าเมื่อเซิร์ฟเวอร์ล่มหรือเกตเวย์ถูกถอดปลั๊ก ไม่ผ่านเกณฑ์: ขัดกับข้อกำหนด Real-time Response ซึ่งเป็นหัวใจสำคัญในการป้องกันผลผลิตเสียหาย

5.2 การวิเคราะห์ช่องว่างเชิงวิศวกรรม (Engineering Gap Analysis) จากการวิเคราะห์รอบที่ 3 พบว่าระบบมีความโดดเด่นในด้าน "ฮาร์ดแวร์และการรับส่งสัญญาณ (Connectivity)" แต่ยังมีช่องว่างขนาดใหญ่ (Gap) ในส่วนของ "ความสมบูรณ์ของสถาปัตยกรรม (Architectural Integrity)" ดังนี้:

1.   ขาดการจัดการข้อยกเว้น (Exception Handling) ระบบไม่ได้ถูกออกแบบมาเพื่อรองรับสถานการณ์ที่ "ไม่ปกติ" เช่น เซิร์ฟเวอร์ล่มหรือการกระทำผิดพลาดของมนุษย์ ทำให้ความน่าเชื่อถือในสภาพจริงต่ำ
   

2.   ความไม่แม่นยำในการวิเคราะห์แนวโน้ม แม้เซ็นเซอร์จะผ่านการสอบเทียบ (Calibration) แต่การที่ข้อมูลขาดช่วง (Data Gap) จากปัญหาเครือข่าย ทำให้ไม่สามารถสร้างแบบจำลอง (Modeling) ที่แม่นยำตามเกณฑ์วิชาการได้
   

3.   ส่วนต่อประสานที่ยังไม่ตอบโจทย์เกษตรกร แม้จะมี Dashboard แต่ข้อมูลยังเป็นข้อมูลดิบที่ตีความยาก ทำให้เกษตรกรยังต้องใช้เวลาวิเคราะห์ด้วยตนเองเหมือนเดิม ไม่ได้ช่วยลดภาระงาน (Labor Reduction) อย่างแท้จริง
   

5.3 บทสรุปการประเมินรอบที่ 3 ผลการวิเคราะห์รอบนี้ยืนยันว่า วิศวกรรมย้อนกลับ (Reverse Engineering) ในขั้นตอนต่อไป จะต้องมุ่งเน้นไปที่การ "ปิดช่องว่าง" ระหว่างฮาร์ดแวร์ที่ทำงานได้ กับซอฟต์แวร์ที่ต้องทำงานได้อย่างชาญฉลาดและทนทาน โดยต้องนำข้อมูลด้านประสิทธิภาพ LoRa ที่ดีอยู่แล้ว ไปบูรณาการกับระบบจัดการข้อมูลที่มีความยืดหยุ่นสูงกว่าเดิม เพื่อให้บรรลุเป้าหมายสูงสุดของวิทยานิพนธ์

6. บูรณาการและวิพากษ์สถาปัตยกรรมเชิงตรรกะ (Logical Architecture) และสถาปัตยกรรมเชิงกายภาพ (Physical Architecture) 6.1 นิยามของ Arcadia Layer 3 และ 4 Layer 3: Logical Architecture (LA): คือการกำหนดว่าระบบต้องมี "ฟังก์ชัน" อะไรบ้างและฟังก์ชันเหล่านั้นทำงานร่วมกันอย่างไร โดยไม่สนใจว่าจะเป็นอุปกรณ์ยี่ห้อไหน (เช่น ฟังก์ชันการจัดการพลังงาน, ฟังก์ชันการสื่อสารข้อมูล) เป้าหมายคือการจัดกลุ่มงาน (Functional Decomposition) ให้เป็นระบบ Layer 4: Physical Architecture (PA): คือการนำฟังก์ชันจาก LA มาลงในอุปกรณ์จริง (Node, Sensor, Gateway) และระบุวิธีเชื่อมต่อทางกายภาพ รวมถึงโปรโตคอลที่ใช้จริง (ESP32, LoRa SX1278, MQTT, Firebase) 6.2 ตารางแจกแจงส่วนประกอบทางกายภาพ (Physical Components List) จากการแกะข้อมูลระบบเดิม (จากไฟล์ R2) สามารถสรุปชิ้นส่วนที่ถูกนำมาใช้ประกอบเป็นระบบได้ดังนี้ ส่วนประกอบ (Component) รายละเอียด/รุ่น (Description) หน้าที่ตามที่ระบุในโครงการ Microcontroller ESP32S ประมวลผลหลักและเชื่อมต่อ Wi-Fi/LoRa LoRa Module SX1278 (433MHz) รับ-ส่งข้อมูลระยะไกล (Point-to-Point) Sensors Soil Moisture, Temp/Humid, pH วัดค่าสภาพแวดล้อมในสวนทุเรียน Power System Solar Cell + Lithium Battery จ่ายพลังงานให้โหนดเซ็นเซอร์ Cloud Service Firebase / Google Sheets จัดเก็บข้อมูลและจัดการสิทธิ์ผู้ใช้ User Interface NuxtJS / Line Notify แสดงผล Dashboard และแจ้งเตือน

ภาพที่ ไดอะแกรมการเชื่อมต่ออุปกรณ์ 6.3 วิพากษ์จุดอ่อน: สิ่งที่หายไปจาก System Architecture เมื่อพิจารณาจากตารางชิ้นส่วนและ Diagram ของระบบเดิม จะพบว่าสิ่งที่ปรากฏเป็นเพียง "การเชื่อมต่อทางฮาร์ดแวร์" แต่ขาด สถาปัตยกรรมระบบ ที่สมบูรณ์ วิพากษ์จุดอ่อนและอุปสรรคในการทำวิศวกรรมย้อนกลับ ขาดมุมมองความสัมพันธ์เชิงตรรกะ (Missing Logical Perspectives) ในเล่มต้นฉบับไม่มีการระบุว่า "หากฟังก์ชัน A ล้มเหลว ฟังก์ชัน B จะต้องทำอย่างไร" เช่น หาก LoRa ขัดข้อง ระบบมีกลไกสำรองข้อมูลในระดับตรรกะอย่างไร การขาดมุมมองนี้ทำให้เมื่อจะทำวิศวกรรมย้อนกลับ เราจะไม่รู้ Logic การตัดสินใจภายในของเครื่อง (Internal State Machine) รู้เพียงแค่ว่าสายไฟเชื่อมกันอย่างไรเท่านั้น ปัญหาการยึดติดกันแน่นเกินไป (Tight Coupling) การออกแบบเน้นไปที่ Physical Layer โดยตรง (เช่น เขียน Code ให้ ESP32 คุยกับ Firebase ทันที) โดยไม่มีชั้น Abstraction หรือ Middleware มาคั่น ทำให้เมื่อต้องการขยายระบบหรือเปลี่ยนเซ็นเซอร์ (Scalability) ทำได้ยากมาก เพราะต้องแก้ไข Code ทั้งระบบใหม่ทั้งหมด ขาดมุมมองด้านความทนทาน (Lack of Robustness View) สถาปัตยกรรมไม่ได้ออกแบบมาเพื่อรองรับ "พฤติกรรมที่ผิดปกติ" (Exception Handling) เช่น การที่ผู้ใช้ถอดปลั๊กหรือ Server ล่ม ซึ่งในเชิงสถาปัตยกรรมที่ดี ควรมีชั้นของ Physical Security หรือ Redundancy ที่ชัดเจนใน Diagram แต่ในระบบเดิมกลับไม่มีการระบุไว้ ความยากในการทำวิศวกรรมย้อนกลับ (Reverse Engineering Difficulty) เนื่องจากขาดข้อมูลในชั้น Logical Architecture (Layer 3) ทำให้วิศวกรที่มาทำงานต่อไม่สามารถเข้าใจ "เจตจำนงของการออกแบบ" (Design Intent) ได้ชัดเจน ต้องเสียเวลาไปกับการแกะ Code (Reverse Code) เพื่อหาตรรกะการทำงาน แทนที่จะสามารถวิเคราะห์จากสถาปัตยกรรมระดับบนได้

ภาพที่ Flowchart การทำงานของระบบการรับ-ส่งข้อมูล สรุปการวิพากษ์ ระบบเดิมมีเพียง Physical Layout แต่ขาด System Architecture อย่างสิ้นเชิง การนำอุปกรณ์มาต่อกัน (Component Integration) ไม่เท่ากับการทำวิศวกรรมระบบ จุดอ่อนที่สำคัญที่สุดคือการขาดมุมมองด้านการจัดการความล้มเหลว (Fault Management) และการขยายระบบ (Scalability) ซึ่งเป็นเหตุผลสำคัญที่ทำให้ระบบล่มบ่อยและเกษตรกรไม่สามารถพึ่งพาระบบได้ในระยะยาว