โปรโตคอลยานพาหนะกับโปรโตคอลแบ็กเอนด์: สองสแตกแยกกัน

โปรโตคอลยานพาหนะกับโปรโตคอลแบ็กเอนด์: สองสแตกแยกกัน
  • 1st January 1970

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

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

สองกอง สองงาน

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

สแตกบนสุดทํางานผ่านการเชื่อมต่อเครือข่าย โดยปกติจะเป็นข้อมูลมือถือหรือ site LAN มันมีสิ่งที่ผู้ปฏิบัติงานต้องการ ได้แก่ คําสั่งเริ่มและหยุด บันทึกธุรกรรม ค่ามิเตอร์ การวินิจฉัย การจัดการเฟิร์มแวร์ และการกําหนดค่า มันไม่มีมุมมองโดยตรงของรถ ทุกอย่างที่มันรู้เกี่ยวกับเซสชัน มันเรียนรู้จากเครื่องชาร์จ

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

ระหว่างรถกับเครื่องชาร์จ

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

โปรโตคอลระดับสูงเพิ่มช่องทางข้อมูล ISO 15118 และรุ่นก่อนหน้า DIN 70121 สื่อสารผ่านสายไฟฟ้าอย่างมีโครงสร้าง: รถยนต์จะระบุตัวเอง ทั้งสองฝ่ายแลกเปลี่ยนความสามารถ รถยนต์จะระบุสิ่งที่ต้องการ และเครื่องชาร์จรายงานสิ่งที่สามารถจ่ายได้ การแลกเปลี่ยนจะดําเนินต่อไปตลอดช่วงใช้งาน ซึ่งเป็นเหตุผลที่เครื่องชาร์จสามารถเห็นคําขอของรถได้ ไม่ใช่แค่กระแสไฟฟ้าที่เกิดขึ้น

ฉบับหลังของ ISO 15118 ขยายขอบเขตนี้ไปสู่การระบุตัวตนตามใบรับรอง ซึ่งเป็นสิ่งที่ทําให้การอนุญาตอัตโนมัติเป็นไปได้ และการถ่ายโอนพลังงานแบบสองทิศทาง ทั้งสองส่วนขยายต้องใช้ฮาร์ดแวร์และซอฟต์แวร์ที่เครื่องชาร์จที่ผลิตเฉพาะรุ่นก่อนหน้าไม่มี

ชั้นนี้คือจุดที่ลักษณะของยานพาหนะเข้าสู่ระบบ และยังเป็นกรณีที่เอกสารของเครื่องชาร์จเองมักจะระบุสองอย่างแยกกัน: โปรโตคอลระดับสูงที่เชื่อมต่อกับรถ และโปรโตคอลหลังบ้านที่พูดขึ้นมา

ระหว่างที่ชาร์จและแบ็กเอนด์

โปรโตคอลหลักที่นี่คือ OCPP ซึ่งเป็นมาตรฐานเปิดที่ดูแลโดยสมาคมอุตสาหกรรมและดําเนินการโดยผู้ผลิตที่ชาร์จและแพลตฟอร์ม backend อย่างอิสระ มันกําหนดข้อความสําหรับการอนุญาต การเริ่มต้นและหยุดธุรกรรม ค่ามิเตอร์ การแจ้งเตือนสถานะ คําสั่งระยะไกล การอัปเดตเฟิร์มแวร์ และการกําหนดค่า

OCPP เวอร์ชันหลังเพิ่มการจัดการอุปกรณ์ โปรไฟล์การชาร์จอัจฉริยะที่ดีขึ้น และวิธีการจัดตารางเวลาแบบคอมโพสรวมที่มีโครงสร้างมากขึ้น ความแตกต่างในทางปฏิบัติสําหรับผู้ปฏิบัติงานคือการควบคุมของระบบหลังบ้านเกี่ยวกับเวลาชาร์จและความเร็วในการชาร์จของแต่ละตัวเชื่อมต่อมากน้อยเพียงใด และสามารถเปลี่ยนแปลงได้มากน้อยเพียงใดโดยไม่ต้องไปเยี่ยมชมสถานที่

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

