Як ви структуруєте великі вбудовані проекти? [зачинено]

Фон :

Молодший інженер з науково-дослідної роботи та електроніки ( єдиний EE в компанії ) - апаратне забезпечення та кодування не є проблемою. Моє найбільше питання - це правильний огляд проекту та з чого почати.

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

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

Що я зараз роблю :

Я, як правило, починаю, замальовуючи функціональність проекту. Це може бути одна з багатьох багатошарових діаграм потоку або пов'язаних з ними діаграм (блок-діаграм тощо) та проведення деяких досліджень компонентів / мікросхем. Тоді я стрибаю прямо в кодування (я думаю, що не вдалося швидко), посилаючись на таблиці / Інтернет, кодуючи одну функціональність за один раз і тестуючи її за допомогою фіктивних даних або подібний тест. Це може записувати дані в мікросхему MEM, і тоді, якщо це працює, то це може бути драйвер SPI між основним і мікросхемою MEM.

Яку відповідь я шукаю :

Все, що насправді. Я розберуся, що вважаю розумним. Це може бути книга, стаття, особистий досвід, рекомендації тощо.

Мені дуже цікаво знати, як старші люди вирішують це.

Редагувати

По-перше, дякую за те, що ви поділилися багаторічним досвідом! Усі відповіді високо оцінені. Моє взяти з цього є;

• Створіть чіткий і точний специфікаційний документ.
• Створіть проект програмного документа. (Щось зараз я додам) Шаблони doc для дизайну
• Подумайте в модулях, як це може здатися зайвим. (Щось мені потрібно більше зосередитись)
• Дотримуйтесь стандарт кодування для структурування файлів заголовків / вихідних файлів. (Ніколи цього не робив) Стандарт Barr Group C
• Спершу зупиніться на створенні низькорівневих реалізацій. (Спілкування тощо)
• Застосовуйте дизайнерські зразки, коли це можливо / розумно. Шаблони дизайну
• Налаштуйте щось для контролю версій (Github тощо - ніколи не використовувався так багато)
• Дослідження безперервної інтеграції / постійного розгортання (щось нове, на що я натрапив) основи CI та CD

Існує кілька аспектів, що впливають на ступінь деталізації структури потреб проекту. Для мене одним з головних факторів є те, чи я єдиний кодування (який, здається, має місце для вас, коли ви пишете, що ви єдиний EE), або якщо в ньому беруть участь інші. Тоді виникає питання, що насправді означає "великий". Зазвичай я поділяю процес проектування на наступні етапи:

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

Межі системи та ремонтопридатність У вбудованих системах у вас часто є деякі системні інтерфейси, деякі зовні (оператор), а також зсередини. Визначте це добре і намагайтеся зберегти залежності як можна нижчими, це спростить постійну інженерію та ремонтопридатність. Також коментуйте / кодуйте документ, де це потрібно, ви ніколи не знаєте, кому ще доведеться працювати з ним (и), він буде радий, що не доведеться копати хоча б десяток шарів коду, перш ніж насправді дізнатися, що робить функція.

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

Однією з інших функцій Люди люблять прогрес, тому якщо у вас є різноманітні завдання, вони зазвичай працюють над тим, що обіцяє найбільший прогрес. Зазвичай я намагаюся закінчити завдання і довести його до перевіреного і перевіреного стану, перш ніж розпочати з наступного. Це дозволяє перевірити свій код іншими, і ви не забудете щось забути.

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

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

Я колись був на посаді ОП - не єдиний ЕЕ, а єдиний ЕЕ, який робив будь-яку розробку MCU в невеликій компанії.

Я не можу наголосити на важливості модульності , навіть якщо ви єдиний розробник. Це єдиний спосіб бути здоровим у міру розвитку проекту. Потрібно бути чіткими щодо написання модулів, які працюють лише з однією функціональною концепцією, і зберігати їх зовнішні інтерфейси на мінімальному рівні. Модулі високого рівня відповідатимуть функціональним вимогам, тоді як модулі низького рівня будуть тісно пов'язані з апаратними ресурсами (тобто драйверами пристроїв).

Я витратив багато часу на підтримку детальної діаграми потоку даних ¹ , яка точно показала, як різні модулі обмінюються інформацією. Деякі функції матимуть дуже різні вимоги щодо продуктивності в режимі реального часу; переконайтеся, що ви знаєте, як впливає на це обмін інформацією. Діаграма мала межі, накреслені на ній, які відокремлювали непереривний код від різних областей, керованих перериванням.

