ปลากะพงกลางแผ่นดิน: สร้างระบบให้อาหารอัตโนมัติสำหรับปลาทะเลที่ไกลจากทะเล

จันทบุรีมีชายฝั่งทะเล นครราชสีมาไม่มี — น้ำทะเลที่ใกล้ที่สุดอยู่ห่างออกไปเกือบห้าชั่วโมงโดยรถยนต์ แต่ถ้าอยากทำ ก็สามารถเลี้ยงปลากะพงขาว (Lates calcarifer) ในโรงเรือนแถวโคราชแล้วขายเป็นปลาทะเลสดจริง ๆ ได้ ปัญหาไม่เคยอยู่ที่ชีววิทยาของปลา ปลากะพงเป็นปลาที่ทนต่อการเปลี่ยนความเค็มได้กว้าง (euryhaline) — ปรับตัวได้ตั้งแต่น้ำทะเลเข้มข้นเต็มที่ไปจนถึงน้ำจืดโดยไม่มีปัญหา ซึ่งเป็นเหตุผลที่ปากแม่น้ำในไทยเลี้ยงปลาชนิดนี้กันอยู่แล้ว ปัญหาจริง ๆ อยู่ที่บ่อเลี้ยงไม่มีน้ำทะเลปริมาณมหาศาลคอยเจือจางความผิดพลาดทุกครั้งให้เหมือนทะเลจริง

ในทะเลเปิด ความผิดพลาดจากการให้อาหาร แอมโมเนียพุ่ง หรือออกซิเจนละลายน้ำตก จะถูกน้ำนับล้านลิตรที่ไหลผ่านกระชังเจือจางไปเอง แต่ในระบบบ่อหมุนเวียนน้ำ (RAS) ขนาด 120 ตร.ม. มันไม่เจือจางให้ มันแย่ลงเรื่อย ๆ จนกว่าจะ "มีคนสังเกตเห็น" — ซึ่งในความเป็นจริงมักหมายถึงปลาตายเป็นชุด ไม่ใช่การแจ้งเตือนบนแดชบอร์ด

นี่คือปัญหาระบบควบคุม ไม่ใช่ปัญหาการเลี้ยงปลา

สวทช./ศูนย์เทคโนโลยีโลหะและวัสดุแห่งชาติ (MTEC) พิสูจน์เรื่องชีววิทยาและเศรษฐศาสตร์มาแล้ว: ระบบ RAS อัตโนมัติที่เลี้ยงปลากะพงความหนาแน่น 40 กก./ลบ.ม. ใน 6 บ่อ ให้ผลผลิตประมาณ 340 กก./เดือน พร้อมประหยัดน้ำได้ถึง 94% เทียบกับระบบน้ำไหลผ่าน ตลาด RAS ในเอเชียตะวันออกเฉียงใต้คาดว่าจะเติบโตจากราว 1.7 พันล้านดอลลาร์สหรัฐในปี 2569 เป็น 2.6 พันล้านดอลลาร์สหรัฐภายในปี 2578 ทั้งความต้องการตลาดและชีววิทยาเป็นเรื่องที่ตอบได้แล้ว

สิ่งที่ยังไม่นิ่ง — สิ่งที่ล้มเหลวอย่างเงียบ ๆ ในระบบ RAS บนแผ่นดินส่วนใหญ่ — คือชั้นควบคุม (control layer) มีค่า 4 ตัวที่ต้องคุมให้อยู่ในช่วงแคบตลอดเวลา โดยไม่มีทะเลคอยให้อภัยความผิดพลาด:

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

โจทย์นี้มีรูปแบบเดียวกับพื้นโรงงาน: เซนเซอร์กระจายจุด วงจรควบคุมที่ต้องทำงานตามตารางเวลาไม่ว่าจะมีคนเฝ้าดูอยู่หรือไม่ และความล้มเหลวที่มองไม่เห็นจนกว่าจะแพงแล้ว นี่คือเหตุผลเดียวกับที่เราเคยเขียนเรื่องความแตกแยกของโปรโตคอล OT บนพื้นโรงงาน และการตรวจวัดความร้อนในเตาสุญญากาศ — เซนเซอร์ ตรรกะควบคุม และการแจ้งเตือน เป็นศาสตร์เดียวกันไม่ว่าภาชนะนั้นจะบรรจุโลหะหลอมเหลวหรือน้ำทะเล

ระบบต้องทำอะไรบ้างจริง ๆ