การปฏิบัติตามข้อกําหนดเพิ่มความสับสนอีกชั้นหนึ่ง การรับรองความสอดคล้องของ OCPP สําหรับเครื่องชาร์จในเวอร์ชันที่กําหนดไว้ และการรับรองนั้นเป็นของสินค้าและเวอร์ชันนั้น มันไม่ได้บอกอะไรเกี่ยวกับโปรโตคอลฝั่งรถ และไม่ได้บอกว่าระบบหลังบ้านแต่ละตัวทําเวอร์ชันเดียวกันได้ดีแค่ไหน ผลิตภัณฑ์ที่สอดคล้องกันสองตัวยังสามารถทํางานร่วมกันในส่วนเสริมของข้อกําหนดไม่ได้ ซึ่งเป็นเหตุผลที่การทดสอบการบูรณาการมีอยู่เป็นกิจกรรมแยกต่างหาก

<สไตล์ตาราง="ความกว้าง: 100%; การยุบขอบ: การยุบ; รัศมีของขอบ: 8px; โอเวอร์โฟลว์: ซ่อน; เงากล่อง: 0 2px 12px rgba(30,159,134,0.10); ขนาดตัวอักษร: 15px;"> สไตล์ < ="การเติมช่องว่าง: 13px 14px; จัดชิดข้อความ: ซ้าย; สี: #ffffff; น้ําหนักตัวอักษร: 600; ความสูงบรรทัด: 1.5;">เลเยอร์ สไตล์ < ="การเติมช่องว่าง: 13px 14px; การจัดแนวข้อความ: ซ้าย; สี: #ffffff; น้ําหนักตัวอักษร: 600; ความสูงบรรทัด: 1.5;">สิ่งที่ควบคุม สไตล์ <="การเติมช่องว่าง: 13px 14px; จัดแนวข้อความ: ซ้าย; สี: #ffffff; น้ําหนักตัวอักษร: 600; ความสูงบรรทัด: 1.5;">ผู้ที่ดําเนินการ สไตล์ <="padding: 13px 14px; จัดแนวข้อความ: ซ้าย; สี: #ffffff; น้ําหนักตัวอักษร: 600; ความสูงบรรทัด: 1.5;">การอัปเกรดมีผล ควบคุมนักบิน, สัญญาณพื้นฐาน ลําดับความปลอดภัย, กระแสสูงสุด, สถานะการเชื่อมต่อ เครื่องชาร์จทุกเครื่องและรถยนต์ทุกคัน ไม่มีอะไร; เลเยอร์นี้เสถียร การสื่อสารยานพาหนะระดับสูง การเจรจาต่อรองแบบมีโครงสร้าง, ระบุตัวตนของรถยนต์, ใบรับรอง, ความสามารถสองทิศทาง เครื่องชาร์จและรถยนต์ ทั้งสอง ยานพาหนะใดสามารถใช้การอนุมัติอัตโนมัติได้; ไม่มีผลต่อระเบียนการเรียกเก็บเงิน การสื่อสาร Backend ธุรกรรม, ค่ามิเตอร์, รีโมทคอนโทรล, การวินิจฉัย, เฟิร์มแวร์ เครื่องชาร์จและแพลตฟอร์มหลังบ้านแยกกัน สิ่งที่ผู้ปฏิบัติงานสามารถมองเห็นและควบคุมได้; ไม่มีผลต่อสิ่งที่รถสามารถรับได้ การชําระเงินและการชําระบัญชี ผลการอนุญาต, การใช้ภาษี, การออกใบแจ้งหนี้ Backend, ผู้ให้บริการชําระเงิน, บางครั้งเป็นเทอร์มินัล ใครได้รับเงินและวิธีพิสูจน์ข้อพิพาท

ทําไมปลั๊กและชาร์จจึงต้องมีทั้งสองด้าน

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

ทุกลิงก์ต้องมีอยู่ รถยนต์ที่ไม่มีใบรับรองสัญญาไม่สามารถแสดงใบรับรองได้ เครื่องชาร์จที่ไม่มีโปรโตคอลระดับสูงและร้าน trust store จะไม่สามารถอ่านได้ แบ็กเอนด์ที่ไม่มีการจัดการใบรับรองที่เกี่ยวข้องไม่สามารถจัดการได้ เมื่อขาดการเชื่อมต่อใด ๆ เซสชันจะกลับไปใช้บัตร แอป หรือ QR โค้ด — ซึ่งเป็นสิ่งที่ผู้ขับขี่ประสบในเครือข่ายที่โฆษณาการชาร์จอัตโนมัติและให้บริการเฉพาะกับรถและผู้ให้บริการบางประเภทเท่านั้น

