เครื่องมือหรือมาตรฐานใดที่สามารถใช้เพื่อปรับปรุงความน่าเชื่อถือของรหัส C แบบฝัง

ฉันมักจะเขียนโปรแกรม PICs ใน C โดยปกติสำหรับตัวแปลงโหมดสวิตช์ ฉันเคยได้ยินเครื่องมือและมาตรฐานการวิเคราะห์แบบคงที่ต่างๆเช่นMISRA Cที่สามารถใช้เพื่อช่วยปรับปรุงความน่าเชื่อถือของรหัส ฉันต้องการทราบข้อมูลเพิ่มเติม มาตรฐานหรือเครื่องมือใดที่อาจเหมาะสมกับบริบทของฉัน

การตรวจสอบรหัสในตัวนั้นมีความยุ่งยากโดยเฉพาะอย่างยิ่งเมื่อต้องรับมือกับส่วนที่มีทรัพยากร จำกัด เช่น PIC คุณมักจะไม่ได้มีความหรูหราของการเขียนโปรแกรมในกรณีทดสอบเนื่องจากข้อ จำกัด ของชิ้นส่วนและการเขียนโปรแกรมแบบ "เรียลไทม์" บนอุปกรณ์เหล่านี้

นี่คือแนวทางบางส่วนของฉัน:

1. เขียนสเป็คถ้าไม่มี:ถ้าคุณไม่ได้เข้ารหัสสเป็คให้จดบันทึกรหัสของคุณว่าอะไรคืออินพุตที่ถูกต้องอะไรคือเอาท์พุทที่คาดหวังเอาท์พุทแต่ละครั้งควรใช้เวลานานเท่าไร การอุดตัน ฯลฯ - ทฤษฎีของการดำเนินงานผังงานอะไรดีกว่าไม่มีอะไร

2. แสดงความคิดเห็นรหัสของคุณ:เพียงเพราะสิ่งที่ชัดเจนสำหรับคุณไม่ได้หมายความว่ามันชัดเจน (หรือถูกต้อง) กับคนอื่น ความคิดเห็นภาษาธรรมดามีความจำเป็นสำหรับทั้งการตรวจสอบและการบำรุงรักษารหัส

3. การป้องกันโค้ด:อย่าใส่รหัสสำหรับอินพุตปกติ จัดการอินพุตที่ขาดหายไปอินพุทที่อยู่นอกระยะทางล้นทางคณิตศาสตร์ ฯลฯ - ยิ่งคุณครอบคลุมการออกแบบโค้ดมากเท่าไหร่ก็จะยิ่งมีอิสระมากขึ้นในการปรับใช้โค้ด

4. ใช้เครื่องมือวิเคราะห์แบบคงที่:มันสามารถทำให้เครื่องมือที่บั๊กเช่น PC-lint สามารถหาได้ในโค้ดของคุณ พิจารณาการวิเคราะห์แบบสแตติกที่สะอาดเป็นจุดเริ่มต้นที่ดีสำหรับการทดสอบอย่างจริงจัง

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

6. การทดสอบมีความสำคัญ:คุณควรทำการตรวจสอบความถูกต้องของคุณเองรวมถึงการตรวจสอบความถูกต้องของรหัสด้วยตนเอง คนอื่น ๆ สามารถทำลายรหัสของคุณในแบบที่คุณนึกไม่ออก ทดสอบทุกเงื่อนไขที่ถูกต้องและทุกเงื่อนไขที่ไม่ถูกต้องที่คุณสามารถนึกถึง ใช้ PRNG และป้อนข้อมูลขยะทำสิ่งที่คุณทำได้เพื่อทำลายสิ่งต่างๆจากนั้นซ่อมแซมและลองอีกครั้ง หากคุณโชคดีคุณจะสามารถเรียกใช้รหัสของคุณในโหมดแก้ไขข้อบกพร่องและดูที่การลงทะเบียนและตัวแปร - ถ้าไม่คุณจะต้องมีฝีมือและสลับไฟ LED / สัญญาณดิจิตอลเพื่อรับทราบสถานะของคุณ เครื่อง ทำทุกสิ่งที่จำเป็นเพื่อรับความคิดเห็นที่คุณต้องการ

7. ดูใต้ฝากระโปรง:อย่ากลัวที่จะดูรหัสเครื่องที่คอมไพเลอร์ C สร้างขึ้น คุณอาจจะ (จะ?) หาสถานที่ที่รหัส C อันสวยงามของคุณระเบิดออกมาเป็นสิบถ้าไม่ใช่การดำเนินการหลายร้อยครั้งซึ่งสิ่งที่ควรจะปลอดภัย (เนื่องจากเป็นรหัสบรรทัดเดียวใช่มั้ย) ใช้เวลานานในการดำเนินการขัดจังหวะหลายครั้ง ได้ไล่ออกและยกเลิกเงื่อนไข หากบางสิ่งบางอย่างไม่มีประสิทธิภาพอย่างน่ากลัวให้ทำการตั้งค่าใหม่และลองอีกครั้ง

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

ฉันจะไม่ละทิ้ง C. ในขณะที่ภาษาเช่น Ada สามารถให้การรับรองเล็กน้อยบางอย่างมันง่ายที่จะตกหลุมพรางของการคิดว่าภาษาสัญญามากกว่าที่เป็นจริง

