กระบวนการพัฒนาเฟิร์มแวร์ของเราใช้แนวทางห้าขั้นตอน

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

ขั้นตอนที่ 1: กำหนดข้อกำหนด

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

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

ขั้นตอนที่ 2: แยกแยะระหว่างสถาปัตยกรรมและการออกแบบ

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

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

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

ขั้นตอนที่ 3: การจัดการเวลา

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

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

ขั้นตอนที่ 4: ออกแบบโดยคำนึงถึงการทดสอบ

การทดสอบระบบฝังตัวทุกระบบในหลายระดับถือเป็นสิ่งสำคัญ ในหลายๆ กรณี การทดสอบในระดับต่างๆ ไม่เพียงแต่มีคุณค่าแต่ยังจำเป็นอีกด้วย

ระดับการทดสอบที่พบบ่อยที่สุดได้แก่

1. การทดสอบระบบได้ยืนยันว่าผลิตภัณฑ์โดยรวมตรงตามหรือเกินกว่าข้อกำหนดที่ระบุ ขอแนะนำให้พัฒนาการทดสอบเหล่านี้ภายนอกแผนกวิศวกรรม แม้ว่าจะสามารถรวมเข้ากับชุดทดสอบที่ออกแบบโดยวิศวกรได้ก็ตาม

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

3. การทดสอบยูนิตจะรับประกันว่าส่วนประกอบซอฟต์แวร์แต่ละส่วนตามที่กำหนดไว้ในขั้นตอนการออกแบบขั้นกลางจะทำงานได้ตามที่ตั้งใจไว้ การทดสอบเหล่านี้มุ่งเน้นไปที่ API (Application Programming Interface) สาธารณะที่ส่วนประกอบนั้นๆ เสนอให้กับส่วนประกอบอื่นๆ โดยทั่วไป การทดสอบยูนิตจะพัฒนาโดยบุคคลเดียวกับที่เขียนโค้ดที่กำลังทดสอบ

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

ขั้นตอนที่ 5: เตรียมพร้อมสำหรับการเปลี่ยนแปลง

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