รถยนต์กำหนดด้วยซอฟต์แวร์แล้วหรือยัง? สถาปัตยกรรมโดเมนและการเปลี่ยนผ่านสู่ SDV

ใช่: พฤติกรรม คุณสมบัติ และลักษณะการทำงานของรถยนต์สมัยใหม่ ตอนนี้ถูกกำหนดโดยซอฟต์แวร์เป็นหลัก การเปลี่ยนแปลงนี้ที่เรียกว่ารถยนต์นิยามด้วยซอฟต์แวร์ (SDV) ได้ย้ายสถาปัตยกรรมอิเล็กทรอนิกส์ของยานพาหนะจากกอง ECU ไปสู่ตัวควบคุมแบบโดเมนและโซน ทำให้ฮาร์ดแวร์และซอฟต์แวร์แยกจากกัน และสร้างสรรค์สิ่งใหม่ตั้งแต่น้ำหนักสายไฟจนถึงการอัปเดต OTA

รถยนต์นิยามด้วยซอฟต์แวร์คืออะไรกันแน่?

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

สถาปัตยกรรม E/E ในปัจจุบันประกอบด้วยหน่วยควบคุม 100 หน่วยขึ้นไป โครงสร้างรุ่นใหม่ช่วยประหยัดจำนวนหน่วยควบคุมได้ถึง 20% และประหยัดวัสดุและฮาร์ดแวร์ได้ถึง 10%

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

จาก ECU สู่สถาปัตยกรรมโดเมน: การจัดกลุ่มตามฟังก์ชัน

ยุคที่ฟังก์ชันเล็กๆ ทุกอย่างในรถยนต์มีหน่วยควบคุมอิเล็กทรอนิกส์ (ECU) เป็นของตัวเอง ทำให้ชุดสายไฟกลายเป็นสิ่งที่จัดการไม่ได้ สถาปัตยกรรมโดเมนคือคำตอบเชิงระบบแรกต่อปัญหานี้: โดยจัดระเบียบระบบอิเล็กทรอนิกส์ของยานพาหนะตามพื้นที่ฟังก์ชันหลัก เช่น ADAS, อินโฟเทนเมนต์, ระบบส่งกำลัง (powertrain), อิเล็กทรอนิกส์ตัวถัง, ชัสซี และความปลอดภัย แต่ละโดเมนโดยทั่วไปจะมีโปรเซสเซอร์ สแตกซอฟต์แวร์ อินเทอร์เฟซการสื่อสาร เซนเซอร์ และแอกชูเอเตอร์ของตัวเอง และถูกควบคุมโดยโดเมนคอนโทรลเลอร์

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

สถาปัตยกรรมแบบโซน: การจัดระเบียบเปลี่ยนจากฟังก์ชันไปสู่ตำแหน่งที่ตั้ง

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

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

ตัวควบคุมโซนทำหน้าที่อะไร? การแบ่งงานและความสัมพันธ์กับฮาร์ดแวร์

หัวใจสำคัญของสถาปัตยกรรมแบบโซนคือตัวควบคุมโซน ซึ่งรับผิดชอบการเชื่อมต่อแอคชูเอเตอร์และเซนเซอร์จำนวนมากเข้ากับ ECU ประมวลผลส่วนกลาง ตัวควบคุมนี้ไม่ใช่เพียงกล่องรวบรวมข้อมูลเท่านั้น; มันสามารถรันวงจรควบคุมแบบเรียลไทม์บนตัวเอง จัดการอุปกรณ์ในโซนของตน และส่งทราฟฟิกที่กรองและจัดลำดับความสำคัญแล้วไปยังบัสแบ็กโบน ตามการประเมินทางวิศวกรรมจากที่มาของ Ti MCU ของโมดูลโซนต้องให้สมรรถนะเรียลไทม์สูง หน่วยความจำขนาดใหญ่ การสนับสนุนการจำลองเสมือนสำหรับระดับ ASIL ที่หลากหลาย การสื่อสารความเร็วสูงไปยังบัสแบ็กโบน และอินเทอร์เฟซปลายทางต้นทุนต่ำจำนวนมาก เช่น CAN FD และ LIN

การจ่ายพลังงานกระจายศูนย์ได้อย่างไร?

