МК-систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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