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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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