เราปฏิบัติตามกระบวนการห้าขั้นตอนในการออกแบบเฟิร์มแวร์

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

การสร้างสถาปัตยกรรมเฟิร์มแวร์ที่แข็งแกร่งและการออกแบบซอฟต์แวร์รุ่นเก่าใหม่ไปพร้อมๆ กันอาจเป็นกระบวนการที่ท้าทายและใช้เวลานาน

อย่างไรก็ตาม เราได้ปรับปรุงการเดินทางครั้งนี้ออกเป็นห้าขั้นตอนที่แตกต่างกัน ซึ่งทำหน้าที่เป็นรากฐานในการชี้แนะทีมของเราในการเริ่มต้นที่ถูกต้อง

ขั้นตอนที่ 1: กำหนดข้อกำหนดที่จำเป็น

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

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

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

องค์ประกอบสำคัญคือความสามารถในการทดสอบ ข้อกำหนดที่เป็นลายลักษณ์อักษรอย่างดีทำให้สามารถสร้างชุดการทดสอบได้อย่างง่ายดายเพื่อยืนยันว่าเป็นไปตามข้อกำหนด

ข้อกำหนดทั้งชุดประกอบด้วยข้อความที่เป็นลายลักษณ์อักษรซึ่งขึ้นต้นด้วยวลีสำคัญ "the [product] should ... "

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

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

เมื่อเวลาผ่านไป เราสังเกตเห็นว่าวิศวกรและผู้จัดการจำนวนมากประสบปัญหาในการแยกความแตกต่างระหว่างส่วนประกอบหรือระดับต่างๆ ของวิศวกรรมเฟิร์มแวร์

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

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

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

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

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

ขั้นตอนที่ 3: การบริหารเวลา

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

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

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

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

การรวมฟังก์ชันการทำงานแบบเรียลไทม์ยังช่วยลดความยุ่งยากในการวิเคราะห์ที่จำเป็นในการพิสูจน์กำหนดเวลาการประชุม

ขั้นตอนที่ 4: การออกแบบที่เน้นการทดสอบ

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

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

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

3. การทดสอบหน่วยยืนยันว่าส่วนประกอบซอฟต์แวร์ที่กำหนดซึ่งระบุไว้ในการออกแบบระดับกลางนั้นทำงานตามที่นักพัฒนาตั้งใจไว้

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

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

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

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

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

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

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