BMS, PCS, และ EMS สื่อสารกันอย่างไรใน BESS เชิงพาณิชย์? อินเตอร์เฟซ, โปรโตคอล, และความรับผิดชอบในการรวมระบบ

อุปกรณ์สามตัวสามารถสนับสนุนโปรโตคอลเดียวกันและยังไม่สามารถสื่อสารได้

ใน BESS เชิงพาณิชย์ BMS รายงานสถานะแบตเตอรี่และขีดจำกัดการทำงาน PCS แปลงพลังงานและดำเนินการคำสั่งชาร์จ/ปล่อย และ EMS ตัดสินใจว่าเมื่อใดที่พลังงานนั้นควรเคลื่อนที่ตามวัตถุประสงค์ของไซต์ การสื่อสารมักใช้ CAN, RS485, Modbus RTU/TCP หรืออินเตอร์เฟซที่ใช้ Ethernet แต่การแชร์ชื่อโปรโตคอลไม่ได้พิสูจน์ความเข้ากันได้ - อุปกรณ์ต้องตกลงเกี่ยวกับแผนที่ข้อมูล การปรับขนาด ที่อยู่ เวลา อำนาจควบคุม ลอจิกเตือนภัย และพฤติกรรมความปลอดภัย

สถาปัตยกรรม BESS ของ DOE แสดงให้เห็นว่าเป็นชั้นควบคุมที่แตกต่างกัน: BMS นั่งใกล้กับโมดูลแบตเตอรี่ PCS ควบคุมการแปลงพลังงาน ขณะที่ EMS ทำงานที่ระดับการควบคุมไซต์

ลำดับชั้นนั้นเข้าใจได้ง่ายขึ้นหากเราติดตามคำสั่งหนึ่งคำสั่ง

EMS บอกว่า 100 kW PCS ไม่สามารถเชื่อฟังได้ง่ายๆ

จินตนาการว่าความต้องการในโรงงานใกล้ถึงขีดจำกัดสูงสุด

EMS คำนวณ:

การปล่อย BESS ที่ต้องการ = 100 kW

มันส่งคำขอพลังงานไปยัง PCS

แต่ก่อนที่จะส่งมอบ 100 kW โซ่ควบคุมมีความคิดเห็นอีกอย่าง

BMS อาจรายงานในขณะนี้ว่า:

SoC: 24%

การปล่อยสูงสุดที่อนุญาต: 62 kW

อาจเป็นเพราะ SoC แรงดันเซลล์ อุณหภูมิ กระแส หรือข้อจำกัดอื่นๆ ของแบตเตอรี่

ผลลัพธ์ที่ถูกต้องไม่ใช่:

คำสั่ง EMS = 100 kW → ผลลัพธ์ PCS = 100 kW

PCS ต้องทำงานภายในขอบเขตที่อนุญาตของแบตเตอรี่

ในเชิงแนวคิด:

BMS → “สิ่งที่แบตเตอรี่ได้รับอนุญาตให้ทำ”

EMS → “สิ่งที่ไซต์ต้องการให้แบตเตอรี่ทำ”

PCS → “สิ่งที่การแปลงพลังงานสามารถดำเนินการได้จริง”

การแยกนี้เป็นพื้นฐานสำหรับการควบคุม BESS ที่ปลอดภัย

CAN และ Modbus เป็นภาษา ไม่ใช่ข้อตกลง

นี่คือจุดที่ข้อกำหนดการจัดซื้อมักจะมีความหวังมากเกินไป

ผู้จัดจำหน่าย A กล่าว:

การสื่อสาร BMS: CAN.

ผู้จัดจำหน่าย B กล่าว:

PCS รองรับ CAN.

ผู้ซื้อเขียน:

เข้ากันได้.

ยังไม่ใช่.

CAN อธิบายกลไกการสื่อสาร อุปกรณ์ยังต้องการการกำหนดข้อความที่เข้ากันได้.