MISRA-C นั้นมีประโยชน์มากในการปรับปรุงคุณภาพรหัสทั่วไปและลดข้อบกพร่อง เพียงให้แน่ใจว่าคุณอ่านและเข้าใจกฎทุกข้อส่วนใหญ่ดี แต่กฎบางข้อก็ไม่สมเหตุสมผล

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

เอกสาร MISRA-C มีสองเวอร์ชันที่อาจมี MISRA-C: 2004 ซึ่งยังคงเป็นมาตรฐานอุตสาหกรรมแบบฝังตัวในปัจจุบัน หรือ MISRA-C: 2012 ใหม่ซึ่งรองรับมาตรฐาน C99 หากคุณไม่เคยใช้ MISRA-C มาก่อนฉันจะแนะนำให้คุณใช้งานหลัง

โปรดทราบว่าผู้ขายเครื่องมือมักจะอ้างถึง MISRA-C: 2004 เมื่อพวกเขาบอกว่าพวกเขามีการตรวจสอบ MISRA (บางครั้งพวกเขาก็อ้างถึงรุ่น MISRA-C: 1998 ที่ล้าสมัย) เท่าที่ฉันรู้การสนับสนุนเครื่องมือสำหรับ MISRA-C: 2012 ยังมี จำกัด ฉันคิดว่ามีนักวิเคราะห์สแตติกเพียงบางส่วนเท่านั้นที่ได้นำไปใช้งาน: Klocwork, LDRA, PRQA และ Polyspace อาจมีมากขึ้น แต่คุณต้องตรวจสอบว่า MISRA รองรับเวอร์ชันใดอย่างแน่นอน

ก่อนที่จะตัดสินใจคุณสามารถเริ่มต้นด้วยการอ่านเอกสาร MISRA และดูว่ามีอะไรบ้าง สามารถซื้อได้ในราคา 10 ปอนด์จากmisra.orgราคาค่อนข้างไม่แพงเมื่อเทียบกับราคามาตรฐาน ISO

Mathworks (กลุ่ม MATLAB) มีเครื่องมือวิเคราะห์รหัสแบบคงที่ที่เรียกว่าPolyspace Polyspace

เช่นเดียวกับการวิเคราะห์โค้ดแบบคงที่ผ้าสำลีและสิ่งที่คล้ายกันฉันขอแนะนำนิยามและการออกแบบอินเตอร์เฟสอย่างระมัดระวัง (พร้อมกระบวนการตรวจสอบอย่างเป็นทางการ) และการวิเคราะห์ความครอบคลุมโค้ด

คุณอาจต้องการดูแนวทางในการออกแบบรหัสเพื่อความปลอดภัยที่สำคัญรวมถึง MISRA แต่ยังรวมถึงมาตรฐาน UL1998 และ IEC 61508

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

ดังนั้นเริ่มต้นด้วยข้อกำหนดและเขียนและตรวจสอบสิ่งเหล่านั้น หากคุณไม่มีเอกสารข้อกำหนดให้ชี้ไปที่บรรทัดของโค้ดแบบสุ่มและถามตัวเองว่า "เหตุใดจึงต้องมีบรรทัดนั้น" ความต้องการโค้ดในบรรทัดใด ๆ ในที่สุดควรตรวจสอบย้อนกลับไปยังข้อกำหนดได้แม้ว่าจะง่าย / ชัดเจนเหมือนกับ "แหล่งจ่ายไฟจะส่งออก 5VDC หากอินพุตอยู่ระหว่าง 12-36VDC" วิธีหนึ่งในการคิดเกี่ยวกับสิ่งนี้คือถ้าบรรทัดของโค้ดนั้นไม่สามารถตรวจสอบข้อกำหนดได้คุณจะรู้ได้อย่างไรว่าเป็นโค้ดที่ถูกต้องหรือจำเป็นต้องใช้เลย?

ถัดไปตรวจสอบการออกแบบของคุณ มันก็โอเคถ้ามันอยู่ในโค้ดอย่างสมบูรณ์ (เช่นในคอมเม้นท์) แต่มันทำให้ยากที่จะรู้ว่าถ้าโค้ดนั้นทำในสิ่งที่มีความหมายจริงๆ ตัวอย่างเช่นรหัสอาจมีสายที่อ่านoutput = 3 * setpoint / (4 - (current * 5)); คือcurrent == 4/5การป้อนข้อมูลที่ถูกต้องที่อาจก่อให้เกิดความผิดพลาดหรือไม่? ในกรณีนี้ควรทำอย่างไรเพื่อป้องกันการหารด้วยศูนย์? คุณหลีกเลี่ยงการดำเนินการทั้งหมดหรือลดเอาต์พุตแทนหรือไม่? การมีหมายเหตุทั่วไปในเอกสารการออกแบบของคุณเกี่ยวกับวิธีจัดการกับเคสแบบขอบทำให้ง่ายต่อการตรวจสอบการออกแบบในระดับที่สูงขึ้น ดังนั้นตอนนี้การตรวจสอบรหัสทำได้ง่ายขึ้นเพราะมันเป็นเรื่องของการตรวจสอบว่ารหัสถูกต้องใช้การออกแบบที่

นอกจากนั้นการตรวจสอบรหัสควรตรวจสอบข้อผิดพลาดทั่วไปที่ IDE ของคุณไม่ได้รับ (คุณใช้ IDE ใช่ไหม) เช่น '=' เมื่อคุณหมายถึง '==' วงเล็บปีกกาที่หายไปซึ่งเปลี่ยนความหมายของ 'ถ้า งบ, อัฒภาคที่พวกเขาไม่ควรเป็นต้น

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