¹ Дуже відрізняється від блок-схеми, орієнтованої на контрольний потік.

У будь-якому великому проекті я планую це так, ніби в ньому беруть участь кілька розробників, навіть якщо я маю намір зробити все це самостійно.

Причини прості:

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

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

3 Розбиття. Є два основні типи розбиття; функціональність обладнання та апаратне / програмне забезпечення. Перший тип полягає у визначенні того, які окремі (але комунікаційні) функціональні блоки повинні бути присутніми. Друга - це компроміс більш простого (іноді) апаратного та програмного забезпечення, але майте на увазі, що просто переміщення більшої кількості речей до програмного забезпечення не обов'язково вирішить апаратну проблему. Більше використання програмного забезпечення може фактично значно збільшити складність обладнання в деяких обставинах (більше обробних кінських сил, складніших інтерфейсів тощо).

4 інтерфейси. Процес розподілу допоможе визначити внутрішні інтерфейси; зовнішні інтерфейси зазвичай є частиною загальних вимог (хоча не завжди). Існує багато способів взаємодії різних частин системи, які можуть бути складним протоколом зв'язку або просто доброю / поганою сигналізацією.

5 Перевірка. Це суміш тестування низького рівня (для апаратних засобів та драйверів) та системного рівня. Зробивши проект у чітко визначених блоках, дозволяє зробити надійну перевірку (яка може бути за допомогою аналізу або фактичного тесту і зазвичай є сумішшю цих двох; оновлення конструкцій можуть використовувати аргументи подібності).

6 стандартів. Я використовую стандарти кодування та малювання так, ніби це була більша команда. Я використовую стандарти кодування групи Barr, оскільки вони не надто обтяжливі, але заважають багатьом класам помилок знаходитися в коді. Для вихідної документації на друковану плату я дотримуюся IPC-D-326 (який викликає IPC-D-325), тому що це перевірений спосіб передачі моїх намірів виробникам та монтажникам друкованих плат. Це може здатися дивним, але дисципліна дотримуватися ряду стандартів означає, що якість відповідає.

7 Контроль версій. Я використовую контроль ревізії для всіх частин проекту (система, апаратне забезпечення, програмне забезпечення. Механічні, вимоги до тестування - все). Інструменти CAD, які я використовую, підтримують таку версію, як і все програмне забезпечення та засоби збирання FPGA.

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

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

Інші відповіді дають багато чудових порад. Ось два, які я визнав найважливішим у своїй вбудованій кар'єрі:

1. Складіть якомога більше коду в окремі, чітко визначені модулі.
2. Зробіть модулі автоматично перевірятими на ПК.

Ось що вам потрібно для розвитку стилю "безперервної інтеграції" у вбудованих системах. Завжди знайдеться кількість коду, який занадто щільно прив'язаний до обладнання для автоматичного тестування, але намагайтеся його мінімізувати. Ви можете дістатись досить далеко, використовуючи імітовані дані або фіксацію даних із фактичного обладнання, яке потім подаєте в тестову систему.

Щоб додати до існуючих відповідей ...

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

Коли ви будуєте інтерфейси низького рівня, звичайно, вам потрібен тестовий джгут. Якщо ви спроектуєте це підключення до ПК з самого початку (можливо, з портом RS-232, можливо, USB, можливо, телнет через Ethernet), тоді ви можете тримати цей інтерфейс тестового ремесла на місці під час створення програми. Ви можете продовжувати додавати більше гачків тестових джгутів, коли додаток формується, і це дозволить вам регресувати тест коду під час продовження роботи.

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

1. Вони насправді хочуть системи? Чи вирішить система проблеми з клієнтами за часом та масштабом витрат, які вони приймуть? Поширеною проблемою є побудова систем, якими замовник не буде користуватися.

2. Чи можемо ми реально побудувати цю систему? Чи можливо буде забезпечити необхідну продуктивність, точність, енергоспоживання, ...?

Створення ранніх прототипів - хороший спосіб відповісти на ці два перші запитання. Пом'якшення ризиків надзвичайно важливе на ранніх етапах.

Наступні два питання більш орієнтовані на пізніші етапи проекту:

3. ми насправді закінчили? Все розроблено, закодовано, протестовано, поставлено

4. Чи реально вони використовують систему?