Які інструменти або стандарти можна використовувати для підвищення надійності вбудованого коду С?

Я, як правило, програмую PIC на C, як правило, для перетворювачів переключеного режиму. Я чув про різні інструменти та стандарти статичного аналізу, такі як MISRA C, які можна використовувати для підвищення надійності коду. Я хотів би дізнатися більше. Які стандарти чи інструменти можуть відповідати моєму контексту?

Перевірка вбудованого коду є складною, особливо при роботі з обмеженими ресурсами, такими як PIC. У тестових випадках у вас часто немає розкоші кодування через обмеження пам’яті деталі та часто програмування в режимі реального часу, що виконуються на подібних пристроях.

Ось деякі мої вказівки:

1. Напишіть специфікацію, якщо такої немає: Якщо ви не кодуєте специфікацію, задокументуйте, що має бути ваш код, які є дійсні входи, які очікувані результати, скільки часу має тривати кожна програма, що можна і чого не можна отримати clobbered тощо - теорія роботи, блок-схеми, що-небудь краще, ніж нічого.

2. Прокоментуйте свій код: Просто те, що для вас щось очевидно, не означає, що це очевидно (або правильно) для когось іншого. Прості коментарі на мові необхідні як для огляду, так і для ремонту коду.

3. Код захисно: Не включайте лише код для звичайних входів. Поводьтеся з відсутніми входами, входами, які знаходяться поза межами діапазону, математичними переповненнями тощо - чим більше кутів ви покриваєте своїм кодовим дизайном, тим меншою мірою буде свобода коду при розгортанні.

4. Використовуйте інструменти статичного аналізу. Це може бути прискіпливим лише те, скільки інструментів помилок, таких як PC-lint, можна знайти у вашому коді. Розгляньте чистий статичний аналіз як хороший вихідний пункт для серйозних випробувань.

5. Експертна оцінка є важливою: Ваш код повинен бути чітким та добре задокументованим, щоб його можна було ефективно переглянути незалежною стороною. Перевірте своє его у дверях і серйозно подумайте про будь-яку критику чи пропозиції.

6. Тестування є важливим: ви повинні зробити власну перевірку, а також провести незалежну перевірку коду. Інші можуть зламати ваш код таким чином, якого ви не можете собі уявити. Перевірте кожну дійсну умову та кожну недійсну умову, яку ви можете придумати. Використовуйте PRNG та подайте дані про сміття. Зробіть усе можливе, щоб зламати речі, потім відремонтуйте та спробуйте ще раз. Якщо вам пощастить, ви зможете запустити свій код у режимі налагодження та зазирнути до регістрів та змінних - якщо ні, то вам знадобиться бути хитрими та перемикати світлодіоди / цифрові сигнали, щоб отримати уявлення про стан свого пристрій. Зробіть все необхідне, щоб отримати необхідний відгук.

7. Подивіться під капот: не бійтеся переглядати машинний код, сформований вашим компілятором C. Ви можете (будете?) Знаходити місця, де ваш прекрасний код C вибухнув на десятки, якщо не сотні операцій, де щось, що повинно бути безпечним (оскільки це лише один рядок коду, правда?), Займає стільки часу, щоб виконати це кілька переривань звільнили та визнали недійсними умови. Якщо щось стає жахливо неефективним, перефактуруйте його та спробуйте ще раз.

Більшість тих же методів створення надійного програмного забезпечення на ПК також застосовні для вбудованої розробки. Корисно відокремити алгоритми від специфічного для апаратури коду та протестувати їх окремо за допомогою тестів, моделювання, статичного аналізу та таких інструментів, як Valgrind. Таким чином, існує набагато менше коду, який перевіряється лише на апаратному забезпеченні.

Я б не відмовлявся від C. Хоча такі мови, як Ада, можуть дати невеликі гарантії, легко потрапити в пастку мислення, якою мова обіцяє більше, ніж насправді.

MISRA-C дійсно дуже корисний для покращення загальної якості коду та мінімізації помилок. Просто переконайтеся, що ви читаєте та розумієте кожне правило, більшість із них хороші, але деякі з них не мають жодного сенсу.

Тут попередження. Документ MISRA передбачає, що читачем є людина з великими знаннями мови С. Якщо у вас немає такого загартованого ветерана 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 .

Окрім статичного аналізу коду, вкладишів тощо, я б запропонував ретельне визначення та дизайн інтерфейсів (з формальним процесом огляду) та аналіз покриття коду.

Можливо, ви також хочете ознайомитись із вказівками щодо розробки коду з критичним для безпеки, включаючи MISRA, а також стандарти UL1998 та IEC 61508.

Для повної відповіді на це питання я б придушив думку про "надійність коду" і замість цього подумав про "надійність дизайну", оскільки код - лише остаточний вираз дизайну.

Отже, почніть з вимог і напишіть та огляньте їх. Якщо у вас немає документа з вимогами, вкажіть на випадковий рядок коду і запитайте себе "для чого потрібен цей рядок?" Необхідність будь-якого рядка коду повинна врешті бути простежена до вимоги, навіть якщо це так просто / очевидно, як "джерело живлення виводить 5В постійного струму, якщо вхід знаходиться між 12-36В постійного струму". Один із способів думати про це полягає в тому, що якщо цей рядок коду неможливо простежити до вимоги, то як ви знаєте, що це правильний код або що він взагалі потрібен?

Далі перевірте свій дизайн. Це нормально, якщо він повністю міститься в коді (наприклад, у коментарях), але це ускладнює розуміння того, чи робить цей код дійсно мається на увазі. Наприклад, у коді може бути рядок, який читає output = 3 * setpoint / (4 - (current * 5)); Чи current == 4/5дійсний вхід, який може спричинити збій? Що слід зробити в цьому випадку, щоб запобігти діленню на нуль? Ви взагалі уникаєте операції або замість цього погіршуєте вихід? Маючи загальну примітку у своєму проектному документі про те, як поводитися з такими крайовими корпусами, це набагато простіше перевірити дизайн на більш високому рівні. Отже, зараз перевірка коду простіша, тому що це питання перевірити, чи правильно реалізується цей дизайн.

Поряд із цим, перевірка коду повинна перевірити наявність поширених помилок, які не виявляє ваш IDE (ви використовуєте IDE, правда?), Наприклад "=", коли ви мали на увазі "==", відсутні дужки, які змінюють значення "якщо 'заяви, крапки з комою, де їх не повинно бути тощо.

Коли я це пишу, мені здається, що насправді важко узагальнити роки навчання / досвіду якості програмного забезпечення в одній посаді. Я пишу код для медичних приладів, і вищесказане є надзвичайно спрощеним підсумком того, як ми підходимо до нього.