แบตเตอรี่ยังอยู่ในสภาพดี ข้อความไม่สามารถส่งผ่านได้
ความล้มเหลวในการสื่อสาร BMS ใน BESS เชิงพาณิชย์มักจะไม่เพียงพอที่จะเปลี่ยน BMS เริ่มต้นโดยการระบุว่าเส้นทางการสื่อสารใดที่ล้มเหลว จากนั้นตรวจสอบพลังงานและสถานะการทำงาน การเดินสายจริง ประเภทของอินเทอร์เฟซ การสิ้นสุด การตั้งค่าโหนด/ที่อยู่ การเลือกโปรโตคอล ความเข้ากันได้ของเฟิร์มแวร์ และการจราจรข้อความจริง สัญญาณเตือนการสื่อสารและความผิดปกติของแบตเตอรี่เป็นปัญหาการวินิจฉัยที่แตกต่างกันสองอย่าง
ฉันเคยเห็นช่างเทคนิคเสียเวลาหลายชั่วโมงเพราะ HMI แสดงข้อผิดพลาดในการสื่อสาร BMSและทุกคนเริ่มพูดคุยเกี่ยวกับแร็คแบตเตอรี่ทันที
คำถามแรกของฉันง่ายกว่า:
ใครหยุดพูดกับใคร?
ใน BESS เชิงพาณิชย์ "การสื่อสาร BMS" อาจหมายถึง BMS แร็คไปยัง BMS หลัก BMS ไปยัง PCS BMS ไปยัง EMS หรือเส้นทางจากระบบจัดเก็บพลังงานไปยังการตรวจสอบ SCADA/cloud ปัจจุบันของ Dawnice C&Iผลิตภัณฑ์แสดงให้เห็นถึงความหลากหลาย: BS09-225-D ของมันเผยแพร่CAN/RS485การสื่อสาร ขณะที่ BS07-265-ES-X แสดงรายการModbus TCP/RTUและความพร้อมใช้งาน EMS/cloud.Dawnice BS09-225-D Dawnice BS07-265-ES-X
อาการกว้างๆ เหมือนกัน
ข้อผิดพลาดที่อาจแตกต่างกันมาก
08:17 — PCS บอกว่า "ไม่มี BMS"
พิจารณาแบตเตอรี่เชิงพาณิชย์ขนาด 400 kWh ที่เชื่อมต่อกับ PCS
ระบบได้รับการว่าจ้างอย่างถูกต้องเมื่อวันศุกร์
เช้าวันจันทร์:
HMI แบตเตอรี่:ปกติ
แรงดันไฟฟ้าแร็ค:มีอยู่
อุณหภูมิเซลล์:น่าเชื่อถือ
PCS:การสื่อสาร BMS หายไป
EMS:แบตเตอรี่ไม่พร้อมใช้งาน
Contactor:เปิด
สิ่งล่อใจคือการพูดว่า:
"BMS ล้มเหลว."
ฉันจะไม่พูดแบบนั้น.
ถ้า HMI แบตเตอรี่ในพื้นที่ยังอ่านเซลล์และอุณหภูมิได้ถูกต้อง BMS ก็ชัดเจนว่าทำงานได้อย่างน้อยบางส่วน ขอบเขตที่ล้มเหลวอาจอยู่ระหว่าง BMS และ PCS.
นั่นเปลี่ยนการสอบสวนทันที.
ฉันจะบันทึกเวลาที่เกิดสัญญาณเตือนก่อนที่จะสัมผัสอะไร จากนั้นเปรียบเทียบกับบันทึกเหตุการณ์ของ BMS, PCS และ EMS.
ถ้านาฬิกาทั้งสามไม่ตรงกันหกนาที ฉันจะแก้ปัญหานั้นด้วย การวิเคราะห์สาเหตุรากฐานจะดูยุ่งเหยิงอย่างน่าประหลาดเมื่อไทม์ไลน์เหตุการณ์ไม่น่าเชื่อถือ.
ฉันตรวจสอบสิ่งที่น่าเบื่อก่อนเปิดแล็ปท็อป
สายสื่อสารที่เปลี่ยนใหม่ได้แก้ไขข้อผิดพลาดมากกว่าการวิเคราะห์โปรโตคอลที่สง่างาม.
ก่อนที่จะเปลี่ยนซอฟต์แวร์ ฉันต้องการรู้ว่า:
BMS มีไฟและตื่นตัวเต็มที่หรือไม่?
ใช้พอร์ตการสื่อสารที่ถูกต้องหรือไม่?
ตัวเชื่อมต่อเสียบแน่นหรือไม่?
ได้มีการตรวจสอบพินของสายเคเบิลหรือไม่ ไม่ได้สมมติจากตัวเชื่อมต่อ RJ45?
CAN-H/CAN-L หรือ RS485 A/B เชื่อมต่อถูกต้องหรือไม่?
การป้องกัน/การกราวด์สอดคล้องกับการออกแบบที่ได้รับการอนุมัติหรือไม่?
สายเคเบิลได้รับความเสียหาย ถูกบีบ ขยาย หรือเปลี่ยนเส้นทางข้างตัวนำไฟฟ้าที่มีเสียงรบกวนหรือไม่?
RJ45 เป็นอันตรายโดยเฉพาะทางจิตวิทยา อุปกรณ์สองตัวสามารถใช้ตัวเชื่อมต่อที่เหมือนกันและการกำหนดพินที่แตกต่างกันโดยสิ้นเชิง.
คู่มือแบตเตอรี่ของ Dawnice เอง ตัวอย่างเช่น กำหนดพินการสื่อสาร CAN และ RS485 แยกกันแทนที่จะบอกว่าหมายเลขสายเครือข่ายทั่วไปสามารถใช้แทนกันได้.คู่มือแบตเตอรี่ Dawnice
รูปทรงของตัวเชื่อมต่อไม่ใช่โปรโตคอล.
มันไม่ใช่แม้แต่การกำหนดการเดินสาย.
ถ้าชั้นวางหลายชั้นหายไปในครั้งเดียว ฉันจะหยุดตำหนิชั้นวางแต่ละชั้น
รูปแบบความล้มเหลวบอกฉันว่าควรมองที่ไหน.
| อาการ | พื้นที่แรกที่ฉันจะตรวจสอบ |
|---|---|
| ตู้หนึ่งหายไป | พลังงานตู้, สายเคเบิล, ที่อยู่, BMS ท้องถิ่น |
| ตู้ทั้งหมดหายไป | BMS หลัก, บัสทั่วไป, แหล่งจ่ายไฟ |
| BMS HMI ทำงานแต่ PCS สูญเสียแบตเตอรี่ | ลิงก์ BMS–PCS / โปรโตคอล |
| PCS เห็นแบตเตอรี่แต่ EMS ไม่เห็น | เครือข่าย PCS/EMS หรือการแมพเรจิสเตอร์ |
| การสื่อสารล้มเหลวเป็นระยะ | การสิ้นสุด, เสียงรบกวน, คอนเนคเตอร์, ท็อปโลยี |
| ความล้มเหลวเกิดขึ้นหลังการอัปเดตเฟิร์มแวร์ | โปรโตคอล/เฟิร์มแวร์/การกำหนดค่า |
| ค่าผิดพลาดแต่ลิงก์ยังออนไลน์อยู่ | แผนที่การลงทะเบียน, การปรับขนาด, ลำดับไบต์, การแมพ |
ตารางนั้นไม่ใช่ทางเลือกแทนคู่มือระบบ.
มันเป็นวิธีการหลีกเลี่ยงการเปลี่ยนโมดูลแบตเตอรี่ที่มีสุขภาพดีสี่ตัวเพราะลิงค์การสื่อสารที่แชร์ล้มเหลว.
CAN และ RS485 ล้มเหลวแตกต่างกัน
ฉันไม่ถือว่า "สายสื่อสาร" เป็นหมวดหมู่เดียว.
ในเครือข่าย CAN ฉันต้องการตรวจสอบโทโพโลยี ขั้ว CAN-H/CAN-L ความเป็นขั้ว อัตราบิต การกำหนดค่าโหนด การสิ้นสุด และว่ามีเฟรมที่คาดหวังอยู่จริงหรือไม่.
ในเครือข่าย RS485/Modbus RTU ฉันเริ่มคิดเกี่ยวกับความเป็นขั้ว A/B ที่อยู่ของทาส อัตราบอด พาริตี้ บิตหยุด การแมพลงทะเบียน และการสิ้นสุด.
ระบบองค์กร Modbusรักษาโปรโตคอลปัจจุบันและข้อกำหนดการใช้งานสายอนุกรม สายอนุกรมของมันจัดการการสิ้นสุดและการขั้วเป็นคุณสมบัติของการออกแบบเครือข่าย ไม่ใช่ตัวต้านทานที่สุ่มเพิ่มเมื่อการสื่อสารไม่เชื่อถือได้.
นี่คือจุดที่ฉันเริ่มระมัดระวังเกี่ยวกับสิ่งที่คุ้นเคย:
"วัด 60 โอห์มและคุณเสร็จแล้ว."
การสิ้นสุด 120 โอห์มสองตัวที่เชื่อมขนานกันสามารถผลิตประมาณ 60 โอห์มบนบัสที่ไม่มีพลังงาน แต่การอ่านค่านั้นมีความหมายเฉพาะสำหรับโทโพโลยีที่ออกแบบมาแบบนั้นและวัดภายใต้เงื่อนไขที่เหมาะสม.
มันไม่ได้พิสูจน์ว่าที่อยู่, อัตราบอด, โปรโตคอลหรือการแมพข้อมูลถูกต้อง.
หมายเลขที่มีประโยชน์หนึ่งหมายเลข ไม่ใช่การวินิจฉัย.
LED การสื่อสารสีเขียวอาจยังคงหลอกคุณ
สมมติว่าลิงก์ทางกายภาพดูมีสุขภาพดี.
เฟรมกำลังเคลื่อนที่.
PCS ยังคงปฏิเสธที่จะทำงาน.
ตอนนี้ฉันเคลื่อนที่ขึ้นไปในสแต็ค.
BMS และ PCS ต้องเห็นพ้องกันในมากกว่าการส่งสัญญาณไฟฟ้า ขึ้นอยู่กับสถาปัตยกรรม พวกเขาอาจต้องการการกำหนดที่เข้ากันได้สำหรับ:
ระบบบนชิป
SoH
แรงดัน/กระแสของแพ็ค
กระแสชาร์จสูงสุด
กระแสปล่อยสูงสุด
การเปิด/ปิดการชาร์จ/ปล่อย
สถานะสัญญาณเตือน
สถานะของคอนแทคเตอร์
ขีดจำกัดอุณหภูมิ
การเต้นของหัวใจ/การตรวจสอบ
บัส CAN สามารถสมบูรณ์แบบทางไฟฟ้าในขณะที่ PCS กำลังฟังชุดข้อความที่แตกต่างกัน.
เช่นเดียวกัน, มาสเตอร์ Modbus สามารถสื่อสารกับสลับได้สำเร็จในขณะที่อ่านรีจิสเตอร์ที่ผิด.
นั่นคือเหตุผลที่ "รองรับ CAN" หรือ "รองรับ Modbus" ไม่ใช่คำแถลงเกี่ยวกับความเข้ากันได้.
มันบอกฉันเกี่ยวกับครอบครัวของภาษา.
ไม่ใช่ว่าทั้งสองอุปกรณ์เข้าใจการสนทนาเดียวกัน.
การเลือกโปรโตคอลเป็นข้อบกพร่องที่แท้จริง ไม่ใช่รายละเอียดการตั้งค่า
นี่คือเหตุผลหนึ่งที่ฉันชอบตรวจสอบการกำหนดค่าก่อนที่จะเปลี่ยนฮาร์ดแวร์.
คู่มืออินเวอร์เตอร์ Dawnice, ตัวอย่างเช่น, ระบุข้อผิดพลาดในการสื่อสาร BMS [58]และแนะนำช่างเทคนิคให้ตรวจสอบทั้งสายเคเบิลการสื่อสารและว่าโปรโตคอลการสื่อสารแบตเตอรี่ลิเธียมที่กำหนดไว้นั้นตรงกับแบตเตอรี่หรือไม่.คู่มืออินเวอร์เตอร์ Dawnice
ตรรกะการแก้ไขปัญหานั้นขยายไปเกินกว่าผลิตภัณฑ์หนึ่ง.
สมมติว่าวิศวกรที่รับผิดชอบการติดตั้งเลือก:
โปรโตคอลแบตเตอรี่ 03
แทนที่จะเป็น:
โปรโตคอลแบตเตอรี่ 08
สายเคเบิลสมบูรณ์แบบ.
BMS อยู่ในสภาพดี.
PCS อยู่ในสภาพดี.
ระบบยังคงไม่ทำงาน.
ไม่มีอะไร "เสียหาย."
การตั้งค่าผิด.
สำหรับโครงการเชิงพาณิชย์ Ruibit/Dawnice ฉันจึงจะแช่แข็งการสื่อสาร BMS–PCS ที่ได้รับการอนุมัติพร้อมกับ BOM ไฟฟ้า: รุ่นแบตเตอรี่/BMS ที่แน่นอน, โมเดล PCS, โปรโตคอล, อินเทอร์เฟซ, ชุดพารามิเตอร์ และรุ่นเฟิร์มแวร์.
การเปลี่ยนเฟิร์มแวร์อาจเป็นการเปลี่ยนส่วนประกอบแม้ว่าจะไม่มีไขควงสัมผัสตู้.
การสื่อสารที่เกิดขึ้นเป็นระยะคือข้อบกพร่องที่ฉันให้ความสำคัญมากที่สุด
การเชื่อมต่อที่ตายสนิทมักจะง่ายกว่า.
การเชื่อมต่อที่ไม่ต่อเนื่องสามารถผ่าน FAT, อยู่รอดในการติดตั้ง และจากนั้นล้มเหลวเมื่อไซต์ร้อน, โหลดหนัก, หรือมีเสียงรบกวนทางไฟฟ้า.
จินตนาการว่าการสื่อสารที่ขาดหายไปปรากฏขึ้นเฉพาะเมื่อ PCS เกิน 80% พลังงาน.
เวลานั้นสำคัญ.
ฉันจะตรวจสอบการจัดเส้นทางและการรบกวนทางแม่เหล็กไฟฟ้าก่อนที่จะตำหนิซอฟต์แวร์แบบสุ่ม.
หากปัญหาเกิดขึ้นทุก 20 วินาทีไม่ว่าจะมีพลังงานหรือไม่, ฉันอาจมองไปที่การตั้งเวลา heartbeat/watchdog.
หากมันเกิดขึ้นหลังจากเพิ่มชั้นที่ห้า, ฉันจะตรวจสอบโทโพโลยี, ที่อยู่ และการสิ้นสุด.
หากมันเริ่มขึ้นทันทีหลังจากการปรับปรุงเฟิร์มแวร์ 3.12, ฉันต้องการหมายเลขรุ่นก่อนหน้าก่อนที่ใครจะทำการอัปเดตอีก.
เงื่อนไขที่ทำให้เกิดข้อผิดพลาดเป็นหลักฐาน.
อย่าลบมันโดยการรีบูตทุกอย่างก่อน.
คำสั่งการวินิจฉัยของฉันออกแบบมาเพื่อป้องกันการเดาที่มีค่าใช้จ่ายสูง
โดยปกติฉันทำงานจากภายนอกเข้ามา:
1. กำหนดขอบเขตการสื่อสารที่ล้มเหลว
BMS–ชั้น? BMS–PCS? PCS–EMS? EMS–SCADA?
2. รักษาหลักฐาน
รหัสเตือน, เวลาที่บันทึก, ภาพหน้าจอ, รุ่นเฟิร์มแวร์ และการเปลี่ยนแปลงล่าสุด.
3. ตรวจสอบสถานะการทำงาน
แหล่งจ่ายไฟ, สถานะ BMS, คอนแทคเตอร์, สัญญาณเตือนท้องถิ่น.
4. ตรวจสอบชั้นทางกายภาพ
สายเคเบิล, พินเอาท์, ขั้วบวกขั้วลบ, คอนเนคเตอร์, ท็อปอโลยี, การสิ้นสุด, การป้องกัน.
5. ตรวจสอบการตั้งค่าการสื่อสาร
อินเตอร์เฟส, รหัสโหนด, อัตราบอด, อัตราบิต, การตรวจสอบความถูกต้องและการเลือกโปรโตคอล.
6. ตรวจสอบชั้นข้อมูล
เฟรม, แผนที่รีจิสเตอร์, การปรับขนาด, การเต้นของหัวใจและการแลกเปลี่ยนคำสั่ง/สถานะ.
7. ตรวจสอบประวัติการเปลี่ยนแปลง
เฟิร์มแวร์, ส่วนประกอบที่เปลี่ยน, การเปลี่ยนแปลงพารามิเตอร์และการปรับเปลี่ยนเครือข่าย.
ฉันไม่ข้ามไปที่ขั้นตอนที่ 6 เพราะการวิเคราะห์โปรโตคอลไม่สามารถซ่อมแซมคอนเนคเตอร์ที่หลวมได้.
ฉันไม่หยุดที่ขั้นตอนที่ 4 เพราะการต่อเนื่องไม่ได้พิสูจน์ความเข้ากันได้.
ข้อบกพร่องจะถูกแก้ไขเมื่อพฤติกรรมของระบบถูกแก้ไข
การทำให้สัญญาณเตือนการสื่อสารหายไปไม่ใช่เกณฑ์การยอมรับของฉัน.
หลังจากการซ่อมแซม, ฉันต้องการยืนยันว่า PCS รับข้อมูลแบตเตอรี่ที่เชื่อถือได้และเคารพขีดจำกัดของ BMS.
ถ้า BMS ลดกระแสชาร์จที่อนุญาตเพราะอุณหภูมิแบตเตอรี่สูงขึ้น, PCS จะปฏิบัติตามหรือไม่?
ถ้าการอนุญาตการปล่อยถูกยกเลิก, พลังงานจะหยุดจริงหรือไม่?
SoC จะถึง EMS อย่างถูกต้องหรือไม่?
มีสัญญาณเตือนปรากฏทางไกลหรือไม่?
การสื่อสารจะกลับคืนอย่างถูกต้องหลังจากการรีสตาร์ทที่ควบคุมหรือไม่?
มีการจัดเรียงเวลาอย่างถูกต้องหรือไม่?
Dawnice ปัจจุบันระบุว่าระบบ C&I ของตนสนับสนุนการตรวจสอบและวินิจฉัยทางไกลผ่านอินเตอร์เฟสรวมถึง CAN, RS485 และแพลตฟอร์มการตรวจสอบที่เกี่ยวข้อง, และเผยแพร่บทเรียนการเชื่อมต่อการสื่อสารเฉพาะสำหรับการรวมแบตเตอรี่/PCS ของ C&I.Dawnice FAQ ฝ่ายสนับสนุนทางเทคนิคของ Dawnice
สำหรับผู้ซื้อ B2B, ข้อสุดท้ายนี้มีความสำคัญมากกว่าที่ฟังดู.
อย่าซื้อเพียงแบตเตอรี่และ PCS.
ซื้อความสัมพันธ์การสื่อสารที่ได้รับการตรวจสอบระหว่างพวกเขา, โดยมีเวอร์ชัน, การตั้งค่าและความรับผิดชอบในการสนับสนุนที่บันทึกไว้.
เพราะเมื่อ BESS กล่าว "การสื่อสาร BMS ล้มเหลว," ความผิดพลาดที่มีค่าใช้จ่ายคือการสมมติว่าส่วนประกอบแรกที่ระบุในสัญญาณเตือนคือส่วนประกอบที่ล้มเหลว.
ค้นหาการสนทนาที่ขัดข้องก่อน. เปลี่ยนฮาร์ดแวร์เป็นอันดับสอง.
คำถามที่พบบ่อย
1. ทำไม BMS ของฉันถึงไม่สื่อสารกับ PCS?
สาเหตุทั่วไป ได้แก่การเดินสายหรือพินเอาท์ที่ไม่ถูกต้อง, ขั้วบวกขั้วลบของ CAN/RS485, การเลือกโปรโตคอลที่ผิด, การตั้งค่าที่อยู่, การสิ้นสุด, ความไม่เข้ากันของเฟิร์มแวร์, สายเคเบิลที่เสียหาย, หรือการกำหนดค่าพอร์ตการสื่อสาร..
2. สัญญาณเตือนการสื่อสาร BMS หมายความว่า BMS ล้มเหลวหรือไม่?
ไม่. BMS อาจยังคงตรวจสอบเซลล์ได้อย่างถูกต้องในขณะที่การสื่อสารล้มเหลวระหว่าง BMS และ PCS, EMS, BMS หลัก, หรือ SCADA. ระบุขอบเขตการสื่อสารที่ล้มเหลวก่อนที่จะเปลี่ยนฮาร์ดแวร์.
3. อุปกรณ์สองเครื่องสามารถรองรับ CAN หรือ RS485 และยังไม่เข้ากันได้หรือไม่?
ใช่. การแชร์อินเตอร์เฟสทางกายภาพเดียวกันไม่ได้รับประกันความเข้ากันได้. อุปกรณ์ต้องเห็นด้วยกับโปรโตคอล, อัตราบิตหรืออัตราบอด, คำจำกัดความของข้อความ/การลงทะเบียน, การจัดที่อยู่, การปรับขนาดข้อมูล, และตรรกะการควบคุม.
4. ทำไมการสื่อสาร BMS ถึงล้มเหลวเป็นระยะ?
ข้อบกพร่องที่เกิดขึ้นเป็นระยะอาจเกิดจากการเชื่อมต่อที่หลวม, การสิ้นสุดที่ไม่ดี, สัญญาณรบกวนทางไฟฟ้า, การจัดเรียงสายเคเบิล, แหล่งจ่ายไฟที่ไม่เสถียร, โทโพโลยีเครือข่าย, การตั้งเวลาวอชด็อก, หรือปัญหาซอฟต์แวร์เฟิร์มแวร์ บันทึกเวลาที่เกิดข้อบกพร่องก่อนที่จะรีบูตระบบ
5. ควรตรวจสอบอะไรหลังจากแก้ไขข้อบกพร่องการสื่อสาร BMS?
ยืนยันว่า PCS รับข้อมูลถูกต้องSoC, แรงดันไฟฟ้า, กระแสไฟ, อุณหภูมิ, สัญญาณเตือน, และขีดจำกัดการชาร์จ/การปล่อย, ปฏิบัติตามคำสั่งป้องกัน BMS, รายงานอย่างถูกต้องไปยัง EMS, และกู้คืนการสื่อสารหลังจากการรีสตาร์ทที่ควบคุม