ปัญหาเดียวกันนี้เกิดขึ้นกับ Modbus.

อุปกรณ์สองเครื่องอาจรองรับ Modbus RTU ทั้งคู่ แต่ไม่เห็นด้วยเกี่ยวกับ:

ที่อยู่รีจิสเตอร์

ประเภทข้อมูล

ลำดับไบต์

การปรับขนาด

สิทธิ์ในการอ่าน/เขียน

รหัสอุปกรณ์

อัตราการอัปเดต

รหัสเตือนภัย

ค่าของรีจิสเตอร์500ไม่มีความหมายจนกว่าทุกคนจะเห็นด้วยว่ามันหมายถึง:

500 A

50.0 A

หรืออย่างอื่นทั้งหมด.

นั่นคือเหตุผลที่ฉันขอโปรโตคอลการสื่อสารจริงหรือแผนที่รีจิสเตอร์ก่อนการใช้งาน.

ดอว์นีซผลิตภัณฑ์แสดงให้เห็นว่าหน้าต่างเชื่อมต่อขึ้นอยู่กับขอบเขตของระบบ

ผลิตภัณฑ์แบตเตอรี่เชิงพาณิชย์ทุกตัวไม่ได้เปิดเผยอินเทอร์เฟซเดียวกัน.

Dawnice'sBS09-225-D 225.07 kWh ระบบด้าน DC, ตัวอย่างเช่น, เผยแพร่CAN/RS485อินเทอร์เฟซและระบุว่า CAN เป็นวิธีการสื่อสาร BMS.

ระบบที่รวมอยู่BS07-265-ES-X 125 kW/265.3 kWhแทนที่จะเผยแพร่Modbus TCP/RTUและความพร้อมใช้งาน EMS/cloud.

และข้อมูลจำเพาะของตู้คอนเทนเนอร์ 1 MW/2.089 MWh ของ Dawnice ระบุการสื่อสาร EMS ผ่านRS485 และ TCP/IP.

ความแตกต่างเหล่านั้นมีเหตุผล

แบตเตอรี่ด้าน DC ต้องการอินเตอร์เฟซกับ PCS ภายนอก

ระบบแบบรวมทุกอย่างมีความสัมพันธ์ระหว่างแบตเตอรี่–PCS มากขึ้นภายใน

โรงงานที่บรรจุในตู้คอนเทนเนอร์จึงต้องการการสื่อสารระดับสูงกับ EMS, การตรวจสอบ, มิเตอร์, และอาจรวมถึง SCADA ของไซต์

สถาปัตยกรรมการสื่อสารตามขอบเขตของระบบ.

มิเตอร์เป็นส่วนหนึ่งของการสนทนาด้วย

การตัดยอดพีคให้ตัวอย่างที่ดีแก่เรา

มิเตอร์ของไซต์รายงาน:

การนำเข้าไฟฟ้าจากกริด = 680 kW

เป้าหมายของ EMS คือ:

600 kW

EMS คำนวณประมาณ:

ต้องการการปล่อย 80 kW

และส่งคำสั่ง

PCS ดำเนินการตามนั้น

มิเตอร์รายงานสภาพกริดใหม่ ทำให้ EMS ปรับเปลี่ยนได้อีกครั้ง

ดังนั้นวงจรจริงจึงใกล้เคียงกับ:

มิเตอร์ไซต์ → EMS → PCS ↔ BMS → PCS → มิเตอร์ไซต์

นี่คือเหตุผลที่ CT ที่กลับด้านหรือการปรับขนาดมิเตอร์ที่ไม่ถูกต้องสามารถทำให้แบตเตอรี่ที่มีสุขภาพดีทำงานผิดปกติ

EMS กำลังตัดสินใจอย่างมีเหตุผลจากข้อมูลที่ไม่ดี

สถาปัตยกรรมการสื่อสาร BESS ของ DOE ก็รวมถึงมิเตอร์, EMS, PCS, BMS, การควบคุมสิ่งแวดล้อม, HMI, ระบบป้องกันอัคคีภัย, และโครงสร้างพื้นฐานเครือข่าย แทนที่จะถือว่าการสื่อสารแบตเตอรี่เป็นสาย CAN สายเดียว

ความล้มเหลวในการสื่อสารต้องการสถานะปลอดภัยที่กำหนด

ตอนนี้ถอดปลั๊กเครือข่าย EMS

สิ่งที่ควรเกิดขึ้น?

คำตอบนั้นอยู่ในข้อกำหนดการออกแบบ

ขึ้นอยู่กับการใช้งานและสถาปัตยกรรมที่ได้รับการอนุมัติ ระบบอาจ:

ดำเนินการตามคำสั่งล่าสุดที่ถูกต้องเป็นระยะเวลาที่กำหนด

กลับไปควบคุม PCS ในท้องถิ่น

ลดกำลังไฟ

หยุดการชาร์จ/การปล่อย

ส่งสัญญาณเตือน

หรือเข้าสู่สถานะที่ปลอดภัยที่กำหนดไว้ล่วงหน้าอื่น

คำถามเดียวกันนี้ใช้ได้เมื่อ:

การสื่อสารระหว่าง BMS–PCS ล้มเหลว

ข้อมูลมิเตอร์หายไป

การเชื่อมต่อกับคลาวด์หายไป

SCADA ไม่สามารถใช้งานได้

ความล้มเหลวเหล่านี้ไม่เท่ากัน

การขัดข้องของคลาวด์ไม่ควรมีผลลัพธ์เหมือนกับการสูญเสียขีดจำกัดของ BMS ที่จำเป็นสำหรับการทำงานของแบตเตอรี่ที่ปลอดภัย

ดังนั้น ตารางการสูญเสียการสื่อสารควรกำหนด:

ลิงก์ที่สูญหาย → หมดเวลา → การดำเนินการสำรอง → สัญญาณเตือน → สภาพการฟื้นฟู

ก่อน SAT

แมทริกซ์ความรับผิดชอบมีความสำคัญมากกว่ารายการโปรโตคอล

ฉันจะใส่ตารางนี้ลงในข้อตกลงทางเทคนิค:

คอลัมน์สุดท้ายป้องกันการสนทนาที่เกิดขึ้นบ่อยในระหว่างการติดตั้ง:

ผู้จัดหาแบตเตอรี่:

“ระบบ CAN ของเราทำงาน”

ผู้จัดหา PCS:

“ระบบ CAN ของเราทำงาน”

ผู้รวมระบบ:

“แล้วทำไมพวกเขาถึงไม่สื่อสารกัน?”

ห้องสมุดสนับสนุนทางเทคนิคของ Dawnice มีขั้นตอนการสื่อสารเฉพาะสำหรับการรวมกันเช่นSolis 50 kW PCS กับการจัดเก็บของ Dawnice 100/143 kWhและMegarevo 500 kW PCS กับการจัดเก็บ C&I 860 kWh ของ Dawnice, ซึ่งแสดงให้เห็นว่าการจับคู่ของอุปกรณ์จริงต้องการการกำหนดค่าและการรวมระบบที่มากกว่าการระบุโปรโตคอลในแผ่นข้อมูล

สิ่งที่ฉันจะทดสอบก่อนที่จะเรียกว่าหน้าต่างเชื่อมต่อเสร็จสมบูรณ์

ฉันไม่ถือว่าการสื่อสารได้รับการติดตั้งเพราะอุปกรณ์แต่ละชิ้นแสดงไอคอนสีเขียว

ในระหว่าง FAT/SAT ฉันต้องการพิสูจน์ว่า:

ค่าของ SoC และอุณหภูมิถูกปรับขนาดอย่างถูกต้อง

ขีดจำกัดการชาร์จ/การปล่อยของ BMS ถึง PCS

คำสั่งพลังงาน EMS ถูกดำเนินการอย่างถูกต้อง

ทิศทางและการปรับขนาดของมิเตอร์ถูกต้อง

สัญญาณเตือนจะถูกส่งไปยัง HMI/SCADA ที่ตั้งใจ

เวลาประทับตรงกัน

พฤติกรรมการสูญเสียการสื่อสารตรงตามข้อกำหนด

ระบบสามารถฟื้นตัวได้อย่างถูกต้องหลังจากการสื่อสารกลับมา

สำหรับโครงการ Ruibit/Dawnice ความรับผิดชอบนั้นควรจะถูกแช่แข็งก่อนการจัดส่งเมื่อมี PCS, EMS, มิเตอร์ หรือระบบ SCADA ภายนอกเกี่ยวข้อง Dawnice ระบุว่าระบบ C&I ของตนผลิตภัณฑ์สนับสนุนอินเตอร์เฟซมาตรฐานรวมถึง CAN, RS232 และ RS485 และให้บริการการรวมระบบและการว่าจ้างสำหรับโครงการ C&I ขนาดใหญ่

รายการโปรโตคอลบอกฉันว่าการสนทนาใดอาจเป็นไปได้

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

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

1. BMS, PCS และ EMS สื่อสารกันใน BESS เชิงพาณิชย์ได้อย่างไร?

ระบบBMS ให้สถานะแบตเตอรี่, SoC, สัญญาณเตือน, และขีดจำกัดการทำงาน,EMS กำหนดพลังงานที่ต้องการในการชาร์จหรือปล่อย, และPCS ดำเนินการคำสั่งการแปลงพลังงานในขณะที่เคารพขีดจำกัดของแบตเตอรี่และระบบ.

2. โปรโตคอลการสื่อสารใดที่มักใช้ใน BESS เชิงพาณิชย์?

อินเตอร์เฟซทั่วไปประกอบด้วยCAN, RS485, Modbus RTU/TCP, และการสื่อสารที่ใช้ Ethernet. การสนับสนุนโปรโตคอลเดียวกันไม่ได้รับประกันความเข้ากันได้ระหว่างอุปกรณ์โดยอัตโนมัติ

3. ทำไมอุปกรณ์ BESS สองตัวจึงสามารถรองรับ CAN หรือ Modbus แต่ยังล้มเหลวในการสื่อสาร?

พวกเขาอาจใช้การกำหนดข้อความ, ที่อยู่รีจิสเตอร์, การปรับขนาด, ลำดับไบต์, ID อุปกรณ์, อัตราการอัปเดต, รหัสสัญญาณเตือน, หรือโลจิกการควบคุมที่แตกต่างกัน. แผนที่โปรโตคอล/รีจิสเตอร์จริงจึงต้องได้รับการตรวจสอบ

4. จะเกิดอะไรขึ้นหากการสื่อสารของ BMS, PCS หรือ EMS หายไป?

ระบบควรเข้าสู่สถานะที่กำหนดไว้ล่วงหน้าตามอินเตอร์เฟซที่ล้มเหลว ข้อกำหนดควรกำหนดเวลาหมด, การดำเนินการสำรอง, พฤติกรรมสัญญาณเตือน, และเงื่อนไขการฟื้นตัวสำหรับการสื่อสารที่ล้มเหลวแต่ละครั้ง

5. ใครเป็นผู้รับผิดชอบในการรวม BMS–PCS–EMS?

ความรับผิดชอบควรได้รับการกำหนดอย่างชัดเจนในเอกสารโครงการ ผู้ซื้อควรกำหนดว่าใครเป็นเจ้าของแต่ละอินเตอร์เฟซระหว่างแบตเตอรี่, PCS, EMS, มิเตอร์, SCADA, แพลตฟอร์มระยะไกล, และเครือข่ายไซต์ก่อนการ FAT และการว่าจ้าง