Особливості розробки апаратних засобів МК-систем

Застосування однокристальних МК в пристроях керування об'єктами призвело до кардинальних змін в розробці апаратних засобів пристроїв і систем. І справа тут полягає в наступному. Мікроконтролер представляє собою логічний автомат з високою мірою детермінованості, який допускає досить мало варіантів його системного включення. Саме тому типовий склад апаратних засобів ядра будь-якої МК-системи (МК, ППЗП, ОЗП, інтерфейсні ВІС, схеми синхронізації і системного керування) оформляється конструктивно у вигляді одноплатних універсальних програмованих контролерів, які призначені для вбудовування в контур керування об'єктом або процесом. На друкованій платі такої МК-системи є гнізда для встановлення ВІС користувача. На деяких моделях таких плат є ще і так зване “монтажне поле користувача”, на якому він має можливість змонтувати свої специфічні схеми, такі як оптронні розв'язки, АЦП, ЦАП, реле і т.п. Крім того, на платі МК-системи може бути розміщене джерело електроживлення. Якщо розробник покладе в основу виробу, що проектується, такий одноплатний контролер, то він буде позбавлений від необхідності розробляти і супроводжувати конструкторською і експлуатаційною документацією найбільш складну, центральну частину виробу. Як відомо, вага документації на систему автоматичного керування приблизно на порядок перевищує вагу самої системи, а виготовлення і узгодження цієї документації розтягується на роки. При використанні стандартного контролера як комплектуючого системного елемента об'єм документації на апаратурні засоби виробу скорочується в багато разів і може містити тільки документацію на апаратуру сполучення ядра системи з датчиками і виконуючими механізмами об'єкта керування.

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

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

Особливості розробки прикладного програмного забезпечення

МК-систем

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

При цьому в самому загальному випадку необхідно виходити з того, що використання спеціалізованих інтерфейсних ВІС спрощує розробку і забезпечує високу швидкодію системи загалом, але зв'язано із збільшенням вартості, об'єму і споживаної потужності. Більша питома вага програмного забезпечення дозволяє скоротити кількість компонентів системи і вартість її апаратурних засобів, але це призводить до зниження швидкодії, збільшення витрат і термінів розробки та відлагодження прикладних програм. При цьому ще може дещо збільшитися і кількість ВІС зовнішньої пам'яті МК-системи. Рішення про вибір того або іншого варіанта розподілу функцій між апаратними і програмними засобами системи приймається в залежності від тиражності виробу, обмежень за вартістю, об'ємом, споживаною потужністю та швидкодією виробу. Попутно зазначимо, що термін існування виробу, в якого більша частина функцій реалізована в програмному забезпеченні, зростає в багато разів за рахунок того, що термін “морального старіння” виробу може бути істотно відсунений. Програмна реалізація основних елементів алгоритму роботи контролера допускає модифікацію відносно простими засобами (шляхом перепрограмування), в той час як можливість зміни вже існуючої фіксації елементів алгоритму в апаратурі контролера практично відсутня.

Досить поширена практика роботи “тандемом”, коли над розробкою прикладних програм для МК спільно працюють професійний програміст і непрограмуючий професіонал, тобто фахівець, який володіє “таємницями ремесла” в конкретній предметній області, має серйозним недоліком те, що при спробах викласти програмісту значення прикладної задачі, це значення часто вислизає. Внаслідок такої практики формалізуються і програмуються найбільш очевидні, грубо кажучи – тривіальні, прикладні задачі, а найбільш професіонально цікаві залишаються поза межами досяжності. Видимо, це пояснюється тим, що час, необхідний на формалізацію професійних знань при роботі “тандемом”, нерідко складає до 70 % всього часу, що вимагається для отримання закінченого мікроконтролерного виробу.

Робота “тандемом” у величезній більшості випадків призводить до того, що кінцевий користувач МК-системи відмовляється від своїх раніше сформульованих вимог на програму і стверджує, що “малося на увазі щось схоже, але не це”. Таке положення пояснюється тим, що початок процесу програмування задач, які ставить кінцевий користувач, негайно змінює його власне уявлення про ці задачі. Відмітимо попутно, що до 60 % помилок прикладних програм для МКП і МКС викликані не помилками в машинних кодах, не логічними помилками в програмі, а помилковою формалізацією прикладної задачі. Трудомісткість усунення цих помилок, напрацьованих “тандемом” (професійний програміст – непрограмуючий професіонал), така велика, що часто змушує приступити до розробки прикладної програми МК-системи наново і з іншими засобами.

Ресурси, що затрачуються власне на програмування, тобто на отримання машинних кодів, незначні в порівнянні з ресурсами, що затрачуються на процес формалізації прикладної задачі та розробку алгоритму, тому потрібно говорити не про проблему розробки прикладного програмного забезпечення МК-систем, а про проблему формалізації професійних знань кінцевого користувача мікроконтролерних виробів.

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

Структура трудовитрат, що склалася до теперішнього часу в розробці МК-систем, дозволяє виділити три основні стадії проектування прикладного програмного забезпечення:

1) аналіз предметної області з метою визначення задач, автоматизація рішення яких на основі МК обіцяє найбільший ефект;

2) розробку алгоритму рішення поставленої задачі (або комплексу задач);

3) власне програмування, або, точніше, супровід розробки прикладних програм системними засобами підтримки проектування.

Поиск по сайту: