- รถไฟ Impuls 45WE ของ Newag ในโปแลนด์ไม่สามารถออกตัวได้หลังการซ่อมบำรุงโดยผู้ให้บริการอิสระ แม้ระบบวินิจฉัยจะแสดงว่าปกติ และช่างซ่อม SPS จึงว่าจ้าง Dragon Sector ให้ทำวิศวกรรมย้อนกลับคอมพิวเตอร์ออนบอร์ด
- นักวิจัยวิเคราะห์ CAN bus, dump หน่วยความจำบนฐาน TriCore และปรับปรุง Ghidra จนพบ แฟล็กล็อก และเงื่อนไขการสตาร์ตในซอฟต์แวร์ ทำให้รถไฟกลับมาเคลื่อนที่ได้
- โค้ดของรถไฟบางขบวนมีเงื่อนไขที่ห้ามสตาร์ตหากจอดอยู่ที่พิกัด GPS ของศูนย์ซ่อมบางแห่งนาน เกิน 10 วัน, การล็อกเมื่อเปลี่ยนชิ้นส่วน, เงื่อนไขให้เสียหลัง 1 ล้านกม. และเงื่อนไขรายงานความเสียหายของคอมเพรสเซอร์ตามวันที่
- รถไฟที่ถูกวิเคราะห์มีทั้งหมด 29 ขบวน และพบ “surprises” นอกเหนือจากคู่มือการปฏิบัติงานอย่างเป็นทางการในรถไฟทุกขบวนยกเว้น 5 ขบวน โดยปัญหาขยายไปยังหลายพื้นที่ เช่น Wrocław, Opole, Krakow, Szczecin และ Warsaw
- เหตุการณ์นำไปสู่คดีความและการสอบสวนของหน่วยงานบังคับใช้กฎหมาย แต่ยังไม่ยืนยันว่าหน่วยงานคุ้มครองผู้บริโภคและการแข่งขัน หรือหน่วยงานขนส่งทางรางมีมาตรการเฉพาะใดหรือไม่
รถไฟ Newag Impuls ที่หยุดนิ่งหลังซ่อมบำรุง
- เหตุการณ์เริ่มขึ้นในฤดูใบไม้ผลิปี 2022 เมื่อรถไฟขบวนแรกจากทั้งหมด 11 ขบวนของ Impuls 45WE ที่ผลิตโดย Newag และดำเนินงานโดย Lower Silesian Railways ไม่สามารถออกตัวได้หลังเสร็จสิ้นการซ่อมบำรุงภาคบังคับที่ระยะ 1 ล้านกม.
- การซ่อมบำรุงดำเนินการโดยช่างซ่อมอิสระ Serwis Pojazdów Szynowych(SPS)
- Newag เข้าร่วมประมูลด้วย แต่ข้อเสนอของผู้ผลิตแพงกว่าประมาณ 750,000 ดอลลาร์
- SPS ชนะประมูลด้วยเงื่อนไขซ่อมบำรุงรถไฟ 11 ขบวนในราคาราว 5.5 ล้านดอลลาร์
- SPS ถอดประกอบ ตรวจสอบ และประกอบรถไฟตามคู่มือซ่อมบำรุงประมาณ 20,000 หน้า ที่ผู้ผลิตให้มา แต่รถไฟก็ยังไม่เคลื่อนที่ แม้คอมพิวเตอร์ออนบอร์ดจะแสดงสถานะว่าปกติ
- อินเวอร์เตอร์ไม่จ่ายแรงดันไฟให้มอเตอร์ และช่างซ่อมบำรุงไม่สามารถหาสาเหตุได้ด้วยคู่มือและการตรวจสอบทางไฟฟ้า/เครื่องกลเท่านั้น
การหยุดซ้ำและความเสี่ยงด้านสัญญาที่เพิ่มขึ้น
- รถไฟขบวนที่สองหยุดในลักษณะเดียวกันหลังการซ่อมบำรุงแบบเดียวกัน และผู้ผลิต Newag ปฏิเสธที่จะช่วยเหลือ
- รถไฟขบวนที่สามพลาดการตรวจสอบเพราะปัญหาแบตเตอรี่ จึงมีรถไฟขบวนที่สี่เข้าศูนย์ซ่อมแทน
- เมื่อนำรถไฟขบวนที่สี่ซึ่งยังวิ่งได้ตามปกติไปเชื่อมต่อกับรถไฟที่หยุดอยู่ รถไฟปกติก็หยุดตามไปด้วย
- สาเหตุของเรื่องนี้ยังไม่ได้รับการยืนยัน
- ที่ศูนย์ซ่อมอีกแห่งใน Szczecin ก็เกิดกรณีที่รถไฟ Impuls สตาร์ตไม่ติดหลังซ่อมบำรุงเช่นกัน
- เมื่อชุดรถไฟยาว 6 ขบวนของ Lower Silesian Railway หายไป ทำให้ต้องลดตารางเดินรถ นำรถไฟทดแทนมาใช้ และเกิดความแออัดในชุดรถไฟที่สั้นกว่า
- Newag อธิบายว่ารถไฟถูกบล็อกโดย “ระบบความปลอดภัย” แต่ใน คู่มือ 20,000 หน้า ไม่มีการกล่าวถึงระบบดังกล่าว
- รถไฟที่หยุดอยู่ในศูนย์ซ่อมแต่ละขบวนทำให้เกิดค่าปรับตามสัญญามากกว่า 1,000 ดอลลาร์ต่อวัน เพิ่มภาระให้ SPS
วิศวกรรมย้อนกลับของ Dragon Sector
- SPS ค้นหา “Polish hackers” และพบ Dragon Sector ซึ่งเป็นที่รู้จักจาก CTF จากนั้นทั้งสองฝ่ายทำสัญญากัน
- ผู้เข้าร่วมโครงการมี Michał “Redford” Kowalczyk, Sergiusz “q3k” Bazański และ Kuba “PanKleszcz” Stępniewicz
- Redford และ q3k เป็นที่รู้จักจากการแฮ็กโน้ตบุ๊ก Toshiba
- Kuba มีประสบการณ์ด้านระบบอัตโนมัติในอุตสาหกรรม
- ที่หน้างาน นักวิจัยได้รับรถไฟที่ไม่เคลื่อนที่ คอมพิวเตอร์สำรอง 2 เครื่อง และไฟล์ SDK จากผู้ผลิตคอมพิวเตอร์
- การวิเคราะห์เบื้องต้นเริ่มด้วยการ tap CAN bus แต่เนื่องจากไม่มีเอกสารโปรโตคอล การตีความทราฟฟิกจึงทำได้ยาก
- SDK รองรับเฉพาะการอัปโหลดซอฟต์แวร์ใหม่ และไม่มีฟังก์ชัน dump ซอฟต์แวร์เดิม
- เมื่อนำซอฟต์แวร์เวอร์ชันเก่าที่พบไปลงในคอมพิวเตอร์สำรองเครื่องแรก คอมพิวเตอร์เครื่องนั้นก็ไม่ตอบสนองอีก
- นักวิจัยจึงทำงานต่อด้วยคอมพิวเตอร์สำรองที่เหลือเพียง 1 เครื่อง
- ในที่สุดพวกเขาพบอินเทอร์เฟซดีบักและดาวน์โหลดหน่วยความจำของอุปกรณ์แบบไบต์ต่อไบต์
- คอมพิวเตอร์ออนบอร์ดใช้สถาปัตยกรรม TriCore ซึ่งใช้ในภาคยานยนต์ด้วย และเนื่องจากขาด disassembler ที่ดี จึงต้องปรับปรุง Ghidra บางส่วนเพื่อวิเคราะห์โค้ด
เงื่อนไขการสตาร์ตที่พบก่อนเส้นตาย
- หลังผ่านไปประมาณเดือนครึ่ง Lower Silesian Railway รอไม่ไหวอีกต่อไป จึงตัดสินใจร่วมมือกับ Newag ในการซ่อมรถไฟที่เสียและซ่อมบำรุง
- คาดว่าสัญญากับ SPS จะถูกยกเลิกใน อีก 1 สัปดาห์ และนักวิจัยต้องแสดงผลลัพธ์ให้ได้ภายในเวลาที่เหลือ
- นักวิจัยเปรียบเทียบ image หน่วยความจำของคอมพิวเตอร์จากรถไฟปกติและรถไฟเสีย
- รถไฟแต่ละขบวนมีชุดฟีเจอร์และเวอร์ชันซอฟต์แวร์ต่างกัน ทำให้การเปรียบเทียบแบบตรงไปตรงมายาก
- พวกเขาพบความแตกต่างที่ค่าบางอย่างถูกตั้งไว้ในรถไฟบางขบวน แต่เป็น 0 ในขบวนอื่น
- แม้ถอดคอมพิวเตอร์ออกจากรถไฟแล้ว ก็ยังสามารถรันชั่วคราวเพื่อตรวจสอบสถานะความพร้อมทำงานของอินเวอร์เตอร์ได้ จึงทดสอบบนโต๊ะได้
- เมื่อเหลือเวลาไม่ถึงหนึ่งวันก่อนเส้นตาย พวกเขาพบ ชุดแฟล็ก ที่อาจทำให้รถไฟเคลื่อนที่ได้ แต่ระหว่างทดลอง capacitor ของคอมพิวเตอร์ออนบอร์ดปกติเครื่องสุดท้ายไหม้
- หลังพยายามรวมคอมพิวเตอร์ที่เสีย 2 เครื่องเข้าด้วยกัน พวกเขาซ่อมคอมพิวเตอร์ที่ไหม้ได้ และตั้งค่าเพื่อใช้สตาร์ตรถไฟตอนตี 2
- นักวิจัยถือคอมพิวเตอร์เครื่องนั้นไปยังศูนย์ซ่อม แต่รถไฟมาถึงล่าช้า และเมื่อถึงหน้างานแล้วเชื่อมต่อคอมพิวเตอร์ รถไฟก็ยังไม่เริ่มทำงานในตอนแรก
- หลังหารือเพิ่มเติม พวกเขาพบแฟล็กที่ขาดไปอีกหนึ่งตัว และสตาร์ตรถไฟได้สำเร็จในเวลา 08:42 น.
- เวลา 09:30 น. คณะผู้แทนของ Lower Silesian Railway ยืนยันว่ามีความเป็นไปได้ที่จะทำให้รถไฟกลับมาใช้งานได้ และไม่ยกเลิกสัญญากับ SPS
เงื่อนไขล็อกที่ซ่อนอยู่ในโค้ด
- จากการวิเคราะห์และวิศวกรรมย้อนกลับนานหลายเดือน พบเงื่อนไขในซอฟต์แวร์ของรถไฟหลายขบวนที่ Newag จัดหา ซึ่งทำให้เกิด การใช้งานไม่ได้อย่างกะทันหัน
- ตัวเลขในโค้ดอย่าง
53.13845,17.99011เป็นพิกัด GPS และชี้ไปยังพื้นที่ของ PESA ใกล้ Bydgoszcz Główny Railway Station - ต่อมาพบพิกัดของศูนย์ซ่อมและบำรุงรักษาอื่น ๆ ในโปแลนด์ที่สามารถซ่อมรถไฟได้
- ในโค้ดมีเงื่อนไขที่ปิดความสามารถในการสตาร์ตรถไฟ หากรถไฟจอดอยู่ในเขตศูนย์ซ่อมบางแห่ง อย่างน้อย 10 วัน
- หนึ่งในพิกัดนั้นเป็นศูนย์ซ่อมของ Newag เอง
- สำหรับพิกัดศูนย์ซ่อมของ Newag มีการกำหนดเงื่อนไขตรรกะอีกแบบหนึ่งไว้ และคาดว่าอาจมีไว้เพื่อการทดสอบ
- ในรถไฟขบวนอื่น ๆ ยังพบเงื่อนไขล็อกแยกต่างหากด้วย
- หากมีการเปลี่ยนชิ้นส่วนบางรายการ รถไฟจะถูกบล็อกผ่านการตรวจสอบ หมายเลขซีเรียล ของชิ้นส่วน
- มีตัวเลือกให้ปลดล็อกได้โดยกดปุ่มตามลำดับเฉพาะในห้องคนขับและบนหน้าจอคอมพิวเตอร์ออนบอร์ด
- หลังข่าวความสำเร็จในการสตาร์ต Impuls ออกสื่อ รถไฟเหล่านี้ได้รับอัปเดตซอฟต์แวร์ที่ลบตัวเลือก “fix” นี้ออก
- ในรถไฟอีกขบวน พบโค้ดที่สั่งให้เกิด “ความเสียหาย” หลัง 1 ล้านกม.
รายงานความเสียหายของคอมเพรสเซอร์ที่เกิดจากเงื่อนไขวันที่
- รถไฟอีกขบวนหนึ่งปฏิเสธการทำงานในวันที่ 21 พฤศจิกายน 2022 แม้ไม่ได้อยู่ระหว่างซ่อมบำรุง
- คอมพิวเตอร์รายงานว่า คอมเพรสเซอร์เสีย แต่ช่างซ่อมเห็นว่าคอมเพรสเซอร์ไม่มีปัญหา
- การวิเคราะห์โค้ดพบเงื่อนไขต่อไปนี้
- วันที่มากกว่าหรือเท่ากับ 21 และ
- เดือนมากกว่าหรือเท่ากับ 11 และ
- ปีมากกว่าหรือเท่ากับ 2021 แล้ว
- ให้รายงานว่าคอมเพรสเซอร์เสีย
- เดิมรถไฟขบวนนี้มีกำหนดซ่อมบำรุงในเดือนพฤศจิกายน 2021 แต่จริง ๆ เข้าซ่อมเร็วกว่า และเพิ่งกลับมาให้บริการในเดือนมกราคม 2022
- ในเดือนพฤศจิกายน 2021 เงื่อนไขไม่ได้ถูกเรียกโดยบังเอิญ และจนถึง 21 พฤศจิกายน 2022 เงื่อนไขความเสียหายที่กำหนดไว้จึงถูกทำให้ครบ
อุปกรณ์เชื่อมต่อ GSM ที่พบในฮาร์ดแวร์
- ไม่เพียงซอฟต์แวร์เท่านั้น แต่ในฮาร์ดแวร์ก็พบอุปกรณ์แปลก ๆ ด้วย
- ในชุดรถไฟชุดหนึ่ง นักวิจัยพบอุปกรณ์ที่ระบุว่า “UDP<->CAN converter”
- ดูเหมือนเป็นอุปกรณ์ที่ทำให้สื่อสารกับรถไฟจากระยะไกลได้
- แม้ถอดอุปกรณ์ออก ก็ไม่มีฟังก์ชันใดหยุดทำงาน
- คอมพิวเตอร์ออนบอร์ดส่งข้อมูลสถานะล็อกไปยังอุปกรณ์นี้ และตัวอุปกรณ์เองเชื่อมต่อกับ โมเด็ม GSM
ปัญหาที่แพร่ไปหลายพื้นที่และขอบเขตการวิเคราะห์
- ข่าวที่ว่า SPS ซ่อมรถไฟ “เสีย” ของ Newag ได้แพร่ไปถึงบริษัทอื่น ๆ และพบว่าปัญหาคล้ายกันเกิดขึ้นบ่อย
- ใน Wrocław มีการวิเคราะห์ Impuls 13 ขบวน
- ในพื้นที่อื่น ๆ ก็พบรถไฟที่มีปัญหาเช่นกัน
- Kolej Mazowieckie 1 ขบวน
- Opole 2 ขบวน
- Krakow 4 ขบวน
- Zielona Góra 1 ขบวน
- Szczecin 4 ขบวน
- Warsaw 1 ขบวน
- เครื่องมือที่นักวิจัยสร้างขึ้นลบ การล็อกซอฟต์แวร์ ของคอมพิวเตอร์ออนบอร์ด และรถไฟแต่ละขบวนจึงซ่อมได้
- มีการวิเคราะห์ซอฟต์แวร์ทั้งหมด 29 ขบวน และพบองค์ประกอบนอกเหนือจากคู่มือการปฏิบัติงานอย่างเป็นทางการในรถไฟทุกขบวน ยกเว้น 5 ขบวน
การดำเนินการภายหลังและขอบเขตการเปิดเผย
- เรื่องนี้อยู่ระหว่างการดำเนินคดี
- ยังไม่ทราบว่า Office of Consumer and Competition Protection หรือ Railway Transport Office ของโปแลนด์ได้ดำเนินมาตรการเฉพาะใดหรือไม่
- นักวิจัยแจ้งสิ่งที่พบต่อ CERT Polska
- CERT Polska แจ้งต่อ “หน่วยงานที่เกี่ยวข้อง” แล้ว
- เหตุการณ์นี้อยู่ในการดูแลของหน่วยงานบังคับใช้กฎหมาย
- เนื้อหานี้เป็นสรุปย่อจากการนำเสนอของ Jakub Stępniewicz, Sergiusz Bazański และ Michał Kowalczyk ในงานประชุม Oh My H@ck เมื่อวันที่ 5 ธันวาคม 2023
- ต้นฉบับละเว้นส่วนสำคัญจำนวนมากของการวิเคราะห์ทางเทคนิคทั้งหมด และระบุว่าคาดหวังให้นักวิจัยจัดทำและเผยแพร่เอกสารทางเทคนิคแยกต่างหาก
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
มีโพสต์ล่าสุดที่เกี่ยวข้องด้วย: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - ธันวาคม 2023, 347 ความคิดเห็น
นึกไม่ออกเลยว่าจะหน้าด้านได้ขนาดนี้ โค้ดที่ทำให้หัวรถจักรกลายเป็นอิฐ ถ้าพิกัด GPS อยู่ในเขตของอู่ซ่อมคู่แข่ง เกิน 10 วัน เนี่ยนะ
มันไปไกลกว่าระดับที่ทำให้การซ่อมยากขึ้น เช่น อินเทอร์เฟซที่ไม่ทำเอกสารไว้ หรือเฟิร์มแวร์ที่เซ็นด้วยการเข้ารหัสมาก ผมมองว่าใกล้เคียงกับ การทำลายทรัพย์สินโดยเจตนาร้าย เลยทีเดียว ผมไม่รู้ระบบกฎหมายของโปแลนด์ แต่จินตนาการไม่ออกว่าสิ่งนี้จะรอดไปได้อย่างไร
รถไฟมีอยู่แล้วและต้องเดินรถ แต่บริษัทซ่อมบำรุง/ซ่อมแซมไม่สามารถแก้ไขซอฟต์แวร์อย่างถูกกฎหมายได้เพราะลิขสิทธิ์ เป็นทางตันเต็มรูปแบบเลย หวังว่าบริษัทนั้นจะโดนปรับหนักมหาศาลและถึงขั้นถูกดำเนินคดีอาญา แต่ก็สงสัยว่าในความเป็นจริงจะเป็นแบบนั้นไหม
ถ้ามีทีมกฎหมายที่เอาจริงเอาจัง ก็น่าจะหาข้อหาร้ายแรงที่นำมาใช้ได้ โดยเฉพาะถ้ารถไฟหรือหัวรถจักรดังกล่าวเข้าข่าย โครงสร้างพื้นฐานสำคัญ แม้จะไม่รับประกันว่าเป็นเช่นนั้นก็ตาม
การใส่ handshake ลับและทำเอกสารขั้นตอนให้ไม่ดีเพื่อให้คู่แข่งดูไร้ความสามารถ กับการ จงใจทำให้ผลิตภัณฑ์ของตัวเองเสีย เพียงเพราะมันเข้าไปในอู่ซ่อมของคู่แข่งนั้น คนละระดับกันเลย
ชื่อเรื่องชวนเข้าใจผิดเล็กน้อย “gate” ในกรณีนี้ไม่ใช่การ หลอกว่าเป็นมิตรต่อสิ่งแวดล้อม เพื่อผ่านการรับรองภายใต้เงื่อนไขเทียมแบบ Dieselgate แต่เป็นการจำลองความเสียหายปลอม
บริษัทฮาร์ดโค้ดอัลกอริทึมที่อาศัยข้อมูลตำแหน่งเพื่อสรุปว่าบริษัทอื่นซ่อมรถไฟ แล้วรายงานเหมือนชิ้นส่วนที่ทำงานปกติ เช่น คอมเพรสเซอร์ เสีย และหยุดการเดินรถไฟ
แน่นอนว่าสองกรณีนี้คงไม่เหมือนกันทุกอย่าง แต่ก็เห็นได้ชัดว่าทำไมถึงมีการเปรียบเทียบแบบนั้น
อย่างแรกคือทำให้รถไฟไม่ทำงานหลังจากจอดอยู่ในสถานที่ซ่อมของคู่แข่งเป็นเวลา 10 วันตามเกณฑ์ GPS อีกอย่างคือฮาร์ดโค้ดให้เฟิร์มแวร์บางเวอร์ชันแสร้งว่าคอมเพรสเซอร์เสีย หลังจากเลยกำหนดซ่อมบำรุงถัดไปไปไม่กี่วัน
ส่วนที่แย่ที่สุดคือ “ในโปแลนด์หาได้ยากที่จะพบหน่วยงานใดแสดงท่าทีมากกว่าความสนใจอย่างสุภาพต่อเรื่องนี้ ผมก็ไม่รู้ว่าสำนักงานคุ้มครองผู้บริโภคและการแข่งขัน หรือสำนักงานขนส่งทางรางได้ดำเนินการอะไรบ้างหรือไม่”
หน่วยงานคุ้มครองผู้บริโภคไม่ได้มีอำนาจมากเท่าหน่วยงานเหล่านี้
การถกเถียงจากโพสต์ก่อนหน้าของบทความที่เกี่ยวข้องก็น่าอ่านเช่นกัน: https://news.ycombinator.com/item?id=38530885
ทางออกของปัญหาควบคุมเครื่องยนต์แปลก ๆ อย่างการโกงการทดสอบไอเสียและการขัดขวางการซ่อมโดยบุคคลที่สาม อาจเป็นการ ทำให้อินเทอร์เฟซของระบบเหล่านี้เป็นมาตรฐาน
หากเอาต์พุตของเซ็นเซอร์ถูกทำให้เป็นมาตรฐาน ก็สามารถสลับส่วนประกอบต่าง ๆ เพื่อตรวจสอบว่าระบบไม่ได้กำลังหลอกหน่วยงานกำกับดูแลอยู่ได้
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
ผมมีเพื่อนที่ใช้ WRX อยู่ คันนั้นไม่มีแคตตาไลติก มีเทอร์โบใหญ่และจูนมาแล้ว จึงไม่ควรผ่านการตรวจไอเสียได้เลย แต่ข้อมูลเซ็นเซอร์ถูกสังเคราะห์และควบคุมส่วนที่เกี่ยวข้องไว้ จึงไม่มี error code และผ่านได้สบายทุกครั้ง
อยากให้กำจัดหลุมดำที่เรียกว่าเฟิร์มแวร์ออกไปและทำให้ตรวจสอบได้
ไม่จำเป็นต้องทำให้เป็นมาตรฐานอย่างสมบูรณ์ แค่เปิดเผยก็พอ ถึงอย่างนั้นโดยพื้นฐานแล้วทิศทางนี้ก็ถูกต้อง
ดูเหมือนเป็นการ ขัดขวางโดยเจตนา ด้วยซอฟต์แวร์ เพื่อไม่ให้ใช้บริการบุคคลที่สามที่ถูกกว่าบริการของผู้ผลิต
อยากรู้ว่าศาลจะตัดสินอย่างไร
เป็นปัญหาที่ผู้ร่างกฎหมาย ศาล และสาธารณชนหลงทางเมื่อต้องเจอกับปัญหาทางเทคนิค แต่อาชญากรรมนี้น่าจะเข้ากับกฎหมายอาญาเดิมที่เกี่ยวกับการขัดขวางได้อย่างเพียงพอ วิธีการนั้น “ใหม่” แต่อาชญากรรมเองเป็นแบบคลาสสิก
คุณภาพของเฟิร์มแวร์รถไฟโดยรวมให้ความรู้สึกว่าไม่ค่อยดีนัก และหวังว่าเรื่องอื้อฉาวครั้งนี้จะทำให้มีการตรวจสอบที่เข้มงวดยิ่งขึ้น
เมื่อ 3 ปีก่อน Deutsche Bahn เคยออกมาบ่นต่อสาธารณะเรื่องปัญหาซอฟต์แวร์ที่ “ประหลาด” ของรถไฟ Bombardier ที่เพิ่งส่งมอบ ตัวอย่างเช่น เมื่อคนขับรถไฟเปลี่ยนทิศทางการเดินรถ ซอฟต์แวร์ของรถไฟก็ล่ม และต้องใช้เวลา 1 ชั่วโมงในการบูตใหม่ [0] สวิตเซอร์แลนด์ก็มีปัญหาคล้ายกันในปี 2018 [1]
ในฐานะนักวิทยาการคอมพิวเตอร์ เรื่องนี้น่าอาย ลองเทียบกับรถไฟรุ่นเก่าที่ผลิตในเยอรมนีตะวันออกช่วงทศวรรษ 1980 [2] ซึ่งจนไม่นานมานี้ยังลากตู้โดยสารเยอรมนีตะวันตกจากทศวรรษ 1950 [3] อยู่แถวนี้ อุปกรณ์อิเล็กทรอนิกส์ดิจิทัลแทบไม่มีหรือไม่มีเลย และไม่มีเวลาบูต มันแค่ทำงานได้ ถ้าไม่ทำงาน คนขับรถไฟก็มักรู้ว่าต้องเอาค้อนเคาะตรงไหนของเครื่องยนต์ถึงจะแก้ได้ เราไม่ควรคาดหวังให้คนขับรถไฟต้องแฮ็กเฟิร์มแวร์รถไฟแล้วเปิด gdb เพื่อหาว่าทำไมรถไฟไม่ขยับ
[0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
[1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
[2] https://de.wikipedia.org/wiki/DR-Baureihe_243
[3] https://de.wikipedia.org/wiki/N-Wagen
บริษัทที่ผลิตสิ่งของซึ่งมีซอฟต์แวร์อยู่ภายในไม่ได้อยู่ในตลาดที่พร้อมจ่ายให้บุคลากรซอฟต์แวร์มากกว่าเดิม 2–3 เท่า คนที่เหลือจึงเป็นคนที่ยอมรับความสนุกนั้นแทนส่วนต่างของค่าตอบแทนรวม และคนที่ไปทำงานที่จ่ายมากกว่านี้ไม่ได้ ระบบ ที่จำเป็นต่อความปลอดภัย ส่วนใหญ่ที่เราใช้กันถูกสร้างโดยคนเหล่านี้ ลองเทียบค่าตอบแทนนักพัฒนาของ X กับ SpaceX ก็จะเห็นว่าตลาดทำงานอย่างไร ความสนุกก็เป็นส่วนหนึ่งของค่าตอบแทนรวมเช่นกัน แต่ก็ทำให้เกิดผลลัพธ์ที่คนซึ่งไม่ใช่นักพัฒนาที่ดีหันไปออกแบบกระบวนการและเครื่องมือใหม่ในสายงานนี้ พวกเขาอาจยึดติดกับกระแสฟูลสแตกที่ตกยุคไปแล้วและพยายามนำไปใช้กับเฟิร์มแวร์รถไฟ ใน Jira มีข้อความมากกว่า Git ถึง 10 เท่า ทำงานแบบสกรัมผสมน้ำตก และต่อให้มีการใส่ REST API หรือสถาปัตยกรรมเชิงบริการเข้าไปในระบบฝังตัวที่จำเป็นต่อความปลอดภัย ก็ไม่ใช่เรื่องน่าแปลกใจ
นอกจากของอย่าง Tc3 ของ Beckhoff แล้ว สาขานี้ยังไปไม่ถึงการเขียนโปรแกรมเชิงวัตถุด้วยซ้ำ และทั้งวงการยังติดอยู่ในเหมืองจอฟ้าแห่งอดีต พวกเขาจัดการความซับซ้อนด้วยเอกสารมาตรฐานบาง ๆ ไม่มีแม้แต่การควบคุมเวอร์ชัน ขณะที่เครื่องจักรซับซ้อนขึ้นเรื่อย ๆ ในแง่เซนเซอร์และแอกชูเอเตอร์ เครื่องจักรสมัยใหม่ไม่อาจถูกปฏิบัติราวกับอุปกรณ์ฝังตัวงานอดิเรกขนาดเล็กได้ แต่อุตสาหกรรมกลับทำแบบนั้น โปรแกรมเมอร์จากภายนอกเข้ามาแก้ปัญหาเมื่อวานด้วยสถาปัตยกรรมซอฟต์แวร์ที่เหมาะสมและแนวปฏิบัติการพัฒนา C แล้วทำเงินได้ดีเช่นกัน แต่ภาคอุตสาหกรรมก็ไม่เรียนรู้อะไรจากตรงนั้น สำหรับพวกเขา การสร้างซอฟต์แวร์จะไม่มีวันเป็นวิชาชีพเฉพาะทาง
รถไฟสมัยใหม่จำนวนมากประสบปัญหาซอฟต์แวร์การเดินรถพื้นฐาน [0] และความล่าช้าในการอนุมัติซอฟต์แวร์ [1] แต่ผมคิดว่าการถอยหลังที่แย่ที่สุดคือการสูญเสียความเข้ากันได้ ชุดรถไฟไฟฟ้าสมัยใหม่โดยพื้นฐานแล้วทำงานร่วมกันได้เฉพาะกับชุดรถไฟไฟฟ้าที่อยู่ในชุดเดียวกันเท่านั้น แม้จะเป็นรุ่นเดียวกัน หากสองบริษัทสั่งแยกกันก็มักเข้ากันไม่ได้ และแทบต้องเลิกหวังกับการนำชุดรถไฟไฟฟ้าที่ต่างบริษัทกันหรือสั่งห่างกันเกิน 10 ปีมาใช้งานร่วมกัน ในทางกลับกัน ก่อนยุคดิจิทัล การใช้รถรางต่างรุ่นร่วมกันและเดินสายไฟปรับให้เข้ากันเป็นเรื่องปกติ ตู้โดยสารเก่า ๆ ทำงานร่วมกันได้โดยไม่มีปัญหา แต่การใช้ IC2 กับ Railjet หรือ RailJet กับ ICE-L ร่วมกันไม่ใช่เรื่องง่าย หลายครั้งก็มีเฉพาะหัวรถจักรกับตู้โดยสารบางคู่เท่านั้นที่ทำงานร่วมกันได้
ระบบคอมพิวเตอร์มีความซับซ้อนและความทึบสูง จึงทำให้ทำงานร่วมกันได้ยากกว่ามาก แผงวงจรตรรกะแบบดั้งเดิมโดยทั่วไปสามารถทำวิศวกรรมย้อนกลับได้ง่าย แต่การทำวิศวกรรมย้อนกลับซอฟต์แวร์เป็นงานที่ต้องใช้ความเชี่ยวชาญมาก ปรากฏการณ์นี้เด่นชัดในสาขาอื่น ๆ ที่ความสามารถในการทำงานร่วมกันแย่ลงอย่างมากหลังย้ายไปใช้โปรโตคอลดิจิทัลแบบปิด ส่วนหนึ่งเป็นเพราะซอฟต์แวร์มีความทึบ จึงขออนุมัติได้ยากกว่าเทคโนโลยีก่อนหน้า แต่ปัญหาคุณภาพที่แท้จริงก็มีมากเช่นกัน หนึ่งในเหตุผลที่ Bombardier ตกอยู่ในสถานการณ์ลำบากอย่างหนักก็คือซอฟต์แวร์ที่แย่ และถึงขั้นมีการยกเลิกสัญญาที่สั่งไว้มากกว่า 40 ขบวน ([2])
ผมคิดว่าการสร้างซอฟต์แวร์ที่เชื่อถือได้และเข้าใจได้ยากกว่าการสร้างวงจรตรรกะหรือระบบเครื่องกลมาก ผมไม่รู้ทางแก้ แต่นี่เป็นปัญหาที่มีมานานแล้ว
[0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn...
[1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf...
[2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
กำลังเสพเฉพาะคอนเทนต์ภาษาอังกฤษเท่านั้น คอนเทนต์จากประเทศอื่น ๆ ก็จะได้เจอเฉพาะสิ่งที่เล็ดลอดออกมาผ่านสื่อรายใหญ่เท่านั้น
เลยสงสัยว่ามี คอนเทนต์ดี ๆ ที่น่าจะแปลได้อยู่มากแค่ไหน
แต่ภาษาอังกฤษอย่างน้อยในกลุ่มที่มีการศึกษามากกว่าของโลก ตอนนี้กลับกลายเป็น ภาษากลาง ไปแล้วอย่างน่าขัน และแม้แต่คนที่ถนัดภาษาแม่มากกว่า ก็มักจะแปลงานที่ดีที่สุดของตัวเองเป็นภาษาอังกฤษเพื่อให้มีคนอ่านในวงกว้างขึ้น บทความวิทยาศาสตร์เป็นตัวอย่างชัดเจน บางทีของขวัญที่ยิ่งใหญ่ที่สุดที่อังกฤษมอบให้โลกอาจเป็นภาษาอังกฤษก็ได้
แต่เรื่อง การผูกติดกับซัพพลายเออร์ ของรถไฟทั้งหมดนี้ เพิ่งมารู้ครั้งแรกจาก HN ถ้าไม่อย่างนั้นก็คงไม่รู้เลย หรือไม่ก็เพิ่งรู้หลังจากผ่านไปหลายสัปดาห์หรือหลายเดือน