ในสถาปัตยกรรมโดเมน พลังงานจะถูกจ่ายจากกล่องจ่ายพลังงานส่วนกลางที่มีฟิวส์ละลายและรีเลย์ ในโครงสร้างแบบโซน การจ่ายพลังงานกระจายศูนย์: รัดสายพลังงานเส้นเดียวถูกดึงจากแบตเตอรี่ไปยังแต่ละโซน และโมดูลโซนแบ่งพลังงานให้กับโมดูลต่าง ๆ ในบริเวณนั้น สายพลังงานที่สั้นลงหมายถึงการประหยัดน้ำหนักและต้นทุนโดยตรง นอกจากนี้ ฟิวส์ละลายถูกแทนที่ด้วยฟิวส์อัจฉริยะที่ใช้สารกึ่งตัวนำ; สวิตช์ฝั่งสูงที่มีลักษณะ I²t ช่วยให้ความหลากหลายของฟิวส์ลดลงและขนาดหน้าตัดสายไฟได้รับการปรับให้เหมาะสมยิ่งขึ้น กล่องจ่ายพลังงานอัจฉริยะที่ประกอบด้วย MCU สวิตช์ฝั่งสูง และทรานส์ซีฟเวอร์ กลายเป็นหน่วยที่ตั้งค่าได้ด้วยซอฟต์แวร์: กล่องเดียวกันนี้สามารถใช้ในทุกโซนโดยปรับให้เหมาะกับโหลด

การแยกส่วนของอินพุต/เอาต์พุตเชิงกายภาพและเชิงตรรกะ

โมดูลโซนัลช่วยลดความซับซ้อนของสายไฟโดยรวมฟังก์ชันอินพุต/เอาต์พุตเชิงตรรกะของ ECU หลายตัวไว้ที่จุดเดียว ส่วนตำแหน่งทางกายภาพของเซนเซอร์และแอกชูเอเตอร์ยังคงอยู่เช่นเดิม ก้าวไปอีกขั้น อุปกรณ์ปลายทางจะกลายเป็น "อัจฉริยะ": วงจรภายในเก็บรักษาข้อมูลสถานะและรันการวินิจฉัยความผิดพร่อง โปรโตคอลแบบง่ายอย่าง CAN FD Light สามารถขจัดความจำเป็นในการมี MCU แยกต่างหากในโหนดปลายทางบางส่วนได้แม้แต่ตัวเดียว การแยกส่วนที่ฮาร์ดแวร์คงที่แต่งานถูกกำหนดด้วยซอฟต์แวร์นี้ คือโครงสร้างพื้นฐานทางวิศวกรรมของ SDV

บัสข้อมูลในยานยนต์แบบโซนัล: แบนด์วิดท์ การจับเวลา และความปลอดภัยไซเบอร์

การฟิวชันเซนเซอร์และงาน AI บังคับให้โทโพโลยีแบบโซนัลต้องสร้างบนโครงสร้างหลักที่มีแบนด์วิดท์สูง: PCIe, CAN XL ที่มีอัตราข้อมูลถึง 20 Mbps และ Ethernet กิกะบิต ซึ่งรักษาความเข้ากันได้กับ CAN ที่มีอยู่ ความท้าทายที่แท้จริงไม่ได้อยู่ที่แบนด์วิดท์เท่านั้น แต่อยู่ที่การจับเวลา ข้อความควบคุมสั้นๆ ข้อมูลเซนเซอร์ ADAS และทราฟฟิกอินโฟเทนเมนต์ มีความต้องการด้านความหน่วง, จิตเตอร์ และการซิงโครไนเซชันที่แตกต่างกันอย่างมาก แนวทางคร่าวๆ คือ: เป้าหมายความหน่วงระดับมิลลิวินาทีสำหรับเสียง และระดับไมโครวินาทีสำหรับการส่งกำลังและการควบคุมแชสซี

เพื่อขนส่งคลาสทราฟฟิกที่แตกต่างเหล่านี้ในเครือข่ายเดียว Ethernet-based Time-Sensitive Networking (TSN) จึงเด่นขึ้นมาเป็นทางแก้ มาตรฐานต่างๆ เช่น การซิงโครไนซ์เวลา (IEEE 802.1AS), การจัดรูปแบบทราฟฟิกที่คำนึงถึงเวลา (802.1Qbv), express traffic (802.3br), frame pre-emption (802.1Qbu) และความซ้ำซ้อน (802.1CB) ให้การรับประกันความหน่วงแบบดีเทอร์มินิสติกแก่ข้อมูลที่สำคัญ ด้านความปลอดภัย มีการสนับสนุน ISO 26262, เส้นทางการสื่อสารแบบซ้ำซ้อน, การแบ่งส่วนด้านความปลอดภัย และการตรวจจับความผิดพร่อง ส่วนด้านความปลอดภัยไซเบอร์ มาตรฐาน ISO/SAE 21434, ข้อกำหนดของ UNECE และกลไกการเข้ารหัล-ยืนยันตัวตนระดับต่ำอย่าง MACsec คือตัวชี้ขาด เนื่องจากสถาปัตยกรรมแบบโซนัลรวมศูนย์เครือข่าย วิธีการโจมตีที่อิงบน Ethernet จึงกลายเป็นสิ่งที่นำไปใช้ได้ การล่มสลายของแนวคิดการแยกส่วนระหว่าง I/O กับการประมวลผลเมื่อเกิดการละเมิดความปลอดภัย เป็นความเสี่ยงที่ต้องประเมินเป็นรายกรณี

การแยกส่วนฮาร์ดแวร์-ซอฟต์แวร์เปิดทางให้การอัปเดต OTA เป็นไปได้อย่างไร?

การอัปเดต OTA ในการสนทนา SDV ส่วนใหญ่คือคุณสมบัติแรกที่มักถูกพูดถึง แต่มันไม่ใช่ความสามารถที่เป็นอิสระในตัวเอง หากแต่เป็นผลลัพธ์ของสถาปัตยกรรม ซอฟต์แวร์จะไม่สามารถรับการอัปเดตอย่างต่อเนื่องได้ หากไม่แยกออกจากชิปเฉพาะผ่านชั้นการแยกนามธรรมฮาร์ดแวร์ (HAL) และฟังก์ชันของยานพาหนะไม่ถูกแบ่งเป็นบริการที่เป็นอิสระ นำกลับมาใช้ใหม่ได้ และเชื่อมต่อแบบหลวม (สถาปัตยกรรมเชิงบริการ, SOA) การแยกส่วนนี้ยังครอบคลุมถึงการแยกซอฟต์แวร์ที่มีระดับความปลอดภัยต่างกันออกจากกันด้วย

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

การเปลี่ยนผ่านจะเร็วแค่ไหน และสถาปัตยกรรมแบบโซนเพียงอย่างเดียวจะเพียงพอหรือไม่?

การเปลี่ยนผ่านจะเป็นแบบค่อยเป็นค่อยไป โดเมนตัวถัง (body) เนื่องจากมี ECU แอคชูเอเตอร์และเซนเซอร์แบบกระจายจำนวนมาก จึงเป็นพื้นที่แรกที่จะเปลี่ยนไปใช้สถาปัตยกรรมแบบโซน ส่วนการเปลี่ยนผ่านของ ADAS, powertrain และการควบคุมแชสซี อาจใช้เวลานานกว่าเนื่องจากมีความสำคัญต่อความปลอดภัยในระดับวิกฤต วิวัฒนาการของชั้น MCAL, BSW และชั้นแอปพลิเคชันตั้งแต่ปี 2017 เป็นต้นมา แสดงให้เห็นว่านี่ไม่ใช่เพียงโครงการทางเทคนิค แต่เป็นการเปลี่ยนแปลงความคิดในระดับอุตสาหกรรม

ก็จำเป็นต้องอ่านอย่างสมดุลด้วย สถาปัตยกรรมแบบโซนจัดระเบียบยานพาหนะใหม่ในเชิงกายภาพ แต่ด้านตรรกะและซอฟต์แวร์ (SOA, HAL, ความปลอดภัยไซเบอร์) ยังต้องได้รับการแก้ไขแยกต่างหาก - การจัดระเบียบสายไฟใหม่เพียงอย่างเดียวไม่ได้ทำให้ยานพาหนะกลายเป็นยานพาหนะนิยามด้วยซอฟต์แวร์ การประมาณการขนาดตลาดก็เปลี่ยนแปลงอย่างมากขึ้นอยู่กับนิยามขอบเขต ตัวเลขที่แตกต่างกันเกี่ยวกับตลาดสถาปัตยกรรม E/E มีสาเหตุมาจากการวัดที่แตกต่างกัน ขึ้นอยู่กับว่านับรวมอะไรบ้าง (เฉพาะแพลตฟอร์มประมวลผล หรือรวมอิเล็กทรอนิกส์แบบกระจายทั้งหมด) นอกจากนี้ ต้องไม่ลืมว่าผู้ผลิตเซมิคอนดักเตอร์และผู้ให้บริการโซลูชันซึ่งเป็นภาคีในการเปลี่ยนผ่านนี้ ย่อมมีส่วนได้เสียในการเปลี่ยนแปลงครั้งนี้โดยธรรมชาติ

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

แหล่งอ้างอิง

• How a Zone Architecture Paves the Way to a Fully Software-Defined Vehicle (TI SPRY345)
• Domain vs zonal architecture: a complete guide
• Zonal E/E Architecture for Software Defined Vehicles (SDVs)
• Automotive zonal architecture
• Automotive Zone Controller
• Zone Control Unit (ZCU)
• What is a Software-Defined Vehicle
• Understanding Software-Defined Vehicles (SDVs)
• Software-Defined Vehicle (SDV) Explained
• Why Safety Function Decoupling is Essential
• Service-Oriented Architecture for SDVs
• What Is Service-Oriented Architecture (SOA)?
• The Rise of the Software-Defined Vehicle: Architectures and Challenges
• The E/E architecture of the future
• Vehicle Electronics Architecture
• Redefining Architecture in SDVs