flowchart TD
    SENS["เซนเซอร์  
DO · pH · แอมโมเนีย · ความเค็ม · อุณหภูมิ"] --> CTRL["วงจรควบคุม  
Threshold logic · ตารางให้อาหาร"]
    CTRL --> FEED["เครื่องให้อาหารอัตโนมัติ  
ตามเวลา / ตามความต้องการ"]
    CTRL --> AER["เครื่องเติมอากาศ / ปั๊ม  
แก้ไข DO"]
    CTRL --> ALERT["แจ้งเตือน  
SMS / LINE ถึงผู้ดูแล"]
    SENS --> LOG[("บันทึกข้อมูลตามเวลา  
Read-only")]
    CTRL --> LOG
    FEED --> LOG

    classDef sense fill:#0f172a,stroke:#eab308,stroke-width:1px,color:#fde68a;
    classDef core fill:#082f49,stroke:#38bdf8,stroke-width:1px,color:#bae6fd;
    classDef act fill:#052e16,stroke:#22c55e,stroke-width:1px,color:#bbf7d0;
    classDef data fill:#134e4a,stroke:#14b8a6,stroke-width:1px,color:#99f6e4;
    class SENS sense;
    class CTRL core;
    class FEED,AER,ALERT act;
    class LOG data;

ไม่มีอะไรซับซ้อนเกินไปในนี้ มันคือชุดเซนเซอร์ (DO, pH, แอมโมเนีย, ความเค็ม, อุณหภูมิ — โพรบประเภทเดียวกับที่ใช้ในระบบบำบัดน้ำและการตรวจวัดกระบวนการอุตสาหกรรม) วงจรควบคุมที่ตัดสินใจว่าเมื่อไรควรให้อาหารและเมื่อไรควรแก้ไขค่า ชั้นสั่งงาน (มอเตอร์ให้อาหาร เครื่องเติมอากาศ ปั๊ม) และเส้นทางแจ้งเตือนที่ไปถึงมือถือผู้ดูแลก่อนที่ปลาจะตาย ไม่ใช่หลังจากนั้น จุดที่พลาดกันบ่อยคือมองเครื่องให้อาหารเป็นแค่ตัวตั้งเวลาโดด ๆ แทนที่จะเป็นหนึ่งใน output ของวงจรควบคุมที่อ่านค่าคุณภาพน้ำอยู่ตลอดเวลา — นั่นคือความต่างระหว่างเครื่องให้อาหารอัตโนมัติกับระบบเพาะเลี้ยงสัตว์น้ำอัตโนมัติ

สแตกซอฟต์แวร์ แบบเจาะจง

ทุกชั้นในไดอะแกรมข้างบนแมปกับชุดเครื่องมือ Python ที่จงใจเลือกให้ "น่าเบื่อ" และเข้าใจง่าย เพราะของแปลกใหม่คือสิ่งที่ทำให้เจอบั๊กในวงจรควบคุมผ่านการที่ปลาตายยกบ่อ

ชั้น Edge (ต่อบ่อ ทำงานบนอุปกรณ์หน้างาน) โพรบวัด DO, pH และความเค็มระดับอุตสาหกรรมมักส่งสัญญาณแบบ analog (4–20 mA) หรือ Modbus RTU มากกว่าจะมี digital bus ที่สะอาด ดังนั้นตัวควบคุม edge จึงเป็น Raspberry Pi รัน Python ปกติ หรือ ESP32 รัน MicroPython แล้วแต่เกรดของโพรบ:

• pymodbus — โพลข้อมูลจากโพรบ Modbus RTU/TCP (เอาต์พุตทั่วไปของทรานสมิตเตอร์ DO/pH ระดับอุตสาหกรรม)
• smbus2 / ไดรเวอร์ adafruit-circuitpython-* — สำหรับบอร์ดเซนเซอร์ I²C ราคาถูกที่ไม่มี Modbus
• gpiozero หรือ RPi.GPIO — ควบคุมมอเตอร์เครื่องให้อาหาร รีเลย์เครื่องเติมอากาศ และปั๊มโดสสารเคมี
• asyncio — รันการโพลเซนเซอร์ วงจรควบคุม และการสั่งงานพร้อมกันบนอุปกรณ์เดียวโดยไม่บล็อกกัน

Transport ค่าที่อ่านได้จากเซนเซอร์และเหตุการณ์สั่งงานถูกส่งผ่าน MQTT แทนที่จะโพลแบบจุดต่อจุด — รูปแบบเดียวกับที่ใช้บนพื้นโรงงาน และเป็นวิธีแก้ปัญหา "ห้าภาษาถิ่น" ของโปรโตคอลที่กระจัดกระจาย: รวมทุกอย่างให้พูดภาษาเดียวกันตั้งแต่ชั้น edge อย่าบังคับให้ backend ต้องพูด Modbus เอง

• paho-mqtt — ส่งค่าที่อ่านได้จากตัวควบคุมแต่ละบ่อไปยัง Mosquitto broker ในเครือข่ายท้องถิ่น
• orjson — serialize ข้อมูลเซนเซอร์แบบเร็วสำหรับส่งผ่านเครือข่าย

วงจรควบคุม ส่วนนี้ต้องทำงานในเครื่องเองและรอผลจากเครือข่ายไม่ได้:

# ทำงานบนตัวควบคุม edge ของแต่ละบ่อ ทุก 30 วินาที
async def control_tick(tank: TankState) -> None:
    reading = await read_sensors(tank)          # pymodbus / smbus2
    if reading.do_mg_l < tank.thresholds.do_min:
        await actuate("aerator", tank.id, on=True)
    if reading.salinity_ppt < tank.thresholds.sal_min:
        await actuate("brine_dose", tank.id, ml=tank.dose_step)
    if feed_scheduler.due(tank):                 # ควบคุมด้วย APScheduler
        await actuate("feeder", tank.id, grams=tank.feed_ration)
    await publish(reading, tank)                 # paho-mqtt → broker
    if reading.breaches_critical(tank.thresholds):
        await alert(tank, reading)                # LINE Notify / Twilio

• APScheduler — คุมเวลาให้อาหารต่อบ่อ (ทั้งตามเวลาที่กำหนดและตามความต้องการ ไม่ใช่แค่ช่วงเวลาคงที่)
• pydantic — ตรวจสอบความถูกต้องของข้อมูลเซนเซอร์และค่า threshold ทุกครั้งก่อนจะปล่อยให้สั่งงานอุปกรณ์ได้

Backend และแดชบอร์ด ใช้ Django 5 สแตกเดียวกับที่ simpliDepot ใช้อยู่แล้ว โดยแยกข้อมูล time-series ออกจากฝั่งธุรกรรมแทนที่จะยัดรวมไว้ในตารางเดียวกัน:

• Django + djangorestframework — จัดการค่า config ของบ่อ ค่า threshold ตารางให้อาหาร และการจัดการฟาร์ม/ไซต์
• Django Channels — ส่งค่าที่อ่านได้แบบเรียลไทม์ไปยังแดชบอร์ดผู้ดูแลผ่าน WebSocket
• influxdb-client (หรือ TimescaleDB ผ่าน psycopg2/asyncpg) — เก็บข้อมูล time-series ความถี่สูงที่ไม่ควรอยู่ในสคีมา OLTP เชิงสัมพันธ์
• celery — งานตามตารางเวลา สรุปอัตราแลกเนื้อ (FCR) รายวัน และงานที่ไม่จำเป็นต้องรันทุก 30 วินาที

การแจ้งเตือน ใช้ requests เรียก LINE Notify หรือ Twilio API — ช่องทางเดียวกับที่ simpliDepot ใช้แจ้งเตือนเกษตรกรและผู้ซื้ออยู่แล้ว ผู้ดูแลจึงได้รับแจ้งเตือนบ่อในแอปที่เปิดอยู่แล้วเป็นประจำ

ก่อนจะให้ระบบไปแตะปลาจริง วงจรควบคุมจะถูกทดสอบกับบ่อจำลองก่อน — ใช้ simpy จำลองเหตุการณ์แบบ discrete-event สำหรับพลวัตของอาหาร/DO/แอมโมเนีย หรือใช้ numpy จำลองค่าเซนเซอร์แบบง่าย เพื่อพิสูจน์ตรรกะ threshold กับข้อมูลการแกว่งของค่าตลอดหนึ่งฤดูกาลก่อนจะปล่อยให้ทำงานเองข้ามคืนโดยไม่มีคนเฝ้า

มาตรฐานที่ต้องคิดถึงตั้งแต่ต้น: กรมประมงและ GAP

ระบบควบคุมที่แม่นยำไม่ได้มีไว้แค่กันปลาตาย แต่ยังเป็นฐานของการขอ ใบอนุญาตเพาะเลี้ยงสัตว์น้ำ และ มาตรฐานการปฏิบัติทางการเพาะเลี้ยงสัตว์น้ำที่ดี (GAP) จากกรมประมง ซึ่งผู้ซื้อรายใหญ่และผู้ส่งออกมักเรียกร้องเป็นเงื่อนไขซื้อขาย บันทึก time-series ของ DO อุณหภูมิ และความเค็มที่ระบบเก็บไว้อัตโนมัติทุก 30 วินาที คือหลักฐานย้อนหลังชนิดเดียวกับที่ตรวจประเมิน GAP ต้องการ — แทนที่จะเป็นสมุดจดมือที่กรอกตอนเช้าครั้งเดียวแล้วหวังว่าค่ากลางคืนจะไม่มีปัญหา

ทำไมเรื่องนี้ถึงอยู่ข้าง ๆ simpliDepot ไม่ใช่แทนที่

simpliDepot เริ่มจากระบบรับซื้อทุเรียนแล้วขยายไปสู่สินค้าเกษตรแบบเกรดใด ๆ ก็ได้ — ยางพารา ปาล์ม วัสดุรีไซเคิล — เพราะรูปแบบพื้นฐาน (รับเข้า ให้เกรด FIFO บันทึกราคาจ่าย) ไม่ได้ผูกกับชนิดผลไม้จริง ๆ หลักการเดียวกันนี้ใช้ได้ในทิศทางกลับกันที่นี่: ระบบควบคุม RAS บนแผ่นดินไม่ใช่ "ผลิตภัณฑ์เพาะเลี้ยงสัตว์น้ำ" จริง ๆ แต่มันคือระบบตรวจวัดและควบคุมอุตสาหกรรม (หมวดเดียวกับ IMCS) ที่เล็งไปที่ภาชนะบรรจุน้ำทะเลแทนพื้นโรงงาน เซนเซอร์ วงจรควบคุม การแจ้งเตือน และการบันทึกประวัติ ล้วนเป็นองค์ประกอบเดียวกับที่เราสร้างให้สภาพแวดล้อม OT อยู่แล้ว เพียงแค่ต่อสายไปยังชุดตัวสั่งงานที่ต่างออกไป

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

คำถามที่พบบ่อย

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

ต้องใช้เกลือทะเลสังเคราะห์ หรือใช้น้ำเค็มขนส่งมาได้
ใช้ได้ทั้งสองแบบในทางปฏิบัติ ขึ้นอยู่กับต้นทุนและโลจิสติกส์ของแต่ละไซต์ ไม่ใช่ข้อจำกัดทางเทคนิคของระบบควบคุม ระบบต้องคุมความเค็มให้อยู่ในช่วงไม่ว่าจะมาจากแหล่งไหน — เป็นโจทย์เรื่องเซนเซอร์และการโดสสารเหมือนกัน

ถ้าอินเทอร์เน็ตที่ไซต์ชนบทล่มจะเกิดอะไรขึ้น
วงจรควบคุม (เซนเซอร์ → threshold → สั่งงาน) ต้องทำงานในเครื่องเองไม่ว่าเครือข่ายจะเป็นอย่างไร — ตัดสินใจเปิดเครื่องเติมอากาศไม่ได้รอ cloud round-trip เครือข่ายมีไว้สำหรับบันทึกข้อมูล แจ้งเตือน และตรวจสอบระยะไกล ไม่ใช่สำหรับวงจรที่กระทบความปลอดภัยโดยตรง เป็นข้อจำกัดแบบ offline-first เดียวกับที่เราวางแผนไว้สำหรับไซต์ depot ที่อินเทอร์เน็ตชนบทไม่เสถียร

นี่เป็นผลิตภัณฑ์จริงแล้วหรือยัง
นี่เป็นแนวคิดที่เรากำลัง scope อยู่บนพื้นฐานเศรษฐศาสตร์ RAS ที่พิสูจน์แล้วและงาน IMCS/OT monitoring ที่เรามีอยู่ ยังไม่ใช่แพลตฟอร์มที่เปิดให้ใช้งานจริง ถ้าคุณกำลังทำหรือวางแผนทำ RAS บนแผ่นดินและอยากคุยว่าระบบควบคุมสำหรับไซต์ของคุณต้องทำอะไรบ้าง ติดต่อเรา

แหล่งข้อมูล: ระบบ RAS อัตโนมัติสำหรับการเพาะเลี้ยงแบบเข้มข้น สวทช./MTEC; ตลาด RAS เอเชียตะวันออกเฉียงใต้ โดย GM Insights; การเพาะเลี้ยงปลากะพงขาว/บารามุนดี โดย Global Seafood Alliance