3. Требования пользователей и функциональная спецификация.

3.1. Требования пользователей.

Требования пользователей определяют, что должна делать сис­тема для реализации своих функций и выясняются обычно во время встреч с пользователем, а также при планировании ассортимента изделий при изучении рынка сбыта на основе спроса заказчиков.

Требования пользователей строятся на основе описания автома­тизируемой технологии. Именно на этом этапе необходимо опреде­лить математическую модель описывающую поведение объекта, описать физические величины входящие в модель и требования к точности реализации модели.

3.2. Функциональная спецификация.

Функциональная спецификация должна определять какие функции должны выполняться для удовлетворения требований пользователей и обеспечения интерфейса между системой и окружением. Таким образом, функциональная спецификация включает два основных ком­понента:

1. Список функций, выполняемых системой.

2. Описание интерфейса между системой и пользователем.

Так как система проектируется на основе информации, содержа­щейся как в требованиях пользователей, так и в функциональной спецификации, важно чтобы функции, которые должны отображать требуемое поведение системы, были описаны достаточно детально.

Функциями МП системы управления являются действия системы по:

а) преобразованию физических величин, характеризующих объект управления, в сигналы приемлемые для обработки в ЭВМ;

б) вводу и обработке цифровых сигналов с целью удовлетворе­ния требованиям точности и надежности управления;

в) расчету управляющих воздействий;

г) формированию управляющих воздействий;

д) выводу и преобразованию управляющих воздействий в форму, приемлемую для взаимодействия с устройствами электроавтоматики.

Информация, описывающая интерфейс, должна быть достаточной для проектирования элементов УСО. Она должна содержать элект­рические и иные характеристики выходных сигналов датчиков и входных сигналов устройств управления.

Функциональная спецификация может включать схемы и рисунки частей системы.

Для сложных систем применяется декомпозиция системы на несколько подсистем. Функциональная спецификация строится для каждой из них в отдельности. Допускается любое описание функ­ций системы, вплоть до представления их реализации и принципа действия.

Важно, чтобы система выполняла только то, что ожидает от нее потребитель.

Учет человеческого фактора при проектировании системы должен приводить к:

а) простоте системы;

б) легкости ее использования.

Эти цели достигаются посредством проектирования надлежащего системного интерфейса, обеспечивающего экономный обмен инфор­мацией между оператором и машиной. Это позволяет уменьшить затраты на обучение оператора и не требует больших усилий при взаимодействии с системой.

4. Проектирование системы.

После того как определена функциональная спецификация, стро­ят предварительный набросок, начальный проект системы, путем декомпозиции системы на модули. Функциональное назначение мо­дулей и их состав определяют из функциональной спецификации.

Как только система расчленена на модули, надо отделить аппа­ратные модули от программных. Аппаратные модули проектируются и реализуются с использованием стандартных электронных компо­нентов. Программные модули разбиваются на множество процедур, каждая из которых соответствует отдельной функции (подфунк­ции).

Построенная таким образом структура системы, должна соот­ветствовать функциональной спецификации и называется функцио­нальной моделью системы.

Проектирование сводится к постепенной деталировке программ­ных и аппаратных модулей путем детализации выполняемых ими функций. Такой метод проектирования называется нисходящим про­ектированием.

4.1. Выбор соотношения между программными и аппаратными средствами.

На самом начальном этапе проектирования важно решить какие функции лучше выполняются с помощью программного обеспечения, а какие с помощью аппаратных средств. Все функции должны быть распределены между программными и аппаратными средствами.

Некоторые функции можно выполнить только аппаратными средствами, а некоторые только программно. Большинство функций может быть реализовано альтернативными путями. Поэтому очень важно на самом начальном этапе проектирования определить соот­ношение между программной и аппаратной реализациями и не вносить в проект никаких изменений, хотя на практике подобные модификации имеют место. В любом случае, следует помнить, что модификация проекта дешевле модификации изделия.

Критериями выбора способа реализации функций должны быть на­дежность, качество выполнения функции и стоимость реализации. При этом надежность зависит от количества компонентов, состав­ляющих систему. Качество выполнения функции определяется мно­гими факторами, в том числе и характеристиками электронных компонентов, включая и микропроцессор. Стоимость реализации функций программным путем, как правило, существенно дешевле и надежнее аппаратной реализации.

4.2. Нисходящее проектирование.

Проектирование системы может быть разделено на несколько функциональных уровней. Высший - наиболее общий, низший - наи­более детализированный.

Высший уровень для аппаратных средств состоит из структурных схем, обозначающих приближенное разбие­ние. Декомпозиция блоков продолжается до тех пор, пока не бу­дет достигнут уровень таблиц соединений или монтажных схем.

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

На нижних уровнях детализации ПО более тесно связано с аппа­ратурой. Поэтому, часто возникает желание начать проектирова­ние именно с таких уровней, т.к. они кажутся наиболее легкими и понятными. Этого следует избегать по следующим причинам:

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

- Если стоимость и затраты времени на проектирование на не­котором этапе превышают допустимые, и если, при этом, модули верхнего уровня уже работают, можно временно исключить те из функций, которые еще не завершены. При этом, система хотя и не будет полностью соответствовать требованиям пользователей или функциональной спецификации, но уже будет действовать, де­монстрируя возможность завершения. Если же используется метод "снизу вверх", трудно будет завершить проектирование верхних уровней системы, не продемонстрировав возможностей ее функцио­нирования вообще.

4.3. Проектная спецификация.

Проектная спецификация содержит специфическую информацию, связанную с реализацией системы. Проектная спецификация должна содержать схему или список подсистем, модулей, принадлежащих каждой подсистеме и процедуре, принадлежащей каждому модулю.

Составляется предварительный иерархический список процедур. Этот список, или дерево вызова процедур, указывает порядок вы­зова процедур.

Данные, обрабатываемые системой, должны быть организованы в структуры данных и приведены их описание. Каждое описание структуры данных должно содержать информацию об организации данных, о месте их хранения в системе и о методах доступа к ним.

В итоге проектная спецификация должна содержать:

список подсистем;

список модулей ПО;

дерево вызова процедур;

описание структур данных;

и др. информацию необходимую для понимания

системы на уровне проектирования.

4.4. Проверка проекта.

Чтобы система соответствовала требованиям пользователей, ее проект должен периодически подвергаться проверке в течение всего цикла проектирования, с привлечением для обсуждения, если это возможно, пользователей.