นี่จึงเป็นเหตุผลว่าทําไมฟีเจอร์นี้จึงมีให้ใช้งานจริงไม่สม่ําเสมอ มันขึ้นอยู่กับจุดตัดของระบบที่อัปเดตอย่างอิสระสามระบบ และจุดตัดนั้นมีขนาดเล็กกว่าระบบใดระบบ

หนึ่ง

การอัปเกรดหนึ่งจะไม่อัปเกรดอีกอัน

หนึ่ง

สมมติฐานทั่วไปสี่ข้อล้มเหลวด้วยเหตุผลเดียวกัน

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

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

การอัปเดตเฟิร์มแวร์ที่ชาร์จจะเพิ่มความสามารถด้านรถยนต์ ฝ่ายเครื่องชาร์จสามารถอัปเดตได้ รถไม่สามารถทําได้ จากเครื่องชาร์จ

และใบรับรองนี้ครอบคลุมทั้งสองอย่าง ใบรับรองจะออกตามผลิตภัณฑ์ ตามโปรโตคอล และตามเวอร์ชัน และใบรับรองที่ระบุชื่อชั้นหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกชั้นหนึ่ง

อะแดปเตอร์ที่ระบุไว้อย่างดีจะระบุสองชั้นแยกกัน และผลิตภัณฑ์ในช่วงนี้มักจะระบุเวอร์ชันโปรโตคอล backend ควบคู่กับโปรโตคอลที่รองรับในรถยนต์ สไตล์ 120 และ 180 kW ตามข้อกําหนดสถานี และความแตกต่างนี้คือสิ่งที่ทําให้ข้อกําหนดทั้งสองสามารถทดสอบแยกกันได้

วิธีเขียนสิ่งนี้ลงในข้อกําหนด

ข้อกําหนดที่ไม่สามารถทดสอบได้ไม่ใช่ข้อกําหนด สี่เส้นทําให้ทดสอบได้

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

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

ความสัมพันธ์ระหว่างโปรโตคอลเหล่านี้กับการจัดการโหลดใกล้ชิดจนทําให้เกิดความสับสน: โปรไฟล์การชาร์จอัจฉริยะที่ส่งผ่านโปรโตคอล backend เป็นคําสั่งไปยังเครื่องชาร์จ ซึ่งต้องปฏิบัติตามคําสั่งนั้นภายในสิ่งที่รถรับได้ ปฏิสัมพันธ์นี้ถูกกล่าวถึงในหมายเหตุ load management ซึ่งอธิบายว่าคําสั่งสิ้นสุดตรงไหนและขีดจํากัดของรถเริ่มต้นตรงไหน

กองหนึ่งหันหน้าเข้าหายานพาหนะ อีกกองหันหน้าไปทางชานชาลา และไม่มีกองใดทดแทนกันได้ เมื่อฟีเจอร์หายไป คําถามแรกคือฟีเจอร์นั้นควรจะมาถึงที่สแตกไหน

สําหรับโอเปอเรเตอร์ส่วนใหญ่ ผลลัพธ์ในทางปฏิบัติคือการตรวจสอบรายการมากกว่าการออกแบบใหม่ เขียนข้อกําหนดโปรโตคอลทั้งสองในบรรทัดแยกกัน ตั้งชื่อเวอร์ชันของแต่ละบรรทัด ถามว่าจะเกิดอะไรขึ้นเมื่อการเจรจาล้มเหลว และทดสอบการรวมกันก่อนที่เว็บไซต์จะเปิด ไม่ใช่หลังจากมีข้อร้องเรียนครั้งแรก

ตรวจสอบว่าที่ชาร์จรองรับอะไรบ้าง?

ขอโปรโตคอลฝั่งยานพาหนะและ backend เป็นสองบรรทัดแยกกัน แต่ละบรรทัดมีเวอร์ชันของตัวเอง ใบรับรองเดียวไม่ครอบคลุมทั้งสองอย่าง

ถามคําถามเกี่ยวกับข้อกําหนด