Программное обеспечение управления автоматизированным комплексом многоканальной связи

ВведениеДанный дипломный проект выполнен на актуальнуюдля предприятий-производителей устройств связи тему, тесно связанную среальными планами исследований и производства, решая практическую задачу поразработке и внедрению программного обеспечения управления автоматизированнымкомплексом многоканальной связи. По своему характеру проект являетсяопытно-конструкторским. Разработанное обеспечение для изделия ТС16Е1 полностьюудовлетворяет техническому заданию. По своему содержанию дипломный проектсоответствует современному уровню науки и техники.В процессе решения задачи создания программногопродукта детально были рассмотрены особенности разработки программного обеспечениядля микропроцессорных систем, устройство и принципы работы микропроцессоровсерии МК51 вообще, интерфейсы в системах связи, основы асинхроннойпоследовательной связи, общие методы ввода / вывода через коммуникационныйпорт и изучен информационный обмен контроллер-ЭВМ с использованием интерфейса RS‑232.Подробное описание структуры программы, алгоритмов построения и работы всехтрех ее частей дает полное представление о ее создании, использовании ипринципах работы.В технологической части разработки программныхсистем и программной документации освещены этапы решения задачи на ЭВМ,принципы тестирования программ и их отладка. Целый раздел посвящен вопросамнадежности программного обеспечения.В организационно-экономической части расчетазатрат на разработку программного продукта после подробного анализасоставляющих затрат приведен расчет конкретно для этого программного продукта.

1.Специальная часть
1.1Постановка задачи проекта
Целью представленного дипломного проектаявляется разработка программного обеспечения управления автоматизированнымкомплексом многоканальной связи, построенного на базе микроконтроллера AT89C51,представляющего собой высокопроизводительный микропроцессор, особенностикоторого будут рассмотрены ниже. Комплекс представляет собой 16 линейныхинтерфейсов, обеспечивающих связь через мультиплексор на входе идемультиплексор на выходе общего высокоскоростного канала связи. Каждыйинтерфейс является коммутатором связи еще нескольких десятков устройств связи.Структурная схема основных частей автоматизированного комплекса многоканальнойсвязи представлена на рисунке 1.1.
/>

Внешняя
ПЭВМ  
MUX
DMUX  
Блок линейных интерфейсов LI1 – LI16                                                                     
/>/>/>                                                                  
/>Е1                                                               Е3, Е4/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />

Рис. 1.1. Структурная схема основныхчастей комплекса
Блок линейных интерфейсов состоит из 16 независимых коммутаторных устройств,работающих с сигналами на скорости Е1. Каждый интерфейс имеет в своем составе 8управляющих регистров, которые отображают состояние его работы. При измененииусловий работы интерфейса, состояния линии связи или неполадок в самомустройстве регистры изменяют свое содержимое, благодаря чему можно однозначноопределить причину неисправности.
Блок управления обеспечивает передачу данных регистров линейных интерфейсовна внешнюю ПЭВМ. Основной частью блока управления является микроконтроллерАТ89С51. Связь организуется через последовательный порт процессора Р3 по RS‑232‑муинтерфейсу.
Мультиплексор и демультиплексор являются блоками передачи сгруппированного сигнала соскоростью Е3, Е4, работая в режиме дуплекса. На принимающей стороне стоятзеркально такие же демультиплексор и мультиплексор соответственно.
Внешняя ПЭВМ, общаясь через последовательный порт микроконтроллераАТ89С51 с блоком управления, получает необходимую информацию о состоянии работывсех 16‑ти линейных интерфейсов, контролируя таким образом весь комплексудаленно. Для самой ПЭВМ таких комплексов может быть несколько.
Разработанное программное обеспечение позволитконтролировать нормальную работу комплекса, взаимодействуя с внешней ПЭВМ по RS‑232‑муинтерфейсу. К данному программному продукту предъявляются следующие требования:
1.        Программное обеспечение дляпроцессора АТ89С51 должно быть разработано в соответствии с общим алгоритмом ПОизделия ТС16Е1;
2.        Использовать ОЗУ данныхпроцессора АТ89С51 для хранения карты памяти состояний части битов регистровCR1, CR2, TSR и PSR 16‑ти линейных интерфейсов по заданным адресам взаданном порядке;
3.        Обеспечить своевременноеобновление карты памяти состояний части битов регистров CR1, CR2, TSR и PSRвсех интерфейсов;
4.        Обеспечить передачу картыпамяти состояний оговоренных регистров, взаимодействуя с внешней ПЭВМ,используя интерфейс RS‑232, через последовательный порт Р3.
/>1.2 Особенностиразработки программного обеспечения для микропроцессорных систем
В устройствах управления объектами на основе МПаппаратные средства и программное обеспечение существуют в форме неделимогоаппаратно-программного комплекса. При проектировании контроллеров приходитсярешать одну из самых сложных задач разработки, а именно задачу оптимальногораспределения функций контроллера между аппаратными средствами и программнымобеспечением. Решение этой задачи осложняется тем, что взаимосвязь ивзаимовлияние аппаратных средств и программного обеспечения в микропроцессорнойтехнике претерпевают динамичные изменения. Если в начале развития МП – техникиопределяющим было правило, в соответствии с которым аппаратные средства обеспечиваютпроизводительность, а программное обеспечение – дешевизну изделия, то внастоящее время это правило нуждается в серьёзной корректировке. Так как МПпредставляет собой стандартный массовый логический блок, конкретное назначениекоторого определяет пользователь с помощью программного обеспечения, то сростом степени интеграции и, следовательно, функционально-логическихвозможностей МП резко понижается стоимость изделия в пересчёте на выполняемуюфункцию, что в конечном итоге и обеспечивает достижение высокихтехнико-экономических показателей изделий на МП. При этом затраты на разработкупрограммного обеспечения изделия в 2 – 10 раз превышают затраты на приобретениеи изготовление аппаратных средств.
В настоящее время наибольшее распространениеполучил методологический приём, при котором весь цикл разработки контроллероврассматривается как последовательность трёх фаз проектирования:
1.        Анализ задачи и выбора аппаратныхсредств контроллера;
2.        Разработка прикладногопрограммного обеспечения;
3.        Комплексирование аппаратныхсредств и программного обеспечения в прототипе контроллера и его отладки.
Фаза разработки программного обеспечения, т.е.Фаза прикладных программ, в свою очередь, разбивается на два существенноразличных этапа:
1.        От постановки задачи кисходной программе;
2.        От исходной программы кобъектному модулю.
Этап разработки «от исходной программы кобъектному модулю» имеет целью получение машинных кодов прикладных программ,работающих в МП. Этот этап разработки прикладного программного обеспечениялегко поддаётся формализации и поддержан всей мощью системного программногообеспечения МП, направленного на автоматизацию процесса получения прикладныхпрограмм. В состав средств системного программного обеспечения входяттрансляторы с различных алгоритмических языков высокого уровня, ассемблеры,редакторы текстов, программы – отладчики, программы – документаторы, и т.д.Наличие всех этих системных средств придаёт инженерной работе на этом этапепроектирования контроллеров характер простого конструирования, без большогообъёма творческой инженерной деятельности. Так как на конечном изделии имеютсятолько «голый» МП и средства его сопряжения с объектом, то выполнять отладкуразрабатываемого прикладного программного обеспечения на нём невозможно, и,следовательно, разработчик вынужден обращаться к средствам вычислительнойтехники для выполнения всех формализуемых стадий разработки: трансляции,редактирования, отладки, загрузки объектных кодов в программируемую постояннуюпамять МП. Попутно отметим, что системные средства автоматизации разработкиприкладных программ МП на этапе «от исходной программы к объектному модулю»широко распространены и существуют в среде операционных систем микроЭВМ иприсутствуют в операционных системах персональных компьютеров как отдельныепакеты инженерных программ.
Совсем по другому выглядит инженерный труд наэтапе разработки программного обеспечения «от постановки задачи к исходнойпрограмме», так как он практически не поддаётся формализации и, следовательно,не может быть автоматизирован. Проектная работа здесь носит творческийхарактер, изобилует решениями, имеющими сугубо субъективную окраску, ирешениями, продиктованными конъюнктурными соображениями. В силу перечисленныхобстоятельств именно на этапе проектирования «от постановки задачи к исходнойпрограмме» разработчик сталкивается с наибольшим количеством трудностей.
Качество получаемого прикладного программногообеспечения контроллера всецело зависит от уровня проектных решений, принятыхна этапе «от постановки задачи к исходной программе». Уровень проектныхрешений, в свою очередь, из-за отсутствия теории проектирования программируемыхконтроллеров определяется только опытом, квалификацией и интуициейразработчика. Однако накопленный опыт убеждает в том, что систематическийподход к процессу разработки прикладных программ для контроллеров обеспечиваетдостижение хороших результатов даже начинающими разработчиками.
1.3 Использование контроллера АТ89С51
На данный момент широко применяются микроконтроллеры серииМК51. Существует обширная техническая документация и что самое главное широкийвыбор отладочных средств от эмулятора ПЗУ и отладочного монитора довнутрисхемного эмулятора. Процессоры данной серии достаточно универсальны дляуспешного применения в микроэлектронике, что позволяет их использовать как приразработке простых систем, так и при создании сложных модулей электроннойаппаратуры.
Рассмотрим микроЭВМ серии МК51 более подробно.
1.3.1 Основные программно-доступные устройства микроконтроллераАТ89С51
Основными программно-доступными устройствамимикроконтроллера AT89C51 являются:
1)  8‑разрядный аккумуляторА;
2)  8‑разрядныйвспомогательный регистр AВ;
3)  триггеры признаков результата:C, OV, P, отрицательности, нуля;
4)  триггеры выбора банка рабочихрегистров RS0 и RS1;
5)  триггерпрограммно-управляемого флага F0;
6)  16‑разрядный счетчиккоманд PC;
7)  16‑разрядный региструказателя данных DPTR;
8)  8‑разрядный региструказателя стека SP;
9)  внутренняя память программ емкостью4 Kb, расширяемая внешними устройствами до 64 Kb;
10)внутренняя память данных емкостью 128 байт, в которойразмещается от одного до четырех банков рабочих регистров R0‑R7, областьстека и побитово адресуемая область памяти;
11)внешняя память данных емкостью до 64 Kb;
12)два программируемых 16‑разрядных таймера-счетчика;
13)программируемый двунаправленный последовательный портввода-вывода и соответствующие устройства управления;
14)четыре 8‑разрядных двунаправленных параллельных портаввода-вывода;
15)двухуровневую приоритетную систему прерываний с пятьювекторами и двумя уровнями;
16)последовательный интерфейс;
17)тактовый генератор.
1.3.2 Структурная схема микроЭВМ серии МК51
Система команд микроЭВМ серии МК51 содержит 111базовых команд с форматом 1, 2 или 3 байта. Микроконтроллер имеет:
·          32 РОН;
·          128 определяемых пользователемпрограммно-управляемых флагов;
·          набор регистров специальныхфункций.
РОН и определяемые пользователемпрограммно-управляемые флаги расположены в адресном пространстве внутреннегоОЗУ данных.
Важнейшей и отличительной чертой архитектурысемейства МК51 является то, что АЛУ может наряду с выполнением операций над 8‑разряднымитипами данных манипулировать одноразрядными данными. Отдельныепрограммно-доступные биты могут быть установлены, сброшены или заменены ихдополнением, могут пересылаться, проверяться и использоваться в логическихвычислениях. Тогда как поддержка простых типов данных может с первого взглядапоказаться шагом назад, это качество делает микроЭВМ семейства МК51 особенно удобнымдля применений, в которых используются контроллеры. Алгоритмы работы последнихпо своей сути предполагают наличие входных и выходных булевых переменных,которые сложно реализовывать при помощи стандартных микропроцессоров. Все этисвойства в целом называются булевым процессором семейства МК51. Благодарятакому мощному АЛУ набор инструкций микроЭВМ семейства МК51 одинаково хорошоподходит как для применений управления в реальном масштабе времени, так и дляалгоритмов с большим объёмом данных.

/>
Рис. 1.2а. Структурная схема МК51
/>
Рис. 1.2б. Структурная схема МК51
 
Блок управления предназначен для выработки синхронизирующих и управляющихсигналов, обеспечивающих координацию совместной работы блоков микроЭВМсемейства МК51 во всех допустимых режимах её работы. В состав блока управлениявходят устройство выработки временных интервалов, логика ввода-вывода, регистркоманд, регистр управления потреблением, дешифратор команд, ПЛМ и логикауправления ЭВМ.
Устройство выработки временных интервалов предназначено для формирования и выдачи внутреннихсинхросигналов фаз, тактов и циклов.
Логика ввода-вывода предназначена для приёма и выдачи сигналов, обеспечивающихобмен информацией ОМЭВМ с внешними устройствами через порты ввода-вывода Р0‑Р3.
Регистр команд предназначен для записи и хранения 8‑разрядного кодаоперации выполняемой команды, который с помощью дешифратора командпреобразовывается в 24‑разрядный код для ПЛМ, с помощью которойвырабатывается набор микроопераций в соответствии с микропрограммой выполнениякоманды. Регистр команд программно недоступен.
Регистр управления потреблением PCON управляет скоростью передачи последовательного порта SMOD.
Логика управления ЭВМ в зависимости от режима работы МИКРОЭВМ СЕМЕЙСТВА МК51вырабатывает необходимый набор управляющих сигналов.
АЛУ представляет собой параллельное восьмиразрядноеустройство, обеспечивающее выполнение арифметических и логических операций, атакже операции логического сдвига, обнуления, установки и т.п.
Регистр аккумулятора и регистр временногохранения – восьмиразрядныерегистры, предназначенные для приёма и хранения операндов на время выполненияопераций над ними. Программно недоступны.
ПЗУ констант обеспечивает выработку корректирующего кода придвоично-десятичном представлении данных, кода маски при битовых операциях икода констант.
Параллельный восьмиразрядный сумматор представляет собой схему комбинационного типа споследовательным переносом, предназначенную для выполнения арифметическихопераций сложения, вычитания и логических операций сложения умножениянеравнозначности и тождественности.
Регистр В-восьмиразрядный регистр, используемый во время операцийумножения и деления. Для других инструкций он может рассматриваться какдополнительный сверхоперативный регистр.
Аккумулятор представляет собой восьмиразрядный регистр,предназначенный для приёма и хранения результата, полученного при выполненииарифметико-логических операций или операций пересылки.
Регистр состояния программы предназначен для хранения информации о состоянии АЛУ привыполнении программы.
Таймеры / Счётчики предназначены для подсчёта внешних событий, для полученияпрограммно-управляемых временных задержек и выполнения времязадающих функцийОМЭВМ.
Блок последовательного интерфейса ипрерываний предназначен дляорганизации ввода-вывода последовательных потоков информации и организациисистемы прерывания программ.
Счётчик команд предназначен для формирования текущего 16‑разрядногоадреса внешней памяти данных.
Порты Р0, Р1, Р2, Р3 являются двунаправленными портами ввода-вывода ипредназначены для обеспечения обмена информацией микроЭВМ семейства МК51 свнешними устройствами.
Память данных предназначена для приёма, хранения и выдачи информации,используемой в процессе выполнения программы. Память данных, расположенная накристалле ОМЭВМ, состоит из регистра адреса ОЗУ, дешифратора, ОЗУ и указателястека.
Память программ предназначена для хранения программ и имеет отдельное отпамяти данных адресное пространство объёмом до 64 Кбайт.
1.3.3 Адресные пространства АТ89С51
В AT89C51 имеются следующие адресныепространства:
1.        Пространство адресов регистровспециальных функций, таких как аккумулятор А, вспомогательный регистр AВ, старшийи младший регистры указателя данных DPTR, фиксаторы портов ввода-вывода P0‑P3,регистр слова состояния программы PSW, регистр указателя стека SP и др.Диапазон адресов регистров специальных функций находится в пределах от 128 до255. При записи данных по адресу регистра несуществующей специальной функцииданные теряются, при считывании из регистра несуществующей специальной функцииданные не определенны;
2.        Пространство адресов триггеровспециальных функций, таких как триггеры признаков переноса C, переполнения OV,четности P, отрицательности N, нуля Z, триггеры выбора банка рабочих регистровRS0 и RS1; триггер программно-управляемого флага F0 и другие. Все триггерыспециальных функций физически размещаются в регистрах специальных функций.Наличие триггеров специальных функций определяется типом микроконтроллера.Диапазон адресов триггеров специальных функций находится в пределах от 128 до255. Части адресов соответствуют несуществующие триггеры. При записи бита поадресу несуществующего триггера этот бит теряется, при считывании бита изнесуществующего триггера его значение неопределенно;
3.        Пространство адресов памятипрограмм. Диапазон адресов этого пространства находится в пределах от 0 до65535. Память программ с адресами от 0 до 4096 может реализоваться внутреннимзапоминающим устройством. В пространстве адресов памяти программ размещаютсякоды команд и, возможно, данные. Часть адресов пространства памяти программзарезервирована для точек входа в программу начального запуска и программыобслуживания прерываний. Адрес команды, подлежащей выполнению, хранится всчетчике команд PC. Обращение к данным в памяти команд осуществляется по адресуравному сумме содержимого счетчика команд PC и аккумулятора A или регистрауказателя данных DPTR и аккумулятора A;
4.        Пространство адресов внешнейпамяти данных. Диапазон адресов этого пространства находится в пределах от 0 до65535. Во внешней памяти данных могут размещаться только данные, обращение ккоторым осуществляется посредством содержимого рабочего регистра-указателя R0,R1 или регистра указателя данных DPTR;
5.        Пространство прямых адресоввнутренней памяти данных. Диапазон адресов этого пространства находится впределах от 0 до 127. Обращение к данным в пространстве прямых адресовосуществляется посредством второго байта кода команды. Пространство адресоврегистров специальных функций является продолжением данного пространства;
6.        Пространство косвенных адресоввнутренней памяти данных. Диапазон адресов этого пространства находится впределах от 0 до 127. Пространство косвенных адресов от 0 до 127 физическисовпадает с пространством прямых адресов;
7.        Пространство поразрядныхпрямых адресов внутренней памяти данных. Диапазон адресов этого пространстванаходится в пределах от 0 до 127. Данное пространство физически совпадает спространством прямых адресов ячеек от 32 до 47. Пространство адресов триггеровспециальных функций является продолжением пространства поразрядных прямыхадресов;
8.        Пространство адресов стека.Диапазон адресов этого пространства находится в пределах от 0 до 127. Данноепространство физически совпадает с пространством косвенных адресов.Произвольный адрес верхушки стека можно установить, например, с помощьюкоманды:
MOV SP, #;
9.        Пространство рабочихрегистров, которое разделено на 4 банка. Каждый из банков содержит восемь 8‑разрядныхрабочих регистров R0 – R7. Диапазоны адресов пространства рабочих регистров вовнутренней памяти данных следующие:
Для нулевого банка:     0 – 7;
Для первого банка:       8 – 15;
Для второго банка:       16 – 23;
Для третьего банка:      24 – 31.
Выбор текущего банка рабочих регистров определяетсясодержимым триггеров специальных функций RS0 и RS1: Банк Нулевой Первый 1 Второй 1 Третий 1 1
Установить триггеры в требуемое состояние можно, например,посредством команд CLR RS0, CLR RS1, SETB RS0 и SETB RS1. Рабочие регистры R0 иR1 текущего банка могут использоваться при косвенной адресации внутренней ивнешней памяти данных.
Адресам памяти текущего банка рабочих регистров R0‑R7в языке ассемблера присвоены символические имена AR0‑AR7 соответственно.Распределение памяти ОЗУ процессора АТ89С51 представлено на рисунке 1.3.
/>
Рис. 1.3. Распределение памяти ОЗУпроцессора АТ89С51

1.3.4 Характеристики средств языка ассемблера
Средства языка ассемблера обеспечивают модульный способпостроения программы. Программный модуль, записанный на языке ассемблера,называется исходным модулем. Результат трансляции исходного модуля – объектныймодуль.
Исходная программа представляет собой последовательностьпредложений языка, сгруппированных в сегменты и оформленных в виде файла.Сегменты исходного модуля содержат описание машинных команд, данных, адресов ислужат для генерации абсолютных или перемещаемых сегментов объектного модуля.
В зависимости от устройства памяти и способа адресацииданных в этой памяти сегменты исходного модуля делятся на 4 типа:
·    CODE, который используется дляопределения команд, данных и адресов в пространстве памяти команд;
·    XDATA, который используетсядля определения адресов в пространстве внешней памяти данных;
·    DATA, который используется дляопределения прямых адресов в пространстве внутренней памяти данных;
·    IDATA, который используетсядля определения косвенных адресов в пространстве внутренней памяти данных;
·    BIT, который используется дляопределения прямых побитовых адресов в пространстве внутренней памяти данных.
При описании перемещаемого сегмента емуприсваивается имя и тип, а также определяется способ его объединения содноименными сегментами, описанными в других исходных модулях. Абсолютнымсегментам присваивается только тип. Они не могут быть объединены с другимисегментами.
В языке ассемблера имеются средства дляорганизации символических ссылок между различными программными модулями.
Программа в общем случае строится из набора абсолютных и перемещаемыхобъектных модулей и представляет собой абсолютный объектный модуль.
Преобразование исходного модуля в объектныйосуществляется ассемблером за два просмотра. В процессе первого просмотравыделяются все символические имена, определенные пользователем, а такжераспределяются адреса в соответствующих пространствах памяти. В процессевторого просмотра генерируется объектный модуль и формируется листинг,содержащий объектный код, соответствующий текст исходной программы и сообщенияоб ошибках. На этапе трансляции для каждого сегмента исходного модуля создаетсясвой счетчик адреса. В любой момент трансляции доступен только один счетчикадреса, называемый текущим.
1.4 Интерфейсы в системах связи
В условиях увеличивающейся сложностисовременной техники фирмы-производители уделяют всё большее вниманиестандартизации средств сопряжения. В первую очередь представляют интересоткрытые стандарты, позволяющие объединять в одну систему аппаратные ипрограммные средства различных производителей. Идея стандартизации интерфейсовне является новой в вычислительной технике, т.к. Использование стандартныхподходов повышает гибкость системы в целом, даёт экономию капиталовложений ваппаратное и программное обеспечение.
1.4.1 Классификация интерфейсов
Рассматривая интерфейсы, используемые визмерительных системах, их целесообразно разделить на крейтовые и межкрейтовые.Крейтовые стандартные интерфейсы удобно применять для построениясосредоточенных измерительных систем. При этом единая конструкция и общий блокпитания обеспечивают компактность и экономичность системы. Магистраль для связимодулей, которая располагается в крейте, обычно представляет собойвысокопроизводительный параллельный интерфейс. Межкрейтовые интерфейсыиспользуются в случае построения локальных и рассредоточенных измерительныхсистем, которые строятся на основе отдельных приборов и модулей.
Межкрейтовые интерфейсы. В начале 70‑хгодов фирма Hewlett-Packard разработала восьмибитовое параллельное устройствосопряжения – «Hewlett-Packard Interface Bus» – для связи между измерительнымиприборами и управляющим компьютером на расстояниях до 20 м. И со скоростьюдо 1Мбит/с. В 1975 г. HP-IB был приведен IEEE к национальному стандартуСША IEEE‑488, а в 1987 г. Опубликована его последняя версия: IEEE‑488.2.Международная электротехническая комиссия выпустила аналогичный стандарт вноябре 1976 г. В России этот тип интерфейса стандартизован ГОСТ 26.003–80 «Системаинтерфейса для измерительных устройств с байт последовательным, битпараллельным обменом информацией» и известен также под названием «приборныйинтерфейс» и «канал общего пользования». Стандарт IEEE‑488 получилширокое распространение и поддерживается почти всеми производителями измерительныхприборов. Он даёт возможность объединять до 15 различных приборов в локальнуюизмерительную систему, управляемую компьютером.
Следующая большая группа межкрейтовыхинтерфейсов – последовательные интерфейсы. Преимуществами этихинтерфейсов является значительная экономия средств благодаря меньшемуколичеству проводов в используемых кабелях связи и простоте гальваническойразвязке. Хотя некогда последовательный канал связи автоматически означалзадержки при передаче информации, современные микропроцессоры могутобмениваться данными и по последовательным каналам со скоростями, вполнедостаточными для удовлетворения требований выдвигаемых пользователямиизмерительных систем.
Зарубежными организациями, выпускающимистандарты на последовательные каналы связи, получившие широкое распространение,являются американская Ассоциация электронной промышленности, Международныйконсультативный комитет по телеграфии и телефонии международная организация постандартизации.
В настоящее время существуют несколько широкоиспользуемых интерфейсов: RS‑232C/V.28, EIA‑232D/V.28, RS‑423,-422, – 485. Эти стандарты регламентируют обмен данными в последовательномканале на физическом уровне. Они учитывают особенности линии связи, рекомендуютоптимальные схемы соединения, оптимальные характеристики приёмников ипередатчиков. Принципиальное различие перечисленных интерфейсов состоит виспользуемом типе линий связи. В этом отношении интерфейсы можно разделить наоднопроводной, несимметричный, дифференциальный и симметричный дифференциальный.
К стандартам, описывающим однопроводнойинтерфейс, относятся EIA RS‑232C, EIA‑232D, аналогичные европейскиеспецификации CCITT V.24, V28 и рекомендация ISO 2110, а также российские ГОСТ18145–81, 23675–79.
Первоначально интерес RS‑232 был разработандля сопряжения терминалов с модемами. Сейчас этим интерфейсом комплектуетсябольшинство популярных компьютеров для связи с внешними устройствами, в томчисле и персональные компьютеры IBM PC. Поскольку ядром любой современнойизмерительной системы служит компьютер, использование штатного машинногоинтерфейса – наиболее простой и дешёвый способ организации связи врассредоточенной системе.
1.4.2 Основы асинхронной последовательной связи
Говоря о передаче данных, мы интересуемся передачей байтовданных от одного устройства к другому, например, от персонального компьютера кмодему или к последовательному принтеру. Если мы имеем восемь линий между двумяустройствами, то мы можем назначить каждой линии бит и послать сразу один байтданных. Это будет параллельная передача. Таким образом работает параллельныйпорт персонального компьютера, кроме того, в дополнение к восьми линиям данныхимеются другие сигнальные линии, оказывающие помощь в передаче данных.
С другой стороны, если мы имеем одну линию дляпередачи сигналов, то необходимо посылать каждый байт данных последовательно,по одному биту. Более того, мы может посылать данные синхронно, таким образом,что каждый байт посылается в ранее определенное время, или асинхронно соскоростью, которую предварительно определять необязательно.
Последовательная связь дешевле, чемпараллельная, так как требует меньше линий передачи данных – минимум две длядвусторонней связи. Кроме того режим асинхронной передачи оказывает значительноменьшее воздействие на аппаратуру ввиду того, что не требуется дополнительноеспециальное оборудование для поддержки синхронизации между передатчиком иприемником.
Таким образом, асинхронная последовательнаясвязь является предпочтительным решением ввиду низкой стоимости и простотыиспользуемых аппаратных средств. Конечно, в этом режиме передачи мы должныпреобразовывать каждый байт данных в серию битов и указывать приемнику начало иконец каждого байта.
Предположим, что мы умеем преобразовыватькаждый байт в поток единиц и нулей, то есть биты, которые могут быть переданычерез среду связи. В самом деле, универсальный асинхронный приемопередатчик,как мы увидим в следующем разделе, выполняет точно такую же функцию. Обычно, вто время как линия находится в режиме ожидания, для демонстрации того, чтолиния в порядке, по ней передается единица, обозначая незанятость линии. Сдругой стороны, когда линия находится в состоянии логического нуля, говорится,что она стоит в режиме выдерживания интервалов. Таким образом, логическиеединица и ноль рассматриваются, соответственно, как MARK и SPACE.
В асинхронной связи изменение условия состояниялинии с MARK на SPACE означает начало символа). Это называется стартовым битом.За стартовым битом следует комбинация битов, представляющая символ, и затем битконтроля четности. Наконец, линия переходит в состояние ожидания MARK, котораяпредставляет собой стоповый бит и означает конец текущего символа. Число битов,используемых для представления символа, называется длиной слова и обычно бываетравно семи или восьми. Контрольный бит используется для выполнения элементарнойпроверки на наличие ошибки.
/>
Рис. 1.4. Представление в асинхроннойпоследовательной связи формата одиночного символа. A‑длительность 1 бита;B-MARK или 1; C-SPACE или 0
Как передатчик узнают о длительности каждогобита? Действительно, и передатчик, и приемник должны знать его длительность илидетектирование битов будет невозможно. Длительность каждого бита определяетсягенераторами тактовых импульсов приемника и передатчика. Отметим, однако, чтогенераторы в приемнике и передатчике должны иметь одну и ту же частоту, но нетребуется, чтобы они были синхронизированы. Выбор частоты генератора зависит отскорости передачи в бодах, которая означает число изменений состояния линиикаждую секунду. Номинально тактовая частота «16‑кратная скорость передачив бодах» означает, что линия проверяется достаточно часто для надежногораспознавания стартового бита.
Существует одно обычное состояние линии,которое иногда используется для привлечения внимания приемника. Нормальнымсостоянием линии является MARK и начало символа определяется переходом SPACE. Еслилиния находится в состоянии SPACE в течение периода времени большем, чем время,которое она затратила бы на получение всех битов символа, тогда мы говорим, чтонаступило состояние BREAK. В кодах ASCII отсутствует представление BREAK – этоозначает, что линия «умерла» на непродолжительный промежуток времени, которыйсоставляет BREAK.
Ранее мы упоминали, что бит контроля четностиполезен для обнаружения ошибок. Например, если выбрана проверка на четность,этот бит устанавливается таким образом, что общее число единиц в текущем словеявляется четным. В приемнике четность вычисляется заново и сравнивается с битомконтроля четности. Если они не равны, то приемник сообщает, что имеет местоошибка четности. Главный недостаток обнаружения ошибки посредством проверки начетность заключается в том, что можно только обнаружить ошибки, которые влияютна один единственный бит. Например, битовая комбинация 0100 0001 0, переданнаявосемью битами с проверкой на четность, может измениться на 0100 01110, однакоприемник не обнаружит ошибку, так как проверка на четность выполняется.
В дополнение к квитированию установления связипосредством аппаратных сигналов RTS/CTS, для достижения управления потоком сиспользованием программного обеспечения применяются специальные управляющиесимволы ASCII. Управлять потоком необходимо ввиду того, что иногда либопередатчик либо приемник не могут поддерживать скорость передачи и они должныиметь возможность информировать другую сторону о необходимости остановки навремя, требуемое для того, чтобы отставшая сторона смогла догнать другую.
Предположим, что приемник имеет буфер дляхранения поступающих символов. Как только буфер после заполнения закрывается,приемник может послать символ XOFF передатчику, сигнализируя, что передачадолжна быть приостановлена. Конечно, передатчик должен понять значение XOFF ипрекратить передачу символов. Затем, когда приемник обработает символы и буферосвободится, тогда посылается символ XON, показывающий, что передача может бытьпродолжена. Эта схема управления потоком широко применяется ввиду ее простоты.Большинство связных программ предоставляют возможность дуплексной связи суправлением потоком, основанном на применении символов XON/XOFF.
1.5 Общие методы ввода / вывода через коммуникационный порт
Существует два общих метода ввода / выводав любой вычислительной системе: упорядоченный и управляемый прерываниями.Упорядоченность относится к повторяющейся проверке состояния регистраустройства ввода / вывода для инициализации требуемой транзакции. Вупорядоченном вводе / выводе программа, запрашивающая символ ввода,многократно считывает состояние регистра в устройстве ввода / вывода дотех пор, пока оно не покажет, что символ доступен для ввода. Когда состояниеуказывает, что имеется готовый для работы символ, программа считывает его изсоответствующего регистра устройства ввода / вывода. Сходнаяпоследовательность «ждать, до тех пор пока не готов, затем писать» используетсяпри выведении символов на устройство ввода / вывода. Таким образом,дальнейшее выполнение программы приостанавливается до завершения выполненияоперации ввода / вывода.
Большой проблемой для упорядоченного ввода /вывода через коммуникационный порт является то, что при скорости передачи выше300 бод программе трудно что-либо сделать с получаемым символом кроме какотображать его на экране. Рассмотрим следующий пример. Предположим, что мычитаем символы со скоростью 300 бод и имеем следующие связные параметры: длинаслова 7 бит, проверка на четность и один стоповый бит, который вместе состартовым битом, добавляет до 10 бит на символ. Ожидается получать около 30символов каждую секунду. После чтения символа программа имеет около 1/30секунды для выполнения других операций. Чтобы не потерять какие-либо символы вэто время следует снова начать упорядочение порта. Что произойдет, когдаскорость возрастет до 9600 бод? Временной интервал между символами слишком малдля выведения символа на экран дисплея, не позволяет интерпретироватьспециальные символы и эмулировать терминал.
В подходе, основанном на управлениипрерываниями, программа предоставляет возможность прерываниям устройства ввода /вывода поступать непосредственно на центральный процессор, который продолжаетвыполнять свою работу, не связываясь с устройством. Когда устройство готово квводу / выводу, оно сигнализирует об этом центральному процессорупосредством аппаратуры. Получив этот сигнал, центральный процессор сохраняетсвое текущее состояние и вызывает подпрограмму обслуживания прерываний, адрескоторой хранится в таблице векторов прерываний. Эта подпрограмма выполняетоперацию ввода / вывода, затем восстанавливает состояние машины ивозвращается в прерванную программу. Также стоит учитывать регистр символов,поступающих в коммуникационный порт персонального компьютера. Организовавгде-нибудь некоторые ячейки памяти, можно использовать простую подпрограммуобработки прерываний, которая быстро считывает символ из коммуникационногопорта и сохраняет его в следующей доступной ячейке памяти в буфере. Символы небудут утеряны в процессе считывания и сохранения символа драйвером прерыванийперед поступлением следующего символа. Эта несложная задача достаточно простадля выполнения в короткие временные интервалы между поступающими символами прискорости передачи 9600 бод. Прелесть этого метода заключается в том, что времяобработки главной программой символов, хранящихся в буфере, не имеет значения.Конечно, существует риск переполнения буфера, но эта проблема может быть решенапростым увеличением его размера. Если этот способ не очень хорош, то дляизбежания переполнения буфера можно использовать управление потоком с помощьюXON/XOFF.
Из этих рассуждений становится очевидно, чтоуправляемая прерываниями буферная связь с использованием управления потоком спомощью XON/XOFF, предпочтительнее упорядоченной связи.
1.5.1 Последовательный порт с точки зрения программиста
Скорость передачи в бодах определяется как 16‑битовыйделитель тактовой частоты, используемой для последовательного адаптера. Значениеделителя вычисляется по формуле
1,843,200
делитель= –––––––––––––––––––––––––––––––
16 Х скорость передачи в бодах
Чтобы установить скорость передачи в бодах, Выдолжны проделать следующее:
1.        Установить в 1 наиболеезначимый бит регистра управления линией.
2.        Загрузить младший и старшийбайты делителя соответственно в приемный буфер и регистр разрешения прерываний.
3.        Установить DLAB в 0 дляобеспечения нормальной работы универсального асинхронного приемопередатчика.
Применяя этот подход, можно установить любоезначение скорости передачи в бодах. Максимально возможной скоростью передачиявляется 1/16 тактовой частоты, или 115,200 бод. Этот предел вытекает из того,что делитель не может быть меньше единицы.
1.6 Информационный обмен контроллер – ЭВМ с использованиеминтерфейса RS‑232
Для связи МК51 с интерфейсом RS‑232 можноиспользовать самый подходящий для этого вариант – последовательный порт.
Последовательный порт микроЭВМ семейства МК51может использоваться в виде регистра сдвига для расширения ввода-вывода или вкачестве универсального асинхронного приемопередатчика с фиксированной илипеременной скоростью последовательного обмена и возможностью дуплексноговключения. Последовательный порт может принимать очередной байт, даже если ужепринятый до этого байт не был прочитан из регистра приёмника. Однако если доокончания приёма, находящийся в регистре приёмника байт не будет прочитан топринятый байт теряется. Программный доступ к регистрам приёмника и передатчикаосуществляется обращением к регистру специальных функций SBUF. При записи вSBUF байт загружается в регистр передатчика, а при чтении SBUF байт читается изрегистра приёмника.
Приём и выдача байта данных начинается смладшего разряда и заканчивается старшим разрядом. Для разрешения приёманеобходимо установить 1 в разряде REN регистра управления SCON.
Последовательный порт может бытьзапрограммирован на один из четырёх режимов приёма / передачи путёмпрограммирования разрядов SM0 и SM1 регистра SCON. Во всех четырёх режимахпередача инициируется любой командой, которая использует SBUF в качестверегистра назначения.
Режим 0. В этом режиме информация и передаётся и принимается черезвнешний вывод входа приёмника. Принимаются или передаются 8 бит данных. Черезвнешний вывод выхода передатчика выдаются импульсы сдвига, которые сопровождаюткаждый бит. Частота передачи бита информации равна 1/12 частоты резонатора.
Режим 1. В этом режиме передаются через TXD или принимаются из RXD10 бит информации: старт бит, 8 бит данных и стоп-бит. Скорость приёма / передачи– величина переменная и задаётся таймером.
Режим 2. В этом режиме через TXD передаются или из RXD принимаются11 бит информации: старт бит, 8 бит данных, программируемый девятый бит истоп-бит. При передаче девятый бит может принимать значение 0 или 1, или,например, для повышения достоверности передачи путём контроля по чётности внего может быть помещено значение признака паритета из слова состоянияпрограммы. Частота приёма / передачи выбирается программой и может бытьравна либо 1/32, либо 1/64 частоты резонатора в зависимости от управляющегобита SMOD.
Режим 3. Режим 3 совпадает с режимом 2 во всех деталях, заисключением частоты приёма / передачи, которая является величинойпеременной и задаётся таймером.
Передача начинается в фазе S1P1 машинногоцикла, следующего за ближайшим после ЗАПИСЬ В SBUF переполнением делителя на 16в цепи сигнала СИНХР Тх. Период сигнала СИНХР Тх определяет время, в течениекоторого выдаваемый бит присутствует на выходе TxD. Внутренние сигналы микроЭВМсемейства МК51 ПОСЫЛКА, ДАННЫЕ и СДВИГ по функциональному назначению иформированию идентичны во всех режимах. На выход TxD выдается девять битданных: D0‑D7 и TB8. После первого импульса СДВИГ в освободившийсядевятый разряд регистра сдвига передатчика заноситься 1. Всего формируется 9импульсов СДВИГ, в результате чего все биты регистра сдвига передатчикапоследовательно выдаются на выход TxD. По окончании выдачи всех бит посылкиблок управления передачей устанавливает флаг прерывания передатчика TI иснимает сигналы ПОСЫЛКА и ДАННЫЕ.
Приём начинается при обнаружении переходасигнала на входе RxD из 1 в 0. Для отслеживания такого перехода вход RxDаппаратно опрашивается с частотой f1. Когда переход обнаружен, немедленносбрасывается счетчик делитель на 16 в цепи сигнала СИНХР Rx, в результате чегопроисходит совмещение моментов переполнения этого счётчика делителя с границамисмены битов принимаемой посылки на входе RxD. Шестнадцать состоянийсчётчика-делителя делят время, в течение которого каждый бит принимаемой посылкиприсутствует на входе RxD, на 16 фаз, с 1 по 16 для каждого бита. В фазах 7, 8и 9 специальное устройство ОМЭВМ, бит-детектор, считывает с входа RxD 3значения принимаемого бита, по мажоритарному принципу «2 из 3» выбирает из ниходно и подаёт его на вход регистра сдвига приёмника. Блок управления приёмомпри этом формирует внутренний импульс МИКРОЭВМ СЕМЕЙСТВА МК51 СДВИГ, врезультате чего содержимое регистра сдвига приёмника сдвигается на один разряди принятый бит заносится в регистр сдвига приёмника. После 10 импульса СДВИГблок управления приёмом загружает биты D0‑D7 из регистра сдвига приёмникав SBUF, переписывает 9 разряд регистра сдвига приемника в бит RB8 регистра SCONи устанавливает флаг прерывания приёмника RI в регистре SCON. Сигнал загрузки SBUF,RB8 и установки RI вырабатывается блоком управления приёмом тогда и толькотогда, когда в момент генерации последнего импульса СДВИГ выполняются следующиеусловия: RI=0 и либо SM2=0, либо принятый 9 бит данных равен 0.
Если хотя бы одно из этих условий невыполняется, принятая посылка безвозвратно теряется, а флаг RI неустанавливается. Если оба приведённых условия выполнены, принятый 9 бит данныхпоступает в RB8, биты D0‑D7 записываются в SBUF и устанавливается флагRI. Независимо от выполнения приведённых выше условий последовательный портвновь начинает отслеживание перехода сигнала из 1 в 0 на входе RxD. Значениепринятого стоп-бита не влияет на SBUF, RB8 или RI.
Обмен между контроллером и ЭВМ производится врежиме полудуплекса, т.е. ЭВМ посылает байт, а контроллер отвечает. С ЭВМ поканалу RS‑232 приходит байт с установленным девятым битом, это означаетчто необходимо начать преобразование входного сигнала. Второй и последующийбайты посылаемые ЭВМ приводят к выталкиванию двух оцифрованных значений побайтно,старшими байтами вперёд, т.е. если первое слово обозначить H0L0, а второе H1L1то они будут переданы так: H0, L0, H1, L1. Затем контроллер передаётконтрольную сумму, которая подсчитывается по формуле: CRC = S + H0 + L0 + H1 +L1. Она служит для контроля за правильностью передачи данных. После передачиконтрольной суммы контроллер переходит в исходное состояние в котором он можетпринимать только байты с девятым битом равным единице.
1.7 Создание программы управления автоматизированным комплексоммногоканальной связи
Конкретная степень сложности данной системы определяется нетолько количественными характеристиками схемы, но и ее топологией. Поэтомустановится ясна необходимость выбора простого в реализации, быстрого, надежногои точного алгоритма.
Простота алгоритма в реализации необходима для удобства егопонимания и облегчения возможности усовершенствования, кроме того нельзязабывать, что чем алгоритм сложнее в реализации, тем вероятнее появление в немошибок, чего необходимо избежать. Под быстротой алгоритма понимаетсяспособность его к завершению за достаточно малое время, чем это время меньше – темлучше. Надежность алгоритма требует отсутствие «лишних» решений – решений,которые являются некорректными. Поэтому, при разработке программного обеспечениядолжны быть соблюдены следующие основные критерии:
1.        Надежность;
2.        Простота реализации;
3.        Точность;
4.        Скорость работы.
 
1.7.1 Структуры данных
Каждая программа оперирует с тремя видами данных – входными,выходными и промежуточными. Входные данные – это вся та информация, котораядоступна до начала выполнения, или вводится по мере работы программы. Выходныеданные – результат работы программы. Входные и выходные данные служат длякоммуникации с другими программами или с оператором, а промежуточные данныепредназначены для обработки, выполнения алгоритмов и прочих действий, результаткоторых не доступен вне программы. Соответственно, для процесса проектированияпрограммы необходимо проработать все три типа данных.
1.7.2 Составляющие программы
Программа управления автоматизированнымкомплексом многоканальной связи состоит из трех частей: основная программа,подпрограмма перезаписи карты памяти части битов внутренних регистров CR1, CR2, TSR и PSRлинейных интерфейсов, которая выполняется с приходом прерывания от любоголинейного интерфейса и подпрограмма связи с внешней ПЭВМ через последовательныйпорт, которая выполняется, когда приходит прерывание от последовательногопорта.
Система прерываний для микроконтроллера АТ89С51организована следующим образом. При приходе прерывания от последовательногопорта, выполняется специальная подпрограмма обработки этого прерывания. Как онаработает. Вначале производится проверка, и если приходит прерывание отпередатчика, то сбросить его и выйти. Если нет, то производится проверкаполученного байта, если пришёл байт с установленным 9 битом то выполняетсяинициализация процедуры чтения данных из памяти, затем подсчёт контрольнойсуммы, передача блока данных на ЭВМ и завершение подпрограммы. Если пришел байтбез установленного 9 бита, то если переданы все байты – передаётся контрольнаясумма, а если нет – передаётся байт и подсчитывается контрольная сумма.
В начале основной программы происходитназначение векторов прерываний от линейных интерфейсов и последовательногопорта. Далее идут два блока инициализации: области памяти ОЗУ данных с 40Н по 7FН исамих линейных интерфейсов. Команды инициализации последних CR2.RESET формируются в соответствии с таблицей адресов линейныхинтерфейсов и таблицей адресов внутренних регистров линейных интерфейсов.Регистр Bit 7 6 5 4 3 2 1 LI1 00Н LI2 1 10H LI3 1 20Н LI4 1 1 30H LI5 1 40Н LI6 1 1 50H LI7 1 1 60H LI8 1 1 1 70H LI9 1 80H LI10 1 1 90H LI11 1 1 A0H LI12 1 1 1 В0Н LI13 1 1 C0H LI14 1 1 1 D0Н LI15 1 1 1 E0H LI16 1 1 1 1 F0H Регистр Bit 7 6 5 4 3 2 1 CR1 00H CR2 1 02H CR3 1 04H CR4 1 1 1 0EH ICR 1 1 06H TSR 1 08H PSR 1 1 0AH ESR 1 1 0CH
Рис. 1.10. Адреса внутренних регистровлинейных интерфейсов.

Затем производится запись в ОЗУ данныхсостояний части битов внутренних регистров линейных интерфейсов. Данныерасполагаются в заранее оговоренной техническим заданием области памяти 40Н – 7FН взаданном порядке. Распределение памяти ОЗУ данных процессора показано нарисунке 1.11. Нужные биты выбираются из внутренних регистров линейныхинтерфейсов, таблица которых приведены на рисунке 1.12. Например, для занесениябита AIS в 1‑й бит ячейки памяти 40Н, его нужно считать из 2‑гобита регистра PSR LI1. Порядок сохраняется длявсей карты по возрастанию следующий: PSR, TSR, CR2, CR1.Линейный интерфейс Адрес регистра в ОЗУ Bit 7 6 5 4 3 2 1 L1 1 40 Н DFMO AIS LOS 41 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 42 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 43 Н ES4 ES3 ES2 ES1 L1 2 44 H DFMO AIS LOS 45 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 46 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 47 Н ES4 ES3 ES2 ES1 L1 3 48 Н DFMO AIS LOS 49 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 4A Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 4B Н ES4 ES3 ES2 ES1 L1 4 4C Н DFMO AIS LOS 4D Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 4E Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 4F Н ES4 ES3 ES2 ES1 L1 5 50 Н DFMO AIS LOS 51 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 52 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 53 Н ES4 ES3 ES2 ES1 L1 6 54 Н DFMO AIS LOS 55 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 56 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 57 Н ES4 ES3 ES2 ES1 L1 7 58 Н DFMO AIS LOS 59 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 5A Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 5B Н ES4 ES3 ES2 ES1 L1 8 5C Н DFMO AIS LOS 5D Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 5E Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 5F Н ES4 ES3 ES2 ES1 L1 9 60 Н DFMO AIS LOS 61 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 62 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 63 Н ES4 ES3 ES2 ES1 L1 10 64 Н DFMO AIS LOS 65 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 66 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 67 Н ES4 ES3 ES2 ES1 L1 11 68 Н DFMO AIS LOS 69 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 6A Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 6B Н ES4 ES3 ES2 ES1 L1 12 6C Н DFMO AIS LOS 6D Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 6E Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 6F Н ES4 ES3 ES2 ES1 L1 13 70 Н DFMO AIS LOS 71 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 72 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 73 Н ES4 ES3 ES2 ES1 L1 14 74 Н DFMO AIS LOS 75 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 76 Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 77 Н ES4 ES3 ES2 ES1 L1 15 78 Н DFMO AIS LOS 79 Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 7A Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 7B Н ES4 ES3 ES2 ES1 L1 16 7C Н DFMO AIS LOS 7D Н FL TQRSS ESOVR ESUNF TDFMO TAIS TLOS 7E Н ЕРАТ1 EPAT0 ETAOS EQZMON ERLOOP ELLOOP EALOOP 7F Н ES4 ES3 ES2 ES1
Рис. 1.11. Распределение памяти ОЗУ данных процессора.
Потом инициализируется последовательный порт Р3на прием. Инициализируется таймер, выбор 1‑го таймера, перевод его втретий режим работы, загрузка константы скорости в таймер для 9600 Бод,разрешение работы таймера. Инициализация последовательного порта проходитследующим образом: порт устанавливается в режим 9‑бит с программируемойскоростью, устанавливается адрес для записи принятых значений, выбираетсяномера канала, идет разрешение приёма сообщений с взведённым 9‑м битом,разрешение работы приёмопередатчика, разрешение прерываний отприёмопередатчика, общее разрешение прерываний, сброс бита разрешения приёма.После этого выполняется основной цикл программы: ожидание прерывания либо отлюбого из линейных интерфейсов с переходом на подпрограмму перезаписи картыпамяти части битов внутренних регистров линейных интерфейсов, либо отпоследовательного порта с переходом на подпрограмму связи с внешней ПЭВМ черезпоследовательный порт.
Подпрограмма перезаписи карты памяти части битов внутреннихрегистров линейных интерфейсов состоит из четырех последовательных вызововподпрограмм RDPSR, RDTSR, DRCR2 и RDCR1 с предварительнымзанесением в регистр R1 соответствующих адресов регистров, используя таблицу,приведенную на рисунке 1.10. Выполнение подпрограммы происходит в режимемаскирования прерываний. После перезаписи карты памяти снимаются все флагипрерываний линейных интерфейсов и происходит выход из подпрограммы.
Подпрограмма связи с внешней ПЭВМ черезпоследовательный порт вызывается при появлении прерывания от последовательногопорта. Она также с запрещения всех прерываний. Инициализируется прием ипрослушивается порт на приход старт байта. В случае его получения происходитинициализация чтения данных из памяти. Считается контрольная сумма для передачибита четности и происходит поблочная передача данных. Для передачи всех 64 байттребуется 64 сеанса связи. Такая организация работы выбрана не случайно. Вразделе, где упоминалось об основах асинхронной последовательной связи,приводились причины, по которым данный способ взаимодействия внешней ПЭВМ споследовательным портом является оптимальным. При втором сеансе связи приемастарт байта не происходит. Это говорит о продолжении уже начатой передачиданных. Смотрится, является ли этот байт признаком передачи последнего кусочкаданных. В этом случае считается контрольная сумма и выполнение подпрограммыпрекращается. Иначе мы продолжаем поблочно читать данные из памяти и передаватьих внешней ПЭВМ через последовательный порт.
1.7.3 Тестирование и отладка программы
После окончания этапа программирования, т.е.собственно процесса написания программы, проводится ее проверка для обнаруженияи исправления возможных ошибок. На эмуляторе микропроцессора АТ89С51проверяется корректность кода программы по содержимому различных регистровпроцессора. В контрольных точках программы, выбранных для удобства послекаждого логически законченного куска кода, мы смотрим содержимое регистра R7.Внесенные в программу отладочные строки для контроля ее пошагового выполненияпозволяют своевременно выявлять неточности реализации общего алгоритма изделияТС16Е1. Применение модульного принципа тестирования программы существеннооблегчает этот процесс.
Далее проверенный таким образом ассемблерныйтекст программы с помощью компилятора ассемблера микропроцессора АТ89С51переводится в hex‑файл. На этом этапе так же можно проконтролироватьвозможные неточности кода. При дальнейшем переводе этого текста программы вмашинный код, производится поиск синтаксических ошибок в программе и, в случаеих обнаружения, печатается диагностика, помогающая последующей локализацииошибок. Отсутствие синтаксических ошибок не говорит о том, что в программе нетошибок.
По окончании такой отладки программы начинаетсяее эксплуатация. С помощью программатора полученный машинный код прошивается втестовой ПЗУ с ультрафиолетовым стиранием, и начинается тестирование опытногообразца. Производится анализ работы системы в целом, обычно многократный. Первыеполученные результаты реальных данных подвергаются тщательному анализу, чтобыубедиться в пригодности использованного метода и установить согласованностьполученных результатов с имеющимися данными и теорией. Если правильностьполучаемых результатов не. вызывает сомнений и эффективность программыудовлетворительна, то ее эксплуатация продолжается. В случае отклонениярезультатов работы программы от ожидаемых, происходит возврат к поискувозможных ошибок на этапе кодирования общего алгоритма изделия ТС16Е1.1.7.4 Оформлениепрограммы и ее возможная модернизация
Для возможности эксплуатации программы кем-либокроме автора она должна быть оформлена. Составляется ее описание, излагаютсяпримененные методы решения, приводятся алгоритмы и текст программы. Наличиеописания программы позволяет не только успешно эксплуатировать ее длительноевремя, но и проводить ее модернизацию и использовать в дальнейших разработках.Основную часть описания составляют материалы, с которыми шла работа напредыдущих этапах разработки. Поэтому для ускорения этапа оформления всеперечисленные материалы всегда должны быть в рабочем состоянии и по содержаниювполне соответствовать друг другу и отлаженной программе, кроме того, уже наэтапах разработки их нужно представлять в таком виде, чтобы они могли бытьиспользованы для описания программы без дополнительных переделок. На основаниирезультатов, полученных в ходе эксплуатации программы, составляется отчет опроделанной работе, оценивается выбранный метод решения задачи и эффективностьпрограммы.
Если разработчик программы постоянно работает внекоторой области науки или техники, то обычно рано или поздно наступает такоймомент, когда перед ним возникает вопрос о модернизации старой программы или осоставлении новой, развивающей идеи, реализованные в прежней программе.Модернизация программы проходит те же этапы, что и разработка, и начинается ссоставления технического задания на модернизацию. Успешное осуществлениемодернизации зависит от того, насколько легко можно будет при разработке новойпрограммы использовать блоки старой программы и вносить в них изменения.Быстрое выполнение такого рода работ зависит, в свою очередь, как от структурымодернизируемой программы, так и от качества ее оформления.1.7.5 Надежностьпрограммного продукта
Надежность является одним изважнейших показателей качества программ, однако они характеризуются еще рядомфункциональных и конструкторских критериев качества, выбор которых взначительной степени зависит от их целевого назначения. Проблема обеспечения ианализа надежности систем может быть решена на базе системного подхода сдетально проработанной программой работ по исследованию и обеспечениюнадежности каждой подсистемы в течение всего жизненного цикла.
Программы, разрабатываемые для решения инженерныхи научно-исследовательских задач характеризуются неполным использованиемресурсов вычислительных систем и относительно небольшим временем жизненногоцикла. Длительность разработки этих программ обычно невелика. Их эксплуатацияносит эпизодический и кратковременный характер, отсутствуют жесткие ограниченияна допустимую длительность ожидания результатов, практически всегда имеетсявозможность достаточно строго проконтролировать выходные данные и принеобходимости поставить контрольные эксперименты. К этому типу программпрактически неприменимы основные понятия теории надежности. И тем не менее,основные принципы создания надежного программного обеспечения справедливы и вэтом случае.
Для определения надежности любых систем необходимопроводить регулярный или эпизодический диагноз их состояния. Теория, принципыпостроения средств и методы организации процесса диагноза систем развиваются втехнической диагностике. Их применение для анализа технического состояниякомплексов программ имеет ряд особенностей. Основные задачи техническойдиагностики включают в себя:
·          проверку исправности системы;
·          проверку работоспособностисистемы и возможности выполнения всех функций с характеристиками, заданнымитехнической документацией;
·          проверку правильностифункционирования в данном режиме работы в данный момент времени;
·          поиск и локализациюнеисправностей в системе.
Объем и последовательность проверок, а такжеметоды анализа результатов определяются алгоритмами диагноза. Основная задачадиагноза состоит в определении текущего состояния системы, как работоспособноготак и неработоспособного.
На надежность функционирования программного обеспечениявлияет структура и технология разработки программ. В зависимости отструктурного построения программы последствия ошибки могут быть локализованы внекотором небольшом участке программы и данных либо распространиться назначительно большое расстояние от места расположения ошибки. Строгоеиерархическое построение программы на базе единообразно оформленных законченныхпрограммных модулей обеспечивает снижение вероятности ошибки в каждой командепрограммы и снижает возможность распространения последствий ошибок за пределыпрограммного модуля. Выбранная в нашем случае линейная организация всех трехчастей программы существенно повышает надежность продукта в целом, облегчаеттестирование и отладку, поиск и исправление ошибок. Простота реализациизаложена в основу написания данной программы.В ходе выполнения данного дипломного проектабыла разработана программа управления автоматизированным комплексоммногоканальной связи. Предъявленные в техническом задании к проекту требованиявыполнены полностью: программное обеспечение для процессора АТ89С51 разработанов соответствии с общим алгоритмом ПО изделия ТС16Е1, ОЗУ данных процессора АТ89С51использовано для хранения карты памяти состояний части битов регистров CR1,CR2, TSR и PSR 16‑ти линейных интерфейсов по заданным адресам в заданномпорядке, обеспечено своевременное обновление карты памяти состояний части битоврегистров CR1, CR2, TSR и PSR всех интерфейсов через подпрограмму обработкипрерываний линейных интерфейсов, обеспечена возможность передачи карты памятисостояний оговоренных регистров, взаимодействуя с внешней ПЭВМ, используяинтерфейс RS‑232, через последовательный порт Р3. Подробно описанаструктура программы, алгоритмы построения и работы всех трех ее частей длядальнейшего использования, модернизации и возможного применения отдельно взятыхчастей кода при разработке подобных программных продуктов для устройств связи.
2. Технологическая часть2.1 Требования к программным системам
Каждая программа, входящая в систему, должна отвечать такимтребованиям, как:
·          правильность
·          точность
·          совместимость
·          надежность
·          универсальность
·          защищенность
·          полезность
·          эффективность
·          проверяемость
·          адаптируемость
Будем говорить, что программа является:
·          правильной, если онафункционирует в соответствии с техническим заданием. Подразумевается, чтотехническое задание составлено в четкой форме, позволяющей однозначно судить отом, действительно ли программа отвечает перечисленным в нем требованиям.
·          точной, если выдаваемая еючисловые данные имеют допустимые отклонения от аналогичных результатов,полученных с помощью идеальных математических зависимостей.
·          совместимой, если она работаетдолжным образом не только автономно, но и как составная часть всей программнойсистемы, осуществляющей обработку информации.
·          надежной, если она при всехусловиях обеспечивает полную повторяемость результатов. Любой человек, имеющийопыт работы с ЭВМ, может подтвердить, что в его практике еще не встречалось ниабсолютно надежного системного программного обеспечения, ни безукоризненноработающих машин. И, несмотря на оптимистичность высказываний некоторыхпрограммистов, то же самое можно сказать о прикладных программных системах.Впрочем, уровень их надежности может быть повышен за счет использованиявстроенных механизмов резервирования и самоконтроля.
·          универсальной, если онаправильно работает при любых допустимых вариантах исходных данных. В ходеразработки программ должны предусматриваться специальные средства защиты отввода неправильных данных, обеспечивающие целостность системы.
·          защищенной, если она сохраняетработоспособность при возникновении сбоев. Это качество особенно важно дляпрограмм, предназначенных для решения задач в режиме реального времени. Вподобных приложениях отказ оборудования может повлечь катастрофическиепоследствия – например, аварию ракеты или ядерного реактора. Указаннымсвойством должны также обладать программы с большим временем выполнения,осуществляющие обработку постоянно хранимых файлов.
·          полезной, если задачи, которыеона решает представляют практическую ценность.
·          эффективной, если объемтребуемых для ее работы ресурсов ЭВМ не превышает допустимых пределов.
·          проверяемой, если ее качествамогут быть продемонстрированы на практике. Здесь подразумевается возможностьпроверки таких свойств программы как правильность и универсальность. Можноприменить формальные математические методы, позволяющие установить,действительно ли программа удовлетворяет техническим условиям и выдаетдостаточно точные результаты. Однако существуют и неформальные способы оценкикачества программ, причем иной раз они оказываются более убедительными, чемформальные. Имеются в виду такие неформальные приемы, как прогоны с остановамив контрольных точках, обсуждение результатов с заинтересованными пользователямии др.
·          адаптируемой, если онадопускает быструю модификацию с целью приспособления к изменяющимся условиямфункционирования. Адаптируемость в значительной степени зависит от конструкциипрограммы, от того, насколько квалифицированно она составлена и полно снабженадокументацией.
Программы редко применяются как самостоятельные единицы.Чаще всего они являются элементами более крупных информационных систем,осуществляющих сбор, хранения и обработку данных. Такие системы становятсянеотъемлемой частью механизма функционирования предприятия, на которых ониэксплуатируются. Прямо или косвенно, они затрагивают деятельность множествалюдей, чтобы это воздействие носило положительный характер, программы не простодолжны быть полезными, надежными и эффективными, но должны явно обнаруживатьэти качества для тех, кто с ними работает. Иными словами, как процесспроектирования программной системы, так и его конечный продукт должны бытьориентированы на нужды пользователя.
Пользователи будут уверены в эффективностисистемы, если почувствуют, что в группе, занимающейся ее разработкой,прислушиваются к их пожеланиям, если найдут, что форма выходных данных ирезультатов удобна и близка к привычной, и, наконец, если им будетпродемонстрировано, что система должным образом перерабатывает информацию,отобранную по их собственному усмотрению./>
Программа должна быть построена таким образом,чтобы могла применяться в различных приложениях и обходится только имеющимисяаппаратными ресурсами и средствами программирования. Процесс разработкипрограммы в значительной степени зависит от наличия специализированных языковпрограммирования, каталогов данных, оптимизирующих компиляторов, генераторовтестовых задач. Существенно проще создать хорошую программу, располагаяэффективными вспомогательными средствами./>
Всякое использование ЭВМ предполагает стандартизацию данныхи способов обработки. Эффективная реализация преимуществ ЭВМ возможна лишь втех случаях, когда необходимо выполнять либо трудоемкие вычисления, либообработку больших объемов информации.
После завершения этапа предварительныхисследований составляется список требований, предъявляемых к системе. В негодолжны быть включены результаты анализа обстановки, описание выполняемыхсистемой функций и ограничения, которые необходимо учитывать в процессепроектирования. Под обстановкой в данном случае понимается совокупностьусловий, при которых предполагается эксплуатировать систему. К ним относятсяаппаратные и программные ресурсы, предоставляемые системе, внешние условия еефункционирования а также состав людей и работ, имеющих к ней отношение. Должныбыть продуманы изменения в текущей деятельности организации, обусловленныевнедрением системы. Возможно, понадобится иная расстановка персонала, придетсявнести изменения в структуру выполняемых работ. Могут также потребоватьсядополнительные вычислительные мощности.
Функциональные требования к системе содержатчеткое описание всего того, что она должна делать. Ограничениями в процессепроектирования являются директивные сроки завершения отдельных этапов,имеющиеся в наличии ресурсы, организационные процедуры и мероприятия,обеспечивающие сохранность информации.
Организация-заказчик и группа разработчиковсовместно составляют официальный перечень спецификаций, а также договор опорядке проведения проектных работ и приемке системы. Иногда процесс созданиясистемы разбивается на два отдельных этапа, в которых участвуют различныегруппы специалистов. Первая из них занимается, собственно, проектированиемсистемы, а вторая – ее программной реализацией. В таких случаях договорызаключаются с обеими группами, причем между указанными этапами должен бытьпредусмотрен определенный промежуток, выделяемый для анализа и обсуждений характеристик системы.
2.2 Этапы решения задачи на ЭВМ
1. Постановка задачи.
Задача, которую предстоит решить программистуна ЭВМ, формулируется им самим или выдается ему в виде специального задания наразработку программы. Задание содержит формулировку задачи, необходимыехарактеристики разрабатываемой программы, требования к взаимодействию с ней.Выдаче такого задания для крупных задач может предшествовать большая работанаучно-исследовательского характера.
Задание на разработку программы по форме ихарактеру должно быть аналогично техническому заданию на разработку какого-либотехнического продукта.
Техническое задание полезно и в том случае,когда заказчик и исполнитель работают в одной и той же комнате или дажеявляются одним и тем же лицом. Наличие четкой письменной формулировки будетпрепятствовать подмене или отходу в процессе разработки программы отсформулированных в ТЗ требований в угоду каким-то другим побочным целям. Крометого, письменно сформулированное задание делает возможным обсуждение, оценкуили согласованную с заказчиками корректировку отдельных требований ТЗ в ходеразработки программы, ТЗ препятствует проникновению в программу таких ошибок ипротиворечий, которые могут быть обнаружены только после разработки большейчасти программы или уже на стадии анализа полученных результатов счета. Чемболее формализованным по характеру будет техническое задание, тем большешансов, что разрабатываемая программа будет решать именно ту задачу, которуюимел ввиду заказчик.
Техническое задание должно содержать такжетребования или указания, касающиеся принципов проверки и испытаний готовойпрограммы.
2. Составление проекта.
На основании анализа технического заданияпрограммист выбирает основной метод решения задачи, составляет общий проектпрограммы. Выбранный подход к решению задачи должен обеспечивать правильныерезультаты для тех условий функционирования программы, которые определены ТЗ,гарантировать требуемую скорость работы, предусматривать удобство использованияпрограммы и т.п.
В проекте, помимо формулировки выбранногообщего метода решения задачи, характеризуются основные части проектируемой программы,их функции, взаимосвязь и последовательность выполнения, а также точноопределяются входные данные и выдаваемые результаты как всей программы, так иосновных ее частей. Поскольку каждая разрабатываемая программа, как правило,используется в дальнейшем не только ее автором, но и другими программистами.Составляется и проект инструкции для пользователей, в которой фиксируется предполагаемыйрежим общения пользователя с программой.
Для очень простых задач проектирование можетпроизводиться программистом мысленно, без фиксации на бумаге. Наоборот, оченьсложные задачи могут потребовать нескольких этапов проектирования:предэскизное, эскизное, техническое – по аналогии с инженерным проектированием.
3. Алгоритмизация.
На этот этап иногда смотрят как на вспомогательный,подготовительный к выполнению следующего этапа считающегося основным, накотором производится написание программы на выбранном языке программирования.Введение такого «промежуточного» этапа преследует цель облегчить выполнениеэтапа 4 и тем самым предотвратить возникновение многих ошибок при егоосуществлении для сложных задач. Формулировка алгоритма закрепляетпоследовательность основных шагов выполнения программы, четко фиксируетфункциональное содержание ее частей, позволяет уделить необходимое вниманиепростоте логической структуры разрабатываемой программы. Этап алгоритмизацииявляется совершенно необходимым также, в случае, если язык, на которомпредстоит программировать, не вполне освоен программистом-разработчиком ипредвидятся. Трудности при его использовании на следующем этапе.
При разработке алгоритма необходимо учитыватьресурсы используемой ЭВМ и возможности применяемой для решения задачиоперационной системы. Алгоритмы для несложных задач, требования которых кресурсам невелики, являются обычно машинно-независимыми.
В ходе разработки общего алгоритма используетсянекоторый специальный язык, который по своему характеру является промежуточным,переходным между неформальным, словесным способом изложения метода решениязадачи на этапе 2 и формальным алгоритмическим языком для программирования наэтапе 4. Промежуточный язык должен сочетать в себе, с одной стороны,наглядность для отображения содержания и смысла выполняемых в алгоритмедействий и, с другой стороны, формализм для указания конкретных операций ипоследовательности их выполнения.
В качестве такого промежуточного языка обычноиспользуют блок-схемы, которые позволяют наиболее наглядно представитьлогическую структуру разрабатываемой программы, взаимосвязь отдельных частейпрограммы, условия или кратность выполнения таких частей. Для отображениявычислительной стороны программы используются обычные математические средстваили элементы алгоритмических языков, а в самых общих блок-схемах – простословесная формулировка; иногда используются и все эти способы вместе.
Для достаточно сложных программ алгоритмизацияпроводится в несколько шагов с целью постепенной детализации алгоритма.Критерием окончания детализации при этом является то, что для каждого операторав полученном на очередном шаге алгоритме программист уже имеет четкое иконкретное мысленное представление о том, как этот оператор алгоритма можетбыть выражен средствами выбранного языка программирования на этапе 4. Дляпростых задач обычно разрабатывают блок-схемы на двух уровнях: общая блок-схемапрограммы и блок-схемы отдельных частей программы.
После последнего шага детализации алгоритма проводитсяпроверка полученного алгоритма для выявления допущенных ошибок. Методы контроляалгоритма аналогичны некоторым методам контроля программы.
В ходе разработки алгоритма, возможно, придетсяуточнять или изменять решения, принятые на этапе 2, и в этом случае такиеизменения обязательно вносятся в проект, который всегда должен соответствоватьразрабатываемому алгоритму.
4. Программирование.
В случае, когда на предыдущем этапе был получендетально разработанный алгоритм, составление программы на выбранном дляпрограммирования языке сводится к переводу этого алгоритма на языкпрограммирования. Основные трудности и, следовательно, причины ошибок на этомэтапе заключаются, во-первых, в необходимости знания всех требований иограничений выбранного языка программирования и, во-вторых, в необходимостипостоянного внимания ко многим деталям языка, которые приходится учитывать входе написания программы. Если этап 3 был выполнен некачественно и алгоритмпредставлен недостаточно детально, то его доводку придется выполнять «на ходу»,во время программирования. Это затруднит процесс программирования-перевода иповедет к возникновению дополнительных ошибок в программе. Чем более процесспрограммирования будет походить на перевод, чем более механическим будет такойперевод, тем более легким будет составление программы и тем меньше возникнетошибок на этом этапе, самом щедром на ошибки.
После составления программы проводится еепроверка для обнаружения и исправления ошибок, внесенных на этом этапе. Еслипри проверке обнаруживаются ошибки, допущенные на предыдущем этапе, тосоответствующие исправления вносятся и в алгоритм, поскольку к нему ещепридется обращаться на следующих этапах, и тексты алгоритма и программы должнысоответствовать друг другу.
1.        Компиляция.
Компилятор в ходе осуществления данного этапа,наряду с попыткой перевода исходного текста программы в машинный код,производит поиск синтаксических ошибок в программе и, в случае их обнаружения,печатает диагностику, помогающую последующей локализации ошибок. Отсутствиесинтаксических ошибок не говорит о том, что в программе нет ошибок. Ниже обэтом еще пойдет речь. В тех случаях, когда в распоряжении программиста имеетсянесколько компиляторов, сначала выбирается тот, который представляет большевозможностей для проведения начинающейся отладки. После окончания отладкипроизводится компиляция с целью изготовления экземпляра программы, используемойв дальнейшем для отладки.
6. Отладка.
На этапе отладки производится обнаружение спомощью ЭВМ ошибок в программе и их исправление. Этап отладки можно разделитьна три подэтапа:
6.1. Контроль правильности программы.
6.2. Локализация ошибок.
6.3. Исправление ошибок.
На подэтапе 6.1 – контроль программы – путемпропуска на машине специальных контрольных примеров устанавливается фактотсутствия или, в противном случае, наличия ошибок в программе. Здесь речь идето содержательных ошибках, которые не проявляются при компиляции программы.
На этапе 6.2 – локализация ошибок – точноустанавливается место, где в программе допущена ошибка, последствия которойпроявились при выполнении этапа 6.1.
На этапе 6.3 производится исправление ошибок,выявленных на этапе 6.2. Исправления вносятся как в программу, так и валгоритм, если он затрагивается этими исправлениями.
Перечисленные подэтапы могут повторятсямногократно, до тех пор пока контроль не покажет, что ошибок в программе,по-видимому, нет.
3 а м е ч а н и е. Поиск ошибок в программепроисходит и на более ранних этапах ее разработки, но там он имеетподготовительный характер и отличается тем, что основным материалом при этомявляется текст программы, а не результаты ее работы.
7. Тестирование.
По окончании отладки программы начинается ееэксплуатация: производится анализ ее работы, обычно многократный. Первыеполученные результаты реальных данных подвергаются тщательному анализу, чтобыубедиться в пригодности использованного метода и установить согласованностьполученных результатов с имеющимися данными и теорией. Если правильностьполучаемых результатов не. вызывает сомнений и эффективность программыудовлетворительна, то ее эксплуатация продолжается по мере необходимости. Нослучается и так, что приходится снова рассматривать вопросы правильностиразработанного алгоритма или пригодности реализованного метода, и тогда всяработа может вернуться к началу. Подробнее этап тестирования будет освещенниже.
8. Оформление программы.
Для возможности эксплуатации программы кем-либокроме автора она должна быть оформлена: составлено ее описание, изготовленыносители для передачи программы пользователям. В описание включается инструкцияпо использованию программы, излагается примененный метод решения, приводятсяалгоритмы, а также контрольные примеры с эталонными результатами. Наличиеописания программы позволяет не только успешно эксплуатировать ее длительноевремя, но и проводить ее модернизацию и использовать в дальнейших разработках.Основную часть описания составляют материалы, с которыми шла работа напредыдущих этапах разработки. Поэтому для ускорения этапа оформления всеперечисленные материалы всегда должны быть в рабочем состоянии и по содержаниювполне соответствовать друг другу и отлаживаемой программе, кроме того, уже наэтапах разработки их нужно представлять в таком виде, чтобы они могли бытьиспользованы для описания программы без дополнительных переделок.
В случае, когда программа проста ипредназначена для эксплуатации только ее автором, оформление программы можетпроизводиться уже после проведения счета по ней, одновременно с изготовлениемотчета.
9. Отчет о работе.
На основании результатов, полученных в ходеэксплуатации программы, составляется отчет о проделанной работе, оцениваетсявыбранный метод решения задачи и эффективность программы; публикуются научныевыводы.
10. Модернизация.
Если разработчик программы постоянно работает внекоторой области науки или техники, то обычно рано или поздно наступает такоймомент, когда перед ним возникает вопрос о модернизации старой программы или осоставлении новой, развивающей идеи, реализованные в прежней программе.Модернизация программы проходит те же этапы, что и разработка, и начинается ссоставления технического задания на модернизацию. Успешное осуществлениемодернизации зависит от того, насколько легко можно будет при разработке новойпрограммы использовать блоки старой программы и вносить в них изменения.Быстрое выполнение такого рода работ зависит, в свою очередь, как от структурымодернизируемой программы, так и от качества ее оформления.
Все перечисленные этапы явно присутствуют ихорошо просматриваются при разработке достаточно сложных программ. Для простыхзадач некоторые этапы могут совмещаться друг с другом или проходить незаметнобез какой-либо четкой фиксации.
Например, дляэлементарных задач первые два или даже три этапа часто отсутствуют илисоединяются в один подготовительный этап. Этим, в частности, можно объяснитьто, что начинающиепрограммисты, обучавшиеся программированию на элементарных задачах, припереходе к составлению сложных программ оказываются не готовыми к разработкетехнического задания, проекта, общих алгоритмов. Кроме того, первые этапы могутбыть значительно сокращены, если программист получает задание на программирование,содержащее уже общий алгоритм разрабатываемой программы. С другой стороны, длясложных задач может быть несколько подэтапов алгоритмизации, отладки иувеличивается этап тестирования.
2.3 Проектирование системы
К основным стадиям развития программной системыотносятся следующие:
·          постановка задачи;
·          разработка;
·          реализация;
·          испытания;
·          эксплуатация системы.
Эти этапы могут частично перекрываться. Так, формулированиезадачи не обязательно должно заканчиваться в тот момент, когда начинаетсяразработка программ и подготовка данных. Почти всегда продолжают возникать теили иные детали, требующие согласования с будущими пользователями. Переделкауже законченной системы, связанная с изменением внешних условий, обычнорассматривается как элемент сопровождения системы в ходе ее эксплуатации, хотяпри этом приходится анализировать новые требования и вносить соответствующиеизменения, осуществлять их реализацию и проводить испытания. Все это можетпроисходить еще до того, как система будет принята к промышленной эксплуатации.Система должна проходить испытания как на этапах разработки и реализации, так ив уже готовом виде. Вначале испытания сводятся к консультациям с будущимипользователями: подобные консультации позволяют четко сформулировать требованияк системе. На этапе разработки путем тщательного анализа результатов решениятестовых задач производится детальная проверка проектной документации./> 2.3.1 Определениеосновных элементов системы
На первом этапе проектирования должны бытьопределены информационные потоки и взаимодействующие с ними процессы.Информационным потоком будем называть информацию, перемещающуюся от одного узлаобработки к другому. Такими узлами обработки могут быть машинные программы илирабочие места служащих, отвечающих за выполнение определенных операций. Большиемассивы информации могут размещаться в архивах.
2.3.2Структурный анализ
Метод исследования, которое начинается с общегообзора системы и затем детализируется, приобретая иерархическую структуру совсе большим числом уровней, принято называть структурным анализом. Требования ксистеме и ее предполагаемые характеристики не могут служить отправной точкой,поскольку помимо общего описания они содержат много ненужных деталей. Их можнорассматривать скорее как цели и стандарты, к которым следует стремиться на всехстадиях проектирования. Расчленение системы на функциональные элементыподчиняется вполне определенным правилам. Самое общее правило состоит в следующем:необходимо отделять то, что требуется сделать от того, каким образом это можносделать. Так или иначе, процесс анализа проблемы исходит из функциональногоописания системы в целом, затем составляются функциональные описания ееотдельных частей, после чего исследуются информационные потоки и, наконец,определяется структура данных./>
2.3.3Структурное проектирование
Логические связи, существующие между различнымиэлементами данных, составляют основу всего процесса проектирования. Процесспроектирования должен быть структурирован. Проектирование становится болеецеленаправленным, если в его основе лежат зависимости между данными, присущиерешаемой проблеме, а не условия, диктуемые вычислительной средой.Функциональные связи между программами могут быть определены еще до того, какначнется разработка соответствующих алгоритмов. На этапе проектирования вопросыреализации решаются на абстрактном уровне с использованием диаграмм, таблиц,структурных схем и псевдокодов. Эта информация обеспечивает возможностьпервоначальной проверки системы. Если проект системы или программы разработанна достаточно детальном уровне, допускающем моделирование основных процессовобработки данных, количество ошибок, возникающих на стадии реализации, резкоснижается. Ошибки на этой стадии обходятся весьма дорого, поскольку к этомувремени в проект вложено слишком много усилий. Гораздо проще вносить коррективыв проект на этапе разработки, чем вновь возвращаться к нему уже после егозавершения./>
2.3.4 Реализация ииспытания
Разработка программы и ее написание – этопроцессы, протекающие при ограничениях, принципиально отличающихся друг отдруга. Если в ходе разработки преследуется цель выполнить требования,предъявляемые пользователем, то при написании программ в качестве ограниченийвыступают требования, диктуемые особенностями аппаратного и программногообеспечения, а также практикой, сложившейся на данном предприятии. Соотношениемежду разработкой и реализацией программы примерно такое же, как междупроведением исследования и составлением технического отчета. В идеалеисследование должно быть полностью закончено и набросана схема отчета, преждечем можно будет приступить к его написанию. На практике, разумеется, все этодалеко не всегда осуществимо. Как правило, приходится неоднократно вноситьизменения и возвращаться к началу процесса.
На этапе реализации кодирование модулей невызывает особых затруднений, если проект продуман достаточно тщательно. По меренаписания программ модули испытываются сначала по отдельности, а затем вовзаимодействии. Реализация должна проводиться по модульному принципу. Подобнопроектированию, процесс реализации необходимо структурировать. Для этогоразработанную систему следует разделить на отдельные части, объединенные либогоризонтальными, либо вертикальными связями. Наиболее важные с точки зрения ихфункций модули следует программировать в первую очередь. В результате будетобразована многоуровневая иерархия модулей и составлен сетевой график реализации,включающий промежуточные этапы проверки взаимодействия модулей.
В конечном итоге вся система в целом будетиспытана и готова к внедрению в промышленнуюэксплуатацию.2.4 Вспомогательныесредства проектирования2.4.1 Графическая схемазадания
Графическая схема задания представляет собойсхему, построенную по иерархическому принципу и охватывающую все вопросы,связанные с разработкой проекта. Графическая схема детализируется в текстеразвернутого плана задания, а каждый из входящих в нее блоков подробнопрорабатывается на более поздних стадиях проектирования. Графические схемызадания и развернутые планы проекта должны включаться в состав системнойдокументации.
/>
Рис. 2.2. Графическая схемазадания.
2.4.2Развернутый план проекта системы
I.         Введение. Дается общаяхарактеристика системы, в достаточной степени подробная, чтобы в будущийпользователь мог принять решение о том, отвечает ли система его требованиям.
A.       Функции системы. Поясняетсяназначение прикладной системы, приводится перечень основных процедур иобрабатываемых данных.
B.       Сфера применения. Характеризуетсякруг пользователей, на которых ориентирована разрабатываемая система.
C.       Сбор и корректировка данных.Описываются источники исходных данных, поступающих в систему, а также источникиданных, используемых для корректировки. В этот пункт следует включить планы играфики корректировки данных. В дальнейшем информация используется как руководствопри детальной проработке программ корректировки данных.
D.       Отчеты. Описываются формы,определяются периодичность и общее содержание отчетов, выдаваемых системой. Этаинформация служит основой для последующей детальной проработки программгенерации отчетов.
II.        Вычислительная среда.Определяется минимальный состав оборудования, необходимого для нормальногофункционирования системы.
A.       Технические средства.Описывается конфигурация технических средств, указывается требуемый объемоперативной памяти, определяется ограничения на сегментацию памяти, требованияк внешним устройствам и т.д.
B.       Программные средства.Указываются типы операционных систем, используемые библиотеки стандартныхпрограмм, системы управления базами данных.
C.       Режимы работы. Определяютсявозможность функционирования системы в условиях пакетного режима,интерактивного режима, режима реального времени или их комбинаций.
III.      Связь с внешней средой. Описываетсявзаимодействие пользователей с системой.
A.       Вход системы. Определяютсяформаты данных всех типов, вводимых пользователями, а также внутренняяструктура данных. Эта информация служит руководством при разработке бланковвходных форм и подготовке данных.
B.       Выход системы. Определяютсяформаты отчетов, сообщений и других выходных форм. Эта информация используетсяпри составлении отчетов и подготовке данных.
C.       Управляющие параметры.Перечисляются параметры, задаваемые при настройке системы на конкретнуюконфигурацию технических и программных средств.
D.       Рабочие инструкции. Даетсяобщий обзор содержания инструкций. Данная информация используется присоставлении инструкций для обслуживающего персонала.
IV.      Качество системы.
A.       Соблюдение стандартов и общепризнанныхобозначений. Указывается, в какой мере система соответствует стандартномуварианту языка программирования и отвечает стандартам версии, эксплуатируемой вданном вычислительном центре. Кроме того, определяется степень использованияобщеупотребительных сокращений и математических обозначений. Это позволяетоценить трудоемкость сопровождения системы.
B.       Универсальность системы.Обсуждается степень независимости системы от конкретных внешних условий, сучетом которых она разрабатывалась. Это характеризует сложность переводасистемы на другие вычислительные установки.
C.       Надежность функционирования.Рассматриваются такие вопросы, как ожидаемое время наработки на отказ, способыкорректировки ошибок, проверка достоверности информации, точность результатов,статистические характеристики всех модулей, осуществляющих вероятностныерасчеты, например генераторов псевдослучайных чисел.
D.       Защита информации. Описываютсясредства, обеспечивающие сохранность данных и авторизацию доступа, используемыеспособы кодирования.
V.       Документация по системе.
A.       Пособия и руководства.Приводится перечень документации, прилагаемой к системе, – пособий, формотчетности, рабочих описаний, системной и программной документации.
B.       Спецификации программ. Даетсяобщее функциональное описание отдельных программ, входящих в состав системы.Эта информация служит руководством при разработке программ.
C.       Организация данных. Приводитсяобщее описание взаимодействия отдельных информационных потоков в системе. Этисведения используются при разработке принципов организации данных.
Документы, содержащие общее описание проекта,служат с одой стороны, своеобразным эталоном, на основании которогоосуществляется проверка законченной системы, с другой – используются какруководства на этапах разработки, реализации ииспытаний.2.5 Организация процессапроектирования
Графическая схема задания и развернутый планпроекта определяют те качества, которыми должна обладать система. Они такжеуказывают в общей форме основные направления проектирования. Однако этидокументы не могут служить планом проектных работ. В процессе разработки иреализации системы решается широкий круг задач, в том числе и такие задачи,как:
·          составление рабочихспецификаций
·          составление перечня характеристик
·          внешнее описание данных
·          внешнее описание программ
·          разработка архивов данных
·          разработка программных модулей
·          разработка тестовых задач
·          кодирование программныхмодулей
·          проверка программных модулей
·          объединение программныхмодулей
·          испытание системы в целом
·          комплектация программнойсопровождающей документации
Поскольку многие из перечисленных задач связаныдруг с другом, возникает необходимость в планировании последовательности ихрешения. На этапах разработки и реализации могут применяться разнообразныеметоды организации проектных работ. Они включают создание ведущих групп,сквозной коллективный анализ проекта, свободное обсуждение программ.
В ведущие группы входят специалисты попрограммированию и лица из вспомогательного персонала, работающие совместно надпроектом с самого начала до окончательного его завершения. Один из них – главныйпрограммист – несет ответственность за разработку программы и координациюдеятельности членов группы. Ему также предоставляется право выступать от именивсей группы. Имея коллектив людей, тесно связанных между собой в течениеопределенного времени, можно более целенаправленно руководить ходом работ иожидать более качественных результатов.
Сквозной анализ проекта предпринимается с цельювыявления таких ошибок, как отсутствие спецификаций или неправильное пониманиесуществующих, и проводится он на той стадии, когда исправление ошибок еще невызывает особых затруднений. Специалисты, работавшие над индивидуальнымизаданиями, осуществляют совместный сквозной просмотр проекта, используя приэтом специально подобранные тестовые наборы данных. С помощью подобныхпросмотров спецификаций отдельных блоков системы или описания их взаимодействияпроверяются до того, как фактически начнется кодирование соответствующихпрограммных модулей.
Свободные обсуждения – это анализ текстовисходных программ, проводимый всей группой. Поскольку проект представляет собойне механическую сумму результатов, а продукт их коллективной деятельности, тотакие обсуждения позволяют выявлять логические ошибки, описки и несоответствияв спецификациях.

2.6 Необходимость тестирования программных продуктов
В последнее время в связи с созданием большихпрограммных систем возрос интерес к методике разработки и, в частности, отладкипрограмм.
Методика разработки и отладки программныхсистем должна дополняться и методикой изготовления и отладки отдельныхпрограммных блоков, подпрограмм, модулей, разрабатываемых одним программистом.Без применения эффективных способов создания таких программных единиц нельзянадеяться успешно решить и проблему создания программных комплексов.
Проблема отладки существует также и для программ среднейсложности. Для таких программ эффективность и достоверность отладки не являетсястоль жизненно необходимой, и обнаружение серьезных ошибок в ходе эксплуатациипрограммы не приводит к столь печальным последствиям, как для больших систем,так как автор программы обычно бывает в состоянии исправить их в приемлемыесроки.
Таким образом, вопросы повышения надежности программ,ускорения их отладки и разработки являются по-прежнему актуальными как дляпрофессиональных программистов, работающих над отдельными блоками программныхсистем, так и для научных работников и инженеров, самостоятельноразрабатывающих свои программы.
2.7 Отладка и общие принципы тестирования программ
Начинающий программист, как правило, переоценивает своивозможности и, проводя разработку программы, исходит из того, что в егопрограмме ошибок не будет. Исходя из такого представления о своих способностях,этот программист и строит свою работу над программой, и каждый неверныйрезультат, каждая найденная ошибка вызывают у него изумление и считаются,конечно, последними. Вследствие такого подхода получение надежных результатовоткладываются на неопределенный срок. Только приобретя достаточный опыт,программист понимает справедливость древнего высказывания: «Человекусвойственно ошибаться». Оказывается, что практически невозможно составитьреальную программу без ошибок, и почти невозможно для достаточно сложнойпрограммы быстро найти и устранить все имеющиеся в ней ошибки. Трудностипрограммирования и отладки программы подчеркивает следующий афоризм: «В любойпрограмме есть по крайней мере одна ошибка». Таким образом, можно сказать, чтоналичие ошибок в только что разработанной программе это вполне нормальноеявление.
Одним из самых сложных и трудоемких этаповтехнологического процесса разработки программ является их тестирование иотладка. Как известно, при создании типичного программного проекта около 50%общего времени и более 50% общей стоимости расходуется на проверку разрабатываемойсистемы и ее отладку.
Под тестированием следует понимать процессисполнения программы с целью обнаружения ошибок, в качестве которых принимаетсялюбое отклонение от эталонов. Хорошим считается тест, который имеет высокуювероятность обнаружения еще не выявленных ошибок.
Под отладкой понимается процесс, позволяющийполучить программу, функционирующую с требуемыми характеристиками в заданнойобласти входных данных. Таким образом, в результате отладки программа должнасоответствовать некоторой фиксированной совокупности правил и показателейкачества, принимаемой за эталонную для данной программы.
Эффективность тестирования является важнейшимфактором, определяющим стоимость и длительность разработки сложных комплексовпрограмм с заданным качеством. Вследствие этого создаются различные методытестирования, обеспечивающие наилучшее использование ресурсов проектирования.
Существует два основных подхода к тестированию:

/>
Рис. 2.3. Технология отладки программ
1. Тестирование программы как «черногоящика». Программа рассматриваетсякак черный ящик. Тестовые данные используются только в соответствии соспецификацией программы, т.е. без учета знаний о ее внутренней структуре. Притаком подходе обнаружение всех ошибок в программе является критериемисчерпывающего входного тестирования. Последнее может быть достигнуто, если вкачестве тестовых наборов использовать все возможные наборы входных данных. Вэтом случае для исчерпывающего тестирования требуются бесконечные наборытестов. Однако существуют определенные методологии тестирования, позволяющие извсех возможных тестовых наборов выделить некоторое подмножество тестов, имеющихнаивысшую вероятность обнаружения большинства ошибок.
2. Тестирование программы как «белогоящика». Стратегия белого ящика, илистратегия тестирования, управляемого логикой программы, позволяет использоватьвнутреннюю структуру программы. В этом случае программист получает тестовыеданные путем анализа логики программы. Основной алгоритм тестирования программыпредставлен на рис. 2.3.
Также существует 3 основных способа тестирования:алгоритмическое, аналитическое и содержательное.Алгоритмическое тестирование
Алгоритмическое тестирование применяетсяпрограммистом для контроля этапов алгоритмизации и программирования.Программисты проектируют тесты и начинают готовить эталонные результаты наэтапе алгоритмизации, а используют их на этапе отладки.Функциональное или аналитическое тестирование
Аналитическое тестирование служит для контролявыбранного метода решения задачи, правильности его работы в выбранных режимах ис установленными диапазонами данных. Тесты проектируют и начинают готовитьсразу после выбора метода, а используют их на последнем этапе отладки или дляанализа результатов пробного счета.Содержательное тестирование
Содержательное тестирование служит для проверкиправильности постановки задачи. Для контроля при этом используются, какправило, качественные оценки и статистические характеристики программы,физический смысл полученных результатов и т.п. В проведении содержательноготестирования, принципы которого формулируются в техническом задании, самоеактивное участие должны принимать заказчики или идущие пользователи программы.
Содержательные и аналитические тесты проверяютправильность работы программы в целом или крупных ее частей, в то время, какалгоритмические тесты в первую очередь должны проверять работу отдельных блоковили операторов программы.2.8Типы тестов
Рассмотрим несколько основных типов тестовпрограммного обеспечения:Вырожденный тест
Этот тест затрагивает работу программы в самойминимальной степени. Обычно тест служит для проверки правильности выполнениясамых внешних функций программы, например, обращения к ней и выхода из нее.Тест граничных значений
Тест проверяет работу программы для граничныхзначений параметров, определяющих вычислительный процесс. Часто для граничныхзначений параметра работа программы носит особый характер, который, тем самым,требует и особого контроля.Аварийный тест
Тест проверяет реакцию программы навозникновение разного рода аварийных ситуаций в программе, в частности,вызванных неправильными исходными данными. Другими словами, проверяетсядиагностика, выдаваемая программой, а также окончание ее работы или, можетбыть, попытка исправления неверных исходных данных.
Помимо автономных тестов, предназначенных дляконтроля отдельных блоков программы, можно выделить стыковочные и комплексныетесты.Стыковочные тесты
Предназначаются для проверки взаимосвязи ужеотлаженных частей программы.Комплексные тесты
Проверяют правильность работы всех илибольшинства частей программы после их объединения.
2.8.1 Модульное тестирование
Переход к большим программам требует специальных способовструктурирования процесса тестирования. Тестирование модулей представляет собойпроцесс тестирования отдельных подпрограмм или процедур программы. Здесьподразумевается, что прежде чем начинать тестирование программы в целом,следует протестировать отдельные небольшие модули, образующие эту программу.
Цель тестирования модулей – сравнение функций,реализуемых модулем, со спецификациями его функций или интерфейса. Тестированиемодулей в основном ориентировано на принцип белого ящика.
Существует два подхода к комбинированиюмодулей: пошаговое и монолитное тестирование. В пошаговом тестировании в своюочередь существуют два способа: тестирование снизу вверх и тестирование сверхувниз. Не Пошаговое тестирование предпочтительнее монолитного.
2.9 Надежность программного обеспечения
Теоретический и практическийуровень современной теории технических устройств надежности достаточно высок, ини одна сложная техническая система не проектируется без одновременного анализаее будущей надежности. В последнее время в область интересов теории и практикиисследования надежности вошел новый вид изделий – сложные комплексыпрограммного обеспечения систем управления и обработки информации. Приэксплуатации таких комплексов возникают сбои и отказы, обусловленныеискажениями программ и данных. Эти искажения возникают не только в связи саномалиями работы аппаратуры, но и могут проявиться при безотказной работе ЭВМ.Высокая ответственность систем управления обусловила необходимость изученияпричин программных отказов и методов борьбы с ними. Надежность является однимиз важнейших показателей качества программ, однако они характеризуются ещерядом функциональных и конструкторских критериев качества, выбор которых взначительной степени зависит от их целевого назначения.
Проблема обеспечения и анализанадежности сложных систем может быть решена на базе системного подхода сдетально проработанной программой работ по исследованию и обеспечениюнадежности каждой подсистемы в течение всего жизненного цикла. В процессереализации такой программы должны быть исследованы надежностные характеристикикомпонент системы и обеспечен контроль выполнения мероприятий по достижениюзаданной надежности. Для уникальных и особо сложных систем анализ показателейнадежности затрудняется невозможностью или сложностью проведения специальныхэкспериментов для определения характеристик надежности компонент системы вцелом. Иногда оценку показателей надежности приходится проводить по исходнымданным, полученным косвенными методами, умозрительными экспериментами илиэкспертными оценками. Тем не менее даже приближенные методы позволяют получатьряд важных оценок, необходимых для выбора наиболее целесообразных решений припроектировании сложных систем.
Надежность – это «свойство объекта выполнять заданные функции,сохраняя во времени значения установленных эксплуатационных показателей взаданных пределах, соответствующих заданным режимам и условиям использования,технического обслуживания, ремонта, хранения и транспортирования». Такимобразом, надежность является внутренним свойством системы, заложенным при ееизготовлении и проявляющимся при эксплуатации. Это свойство проявляется тольково времени, и без более или менее длительного наблюдения нельзя сделатьзаключение о надежности системы. Характеристики надежности зависят от условийэксплуатации, поэтому при определении их значений необходимо учитывать ееособенности.
В основе этих характеристиклежат понятия о двух возможных состояниях объекта или системы: работоспособномили неработоспособном. Работоспособным называется такое состояниеобъекта, при котором он способен выполнять заданные функции с параметрами,установленными требованиями технической документации. В процессефункционирования возможен переход объекта из работоспособного состояния внеработоспособное и обратно. С этими переходами связаны события отказа ивосстановления. Отказ – это событие, заключающееся в нарушенииработоспособности, а восстановление – событие, заключающееся в переходеобъекта из неработоспособного состояния в работоспособное в результатеустранения отказа. Таким образом, отказ связан с нарушениями требованийтехнической документации, соответствующих работоспособному состоянию объекта.
2.9.1 Критерии надежности систем
Критерии представляют собой показатели, позволяющиепредпочтительность тех или иных решений при создании и эксплуатации системы постепени достижения основных целей с учетом затрат, при которых эти целидостигаются. При исследовании надежности основная цель состоит в разработкеэффективных методов и обеспечении длительной работоспособности систем сзаданными функциональными характеристиками. Для этого необходимо установитьколичественные показатели, характеризующие не только факт работоспособностисистемы, но и степень соответствия работоспособности основным требованиям,отраженным в технической документации.
Критерии, используемые в теории надежности,являются вероятностными, статистическими и в том или ином виде учитываютвременные показатели. Вероятностью безотказной работы называетсявероятность того, что при заданных условиях эксплуатации в течение интервалавремени tне возникнет отказа, т.е. система будет работоспособна:
 
P= P.
 
Соответственно вероятностью отказаявляется вероятность того, что в течение заданного времени произойдет хотя быодин отказ:
Q= P= 1 – P.
 
Частота отказов aесть плотность распределения времени работы до первогоотказа:
/> />.
Интегральным критерием является интенсивностьотказов l, которая характеризует плотность распределения наработкидо первого отказа, рассчитанную при условии, что до рассмотренного моментавремени система проработала безотказно:
/>

Перечисленные показатели связаны между собой, иих применение определяется спецификой конкретной системы. При этомпредполагается, что начало эксплуатации или проверки соответствует нулевомумоменту времени. Если исследуется система, которая проработала в течениенекоторого времени tо, тоиспользуются условные показатели надежности. В этом случае вероятностьбезотказной работы учитывает, что отказа не было в течение времени tо:
/>.
Аналогично можно представить другиехарактеристики, описывающие надежность для невосстанавливаемых систем приусловии, что они уже функционировали в течение времени to:
Для оценки надежности восстанавливаемыхсистем, кроме вероятностных характеристик наработки до первого отказа,необходимо знать характеристики функционирования после отказа в процессевосстановления. В результате критерии надежности восстанавливаемых системучитывают возможность многократных отказов и восстановлений. Основныепоказатели надежности в этом случае характеризуют:
·          распределение наработки до i – го отказа:Fi= P;
·          распределение времени до i – го восстановления:Vi= P;
·          вероятность возникновения n отказов до достижениядлительности      наработки t: Pn.
Кроме того, отказы можно характеризоватьсредним числом Hза время t, интенсивностью потокаотказов w= dH/ dt и наработкой на отказ T= t/ H.
Процесс восстановления достаточно полно описываетсяпоказателями, подобными показателям, характеризующим отказы:
·          вероятностью восстановления завремя t;
·          плотностью распределениявремени восстановления;
·          средним временемвосстановления.
Кроме того, используются показатели среднегочисла восстановлений за некоторое время и параметр потока восстановлений.
В перечисленных показателях процессы отказов ивосстановлений могут рассматриваться как независимые. Объединение характеристикотказов и восстановлений производится в критерии коэффициент готовности Kr. Этот показатель характеризует вероятность застать взаданный момент времени восстанавливаемую систему в работоспособном состоянии.Значение коэффициента готовности соответствует доле времени полезной работысистемы на достаточно большом интервале, содержащем отказы и восстановления.2.9.2 Типы программногообеспечения с точки зрения надежности
Программы для вычислительных машин можноразделить на три основных типа:
1.        Программы, разрабатываемые длярешения инженерных и научно-исследовательских задач. Они характеризуютсянеполным использованием ресурсов вычислительных систем и относительно небольшимвременем жизненного цикла. Длительность разработки этих программ обычноневелика. Их эксплуатация носит эпизодический и кратковременный характер,отсутствуют жесткие ограничения на допустимую длительность ожиданиярезультатов, практически всегда имеется возможность достаточно строгопроконтролировать выходные данные и при необходимости поставить контрольныеэксперименты. К этому типу программ практически неприменимы основные понятиятеории надежности.
2.        Cложные комплексы программ для информационно-справочныхсистем и систем автоматизации обработки информации, которые функционируют внереального времени. Период их эксплуатации обычно значительно превышаетдлительность разработки, однако в ходе эксплуатации они могут развиваться иобновляться. Соответственно изменяются характеристики комплексов программ исопровождающая документация. Программы этого типа можно квалифицировать каксистемы, и имеется возможность применять к ним понятия теории надежности.
3.        Комплексы программавтоматического и автоматизированного управления, непосредственно входящие вконтур управления и функционирующие в реальном времени. Такие комплексы программобычно практически полностью используют ресурсы вычислительной машины по памятии производительности, снабжаются подробной документацией и эксплуатируютсядолгие годы и даже десятилетия. Эти комплексы определяют степень автоматизациипроизводства в промышленности и качество управления объектами в народномхозяйстве и военной технике. Комплексы этого типа программ обладают всемихарактерными чертами промышленных изделий, к ним в наибольшей степени применимыосновные подходы и понятия теории надежности.
Стабильность длительной эксплуатации, наличие требованийтехнической документации и возможность дефектов в комплексах программ,вызывающих сбои и отказы при функционировании, позволяют анализироватьпоказатели надежности программ второго и третьего типов. Реальная надежностьпрограммного обеспечения нередко оказывается не ниже, чем надежность аппаратныхсредств, и определяет надежность функционирования системы в целом.2.9.3 Анализ надежностипрограммного обеспечения
Кзадачам анализа надежности программного обеспечения можно отнести следующее:
·          формулирование основныхпонятий, используемых при исследовании параметров и показателей надежностипрограмм;
·          выявление и исследованиеосновных факторов, определяющих характеристики надежности сложных программныхкомплексов;
·          выбор и обоснование критериевнадежности комплексов программ различного типа и назначения;
·          исследование характеристикискажений исходных данных от различных типов источников и их влияния нанадежность функционирования комплексов программ;
·          исследование ошибок впрограммах, динамики их изменения при отладке и модернизации и их влияния нанадежность;
·          разработка и исследованиеметодов структурного синтеза сложных программ, повышающих их надежность;
·          исследование методов и средствконтроля и защиты от искажений вычислительного процесса и данных в памяти путемввода различных видов избыточности и помехозащиты, обеспечивающих автоматизациюи сокращение времени восстановления;
·          разработка методовпрогнозирования характеристик надежности комплексов программ с учетом ихсложности, структурного построения и технологии проектирования;
·          разработка методов созданиякомплексов программ с заданной надежностью функционирования и средств защиты отсбоев и отказов с учетом важности решаемых системой задач.
Результаты решения этих задач являются основой созданиясовременной высокоэффективной технологии проектирования программногообеспечения с заданными показателями надежности. Для их решения используютсярезультаты экспериментального исследования факторов и характеристик,разработанных и разрабатываемых комплексов программ.
2.9.4Диагностика функционирования комплексов программ
Для определения надежности любых систем необходимопроводить регулярный или эпизодический диагноз их состояния. Теория, принципыпостроения средств и методы организации процесса диагноза систем развиваются в техническойдиагностике. Их применение для анализа технического состояния комплексовпрограмм имеет ряд особенностей. Основные задачи технической диагностикивключают в себя:
·          проверку исправностисистемы, т.е. установления факта отсутствия неисправностей и полногосоответствия технической документации;
·          проверку работоспособностисистемы и возможности выполнения всех функций с характеристиками, заданнымитехнической документацией;
·          проверку правильностифункционирования в данном режиме работы в данный момент времени;
·          поиск и локализацию неисправностей в системе.
Объем и последовательность проверок, а также методы анализарезультатов определяются алгоритмами диагноза. Основная задача диагноза состоитв определении текущего состояния системы, как работоспособного так инеработоспособного, для выполнения функций, определенных техническойдокументацией. Выбор алгоритма зависит от сложности системы и ресурсов,выделенных на диагностику.
Диагноз состояния систем можно разделить на тестовыйи функциональный. При тестовом диагнозе используются специальноподготовленные данные и контрольные результаты, которые позволяют проверитьработоспособность определенных компонент системы. При тестовом диагнозенеобходимы значительные ресурсы для подготовки исходных данных и проверкирезультатов, что ограничивает его применение в рабочих режимах.
Функциональный диагнозорганизуется на базе реальных исходных данных, поступающих в систему при ееиспользовании по прямому назначению. Путем анализа выходных данных,соответствующих рабочему функционированию, выявляются ситуациинеработоспособного состояния. В процессе рабочего функционирования расширяютсяхарактеристики исходных данных, однако затрудняется достоверный контрольправильности выходных результатов и их соответствия входным. Функциональныйдиагноз связан с целевым назначением и спецификой использования конкретнойсистемы, что затрудняет обобщение и упорядочение методов.
При тестовом диагнозеразличаются прямая и обратная задачи.
2.9.5Основные факторы, влияющие на надежность функционирования комплексов программ
Одни и те же типы сбоев и отказов при исполнении комплексовпрограмм могут быть вызваны различными факторами, которые можно разделить на 3группы.
В первую группу входят факторы, непосредственно вызывающиесбой или отказ при исполнении программы, причинами которых могут быть:
·          искажения исходной информации,поступающей от внешних абонентов;
·          самоустраняющиеся отказы илисбои в аппаратуре вычислительной системы;
·          невыявленные ошибки вкомплексе программ.
Ко второй группе факторов относятся архитектура комплексапрограмм и структурное построение его компонент. Структура программ определяетвозможность расширения последствий искажений информации или вычислительногопроцесса, влияет на вероятность превращения искажения в отказ и на времявосстановления после отказа.
Третья группа факторов влияет на длительностьвосстановления и глубину последствий от возникающих отказов. В эту группувходят факторы, определяющие качество контроля вычислительного процесса иобрабатываемых данных, запаздывание в обнаружении искажений, качествоклассификации искажений и длительность проявления их последствий. Ониопределяют прежде всего длительность восстановления, время наработки на отказ испособствуют быстрой локализации искажений.
Искажения исходной информации в большинстве случаевнепосредственно не влияют на надежность исполнения программ. Искаженные данныемогут обрабатываться и являться причиной ошибок в результатах, выдаваемыхвнешним абонентом или накапливаемых в памяти ВС. Однако, некоторые искажениявыходят за область допустимых значений переменных. При этом возрастаетвероятность того, что искаженная величина будет обрабатываться некоторымсочетанием команд, приводящим к отказу либо к сбою функционирования. Причиныискажения данных, поступающих от внешних абонентов, могут быть различны, иподробно останавливаться на их рассмотрении в теме данного дипломного проектанет необходимости.
Для некоторых типов систем значительная часть информацииявляется символьной, описывающей логически связанные тексты, либо содержащейдесятичные цифры. Стандартное кодирование таких чисел производится в пределах 1байта на символ.
Таким образом, исходные данные преимущественно имеют объем,кратный целому числу байт. Во многих вычислительных системах интерфейс свнешними абонентами, как и процесс обработки информации, построен на байтовойструктурной основе. Поэтому для оценки показателей достоверности исходнойинформации для комплексов программ в качестве наиболее целесообразной единицы следуетвыбрать вероятность искажения 1 байт.
На надежность функционирования программного обеспечениявлияет структура и технология разработки комплексов программ. В зависимости отструктурного построения комплекса программ последствия ошибки могут бытьлокализованы в некотором небольшом участке программ и данных либораспространиться на значительно большое расстояние от места расположенияошибки. Строгое иерархическое построение крупных комплексов программ на базеединообразно оформленных законченных программных модулей обеспечивает снижениевероятности ошибки в каждой команде программы и снижает возможностьраспространения последствий ошибок за пределы программного модуля и используемыхв нем массивов данных.2.10Разработка программной документации
Первым из документов, которые должнывыпускаться в процессе проектирования, являются исходные требования к системе,согласованные между будущими пользователями и системным аналитиком. Многиечасти документации не имеют непосредственного отношения к программистам. В неевходят инструкции для персонала, занимающегося подготовкой входных данных,описания процедур контроля для управляющего персонала, описания тестовыхпроцедур, а также рабочие инструкции для операторов.
В ходе проектирования выпускается документациядвух типов – рабочая и отчетная. При разработке сложных проектов частоприходится выделять специального человека – секретаря проекта, которыйзанимается оформлением документов и сбором рабочей документации. Любойпрограммист вспомнит немало случаев, когда он выбрасывал распечатки старыхвариантов программ, а впоследствии оказывалось, что без них не обойтись.Секретарь проекта как раз и занимается тем, сто подшивает все промежуточныераспечатки, старые варианты блок-схем, спецификации, тестовые данные и т.п., ихранит до тех пор, пока не завершатся окончательные испытания системы.Некоторые из рабочих документов должны в дальнейшем войти в состав отчетнойдокументации.
Проектная документация служит основным источникоминформации, на основании которой осуществляется разработка системы, ееэксплуатация и обслуживание.

/>
Рис. 2.4. Системная документация
I.         Требования к системе.Составление требований к системе не входит в задачу программистов. Они являютсяспециалистами по программированию, а не по гражданскому строительству,банковскому делу, численным методам или в любых других прикладных областях. Вто же время составление требований к системе не может быть поручено и одномулишь системному аналитику. Они должны вырабатываться в соответствии софициально оформленным договором между организацией-заказчиком иорганизацией-исполнителем и выражать содержание этого документа.
II.        Проектная документация. Этачасть документации готовится системным аналитиком, который руководствуетсясведениями, полученными от программистов и будущих пользователей.
A.       Проект системы. К этимдокументам относится графические схемы задания и развернутые планы проекта,охватывающие структуру и основные детали программы.
B.       Подготовка данных. Этот разделохватывает все уровни организации данных, которые будут использоваться впрограммах, в том числе и справочники данных, описания файлов, таблицы ссылок ит.д.
C.       Разработка программ. В этотраздел входят описания иерархической структуры программ в системе, потоковинформации между программами и организации взаимодействия программ. Сюда жедолжна быть включена информация о внутреннем содержании программ, напримерописания алгоритмов, их блок-схемы или программы на псевдокоде.
III.      Справочные пособия ируководства. Эти издания подготавливаются специалистами по технической документации,которые используют информацию, полученную от системного аналитика ипрограммистов.
A.       Руководство пользователя. Вруководстве содержатся общее описание и подробные сведения о ее применении,разъясняются сообщения об ошибках.
B.       Руководство по обслуживаниюсистемы. В это руководство включаются отдельные разделы проектной документациии документы по реализации системы, необходимые для глубокого ознакомления сорганизацией данных и функциями программ.
C.       Руководство оператора. Вруководстве содержатся описание вычислительной установки и конфигурацииустройств, а также инструкции по работе с программной системой
IV.      Реализация системы. Даннаячасть документации отражает результаты действия группы программирования.
A.       Символьный код. Это набортекстов самодокументированных программ, составленных в удобной для восприятияформе.
B.       Информация, выдаваемая ЭВМ.Сюда входят таблицы перекрестных ссылок, карты загрузки, таблицы атрибутов,данные о времени выполнения программ и любая другая машинная информация.
C.       Тестовые прогоны программ. Вэту часть документации включаются контрольные варианты входных данных исоответствующие результаты, получаемые в различных условиях. Указаннаяинформация служит в качестве тестовой при проверке функционирования системы.
Промежуточная документация должна хранитьсявплоть до завершения работы над системой.
После того, как проектирование системызакончено, единственное назначение документации – обеспечить максимальнуюэффективность использования системы. Комплект документации строится помодульному принципу, но ее отдельные части в значительной степени перекрываютсядруг с другом.
В данном разделе были рассмотрены вопросы разработки,отладки, тестирования и надежности программных продуктов. Было приведенообоснование необходимости и важности этапа отладки в процессе разработкипрограммного обеспечения, даны краткие описания основных способов отладки итестирования. Рассмотрены критерии надежности систем, основные факторы,влияющие на надежность функционирования комплексов программ, проведен анализнадежности программных продуктов. Кроме того, рассмотрен вопрос разработкипрограммной документации, что является неотъемлемой частью разработкипрограммного продукта.

3. Организационно-экономическаячасть
3.1 Экономическая эффективность программногопродукта
Цель составления любых программ состоит в полученииопределенных результатов в процессе эксплуатации и оценивается эффективностьюпрограммного средства. Уточним применяемое далее понятие эффективности процессаразработки программного средства. Выбор адекватных показателей эффективности программныхсредств зависит от их назначения, области применения, а также от рядахарактеристик программ, проявляющихся при их применении. Поэтому, для выборатехнических решений могут использоваться различные критерии. Целесообразноподразумевать под эффективностью процесса разработки минимум затрат наразработку программ при заданной экономической эффективности применения икачества программных средств. Минимизация затрат на обеспечение жизненного циклаКомплекта Программ в некоторой степени эквивалентны максимизации разностиэффекта и затрат, если предположить, что экономический эффект от примененияпрограмм зафиксирован и стабилен. Затраты в жизненном цикле ПО определяются нетолько этапом разработки, но и этапами эксплуатации и сопровождения, причемзатраты на этих этапах могут значительно превосходить затраты на этапепроектирования и разработки и характеризуются своими особыми закономерностями.Неодновременность групп затрат не учитывается, и предполагается, что абсолютнаявеличина и влияние затрат со временем не изменяется.
Обычно, критерии качества изделий используются всовокупности, с разных сторон отражающей основные характеристикифункционирования объекта. Тем не менее во многих случаях доминируетэкономический эффект, который наиболее прост, и обобщенно принято описыватьсуммарным доходом Э от использования изделия в течении его жизненного циклапродолжительностью Тж. В первом приближении это разность между полной идеальнойэкономической эффективностью программы Эо и суммарными потерями и затратами Сs,снижающими предельный доход за весь жизненный цикл:Э = Эо – Сs
В качестве идеальной эффективности Эо рассматриваетсясовокупный доход, который можно получить от использования программ за весьжизненный цикл, если бы они не требовали затрат на создание, производство иэксплуатацию, а также функционировали бы на реализующих ЭВМ без потерь иискажений.
Предполагается, что при любых затратах на разработку всегдадостигается заданная идеальная эффективность последующего применения ПО впроцессе его эксплуатации и необходимые показатели качества функционирования.Это предположение позволяет в дальнейшем исключить из анализа эффективностьприменения программных средств Эо и сосредоточить внимание на эффективностипроцесса их разработки. Дополнительным основанием такого допущения можетслужить то, что многие виды программ невозможно или очень труднохарактеризовать доходом от их функционирования. Тогда исследованияэффективности процесса создания ПО можно проводить, минимизируя затраты Сs впредположении, что обеспечены заданные функциональные характеристики программ.
Снижение эффективности Э на величину Сs происходит преждевсего вследствие затрат на разработку, производство, сопровождение и эксплуатациюпрограмм, а так же вследствие различных сбоев программ и оборудования.
В соответствии с этапами жизненного цикла ПО основныезатраты Сs, снижающие идеальную эффективность за цикл жизни Тж, можнопредставить следующими составляющими:
·          совокупные затраты на созданиеПП и обеспечение решения заданных функциональных задач, в том числе натехнологическое обеспечение и аппаратуру ЭВМ при разработке ПО в течениевремени Тр – Ср;
·          затраты на эксплуатациюпрограммных и аппаратных средств, реализующих ПП, а также совокупные потериэффективности за время Тэ вследствие ограниченных характеристик ЭВМ инеидеальности программ – Сэ;
·          затраты на сопровождение ПО завремя Тс, включающие затраты на хранение и контроль состояния, проведениемодернизаций и исправление ошибок, тиражирование версий – Сс;
·          накладные расходы Сн.
В результате совокупную реальную эффективностьфункционирования ПО за весь жизненный цикл длительностью Тж можно представить ввиде:
Э= Эо – Ср – Сэ – Сс – Сн. 3.2Составляющие затрат на создание           программного продукта
Разработка программ является областью с малой материало- иэнергоемкостью, и основные затраты связаны с непосредственным илиовеществленным трудом специалистов различных категорий.
Наибольшее значение в составе Ср при разработке сложныхкомплексов программ имеют следующие составляющие затрат:
·          на непосредственноепроектирование, программирование, отладку и испытания программ в соответствии стребованиями пользователя или заказчика – С1 р;
·          на изготовление опытногообразца ПП как продукции производственно-технического назначения – С2 р;
·          на разработку, подготовку иприменение технологии программных средств автоматизации разработки программ – С3 р;
·          на технологические иреализующие ЭВМ, используемые для автоматизации разработки программ – С4 р;
·          на подготовку и повышениеквалификации специалистов-разработчиков – С5 р.
Первые две составляющие С1 р и С2 р являютсянепосредственными затратами на создание программных средств. Составляющие С3 ри С4 р можно рассматривать как затраты, обеспечивающие оснащенностьпроцесса создания ПП. Затраты на подготовку и повышение квалификации наиболеетрудно формализовать и учитывать в конкретной разработке программных средств. Внашем случае эта составляющая не учитывается.3.2.1Затраты на непосредственную разработку ПП
Затраты на непосредственную разработку комплекса программ С1 рявляются важнейшей составляющей в жизненном цикле ПП. Наибольшее влияние на нихоказывает объем ПП. Затраты на разработку С1 р и объем программ Пк связанычерез показатель интегральной средней производительности труда разработчиков Р. Дляучета влияния на С1 р различных факторов удобно пользоватьсякоэффициентами изменения трудоемкости – Сij, учитывающими зависимость i‑ойсоставляющей совокупных затрат от j‑го фактора. Непосредственные затратына разработку можно представить как частное от объема ПП и производительностьтруда, корректируемое произведением коэффициентов изменения трудоемкости:
/>
Выделим четыре основных группы факторов, влияющих назатраты С1 р при непосредственной разработке программ:
*          факторы, отражающиеособенности создаваемого комплекса программ как объекта разработки, итребования к его общим характеристикам;
*          факторы, характеризующиетехнологическую и программную оснащенность средствами автоматизации процессаразработки программ;
*          факторы, отражающиеоснащенность процесса создания ПП аппаратурными средствами, на которыхбазируются системы автоматизации разработки;
*          факторы, определяющиеоснащенность процесса разработки программ и его обеспечение квалифицированнымиспециалистами.
Для каждого фактора может быть выделен параметр, наиболееполно отражающий его содержание численными значениями. Для большинства факторовпроизведены оценки диапазона возможного изменения относительных затрат наразработку одной команды в ПП при варьировании соответствующего параметра вуказанном диапазоне. Эти изменения затрат характеризуются коэффициентами Сijизменения усредненной трудоемкости разработки строки текста программы за весьцикл создания ПП при варьировании j‑го фактора i‑ой группы. Кромеоценок предельных значений КИТ, приводятся их средние значения.Факторы объекта разработки Параметры фактора Диапазон изменения параметра Диапазон КИТ Среднее значение КИТ 1. Сложность ПП – С11 Число операторов в тексте программ на ассемблере Пк 104 – 107 1 – 4 2 – 3 2. Надежность функционирования ПП – С13 Часы проработки на отказ программ Тн 1 – 103 1 – 5 2–2.5 3. Ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ – С14 Процент использования памяти и производительности Р 50–95 1 – 3 1.3–1.5 4. Длительность предполагаемой эксплуатации – С15 Годы эксплуатации Тэ 1 – 20 1 – 3 1.3–1.5 5. Предполагаемый тираж – С16 Число предполагаемых экземпляров 1 – 1000 1 – 3 1.3–1.5 6. Мобильность использования компонент ПП из других разработок – С17 Процент возможного использования компонент 0 – 80 1 – 1.4 1.1–1.2 7. Мобильность использования ПП для других разработок – С18 Процент возможного использования компонент 0 – 80 0.4 – 1 0.5–0.7
Факторы ПП как объекта проектирования, влияющие нанепосредственные затраты при разработке сложных программ.
Эта группа факторов отличается наибольшим влиянием назатраты и производительность труда.3.2.2Сложность разработки программного продукта
Наиболее активно в качестве показателя сложности программыиспользуется ее объем, выраженный числом операторов на ассемблере или строк наязыке программирования высокого уровня. Объем программ является одной изнаиболее достоверно измеряемых характеристик ПП. Логично предположить, что помере увеличения объема ПП возрастает относительная трудоемкость разработкикаждой команды в программе. Такая зависимость может быть описаналогарифмической функцией:
/>
В качестве первого приближения суммарные затраты наразработку сложного ПП в зависимости от объема программ можно представитьвыражением:

/>
Надежность функционирования ПП является наиболее важнымфактором, отражающим качество программных средств.
В качестве параметров, характеризующих надежность системы,наиболее широко используется наработка на отказ Тн и коэффициент готовности Кг.Оба показателя тесно связаны, что позволяет ограничить внимание на первом изних. Изучение математических моделей процесса выявления ошибок в программахпривело к тому, что одной из наиболее достоверных и простых являетсяэкспоненциальная зависимость числа оставшихся ошибок от времени еетестирования. Эти соображения позволяют аппроксимировать средние значения С13 приповышении требований к надежности ПП логарифмической зависимостью:
/>
Ограничение ресурсов производительности и оперативнойпамяти реализующей ЭВМ. При использовании создаваемым ПП производительности ипамяти реальной ЭВМ менее чем на 50% можно не учитывать эти ограничения.
/>
где р – реальная загрузка ЭВМ.
Длительность предполагаемой эксплуатации ПП изменяется отнескольких месяцев до нескольких лет. По экспертным оценкам, увеличениепредстоящей длительности эксплуатации ПП на порядок от 1 до 10 лет приводит кувеличению КИТ С15 примерно в 1.5–2 раза. Такую зависимость можно описатьлогарифмической функцией:
/>
где а15 изменяется в диапазоне от 1 до 0.5.
Предполагаемый тираж программ N составляет
/>
При переходе от уникального ПП к программам, подлежащимтиражированию, затраты заметно возрастают.
Мобильность использования компонентов ПП для другихразработок приводит к необходимости их проектирования как автономныхкомплектующих изделий. В результате может быть достигнута возможностьсборочного программирования.
Мобильность использования ПП из других разработок позволяетснижать затраты при сборочном программировании новых ПП. При этом относительноеповышение производительности труда пропорционально доле использования в новомПП. При сборочном программировании кроме 10–20% затрат на создание новыхпрограммных компонент, необходимы ресурсы на комплексирование нового ПП, егокомплексную отладку, испытания и документирование. В результате суммарныезатраты заметно возрастают и эквивалентное повышение производительности трудаС18 может составлять 2.5–3 раза. Необходимо учитывать затраты, которыетребуются на создание адаптируемых компонент и всего первичного ПП. Врезультате программная мобильность с учетом затрат на ее подготовку в среднемдает снижение КИТ на 30–50%.

3.2.3Затраты на изготовление опытного образца как продукциипроизводственно-технического назначения
Затраты на изготовление опытного образца ПП как продукциипроизводственно-технического назначения – С2 р определяется необходимостьюобеспечить отчуждение всего комплекса программ от его непосредственныхразработчиков. Удельный вес этих затрат находится в пределах 10–15% от общихзатрат на разработку С1 р. Для изготовления ПП как продукциипроизводственно-технического назначения необходимо:
·          изготовить и оформить опытныйобразец ПП на носителях данных;
·          разработать комплектдокументации, обеспечивающий квалифицированную эксплуатацию ПП.
При разработке сложных ПП затраты на изготовление носителейпрограмм опытного образца ПП находятся на уровне процента и далее нами неучитываются.
3.2.4 Затраты на создание комплекта документации
Затраты на создание комплектадокументации С2р2 практически пропорциональны объему программы:
/>,
/>,
где Д = 50–100 страницдокументации на тысячу команд,
а2 – удельная трудоемкостьстраницы написания документации. В реальных ПП определяется по аналогичнымразработкам.

3.2.5Затраты на технологию и программные средства автоматизации разработки ПП
Затраты на технологию и программные средства автоматизацииразработки ПП обычно являются весьма весовыми только при использованииавтоматизированных технологий. Объем и сложность программного продуктазначительно влияют на выбор уровня автоматизации технологии и долю затрат вобщих затратах на разработку. Встречаются ситуации, при которых затраты натехнологию достигают 50% общих затрат на разработку С1 р. В нашем случаеподобных затрат нет, и поэтому ими можно пренебречь.
Затраты на ЭВМ, используемые для автоматизации разработкиданного ПП – С4 р – включают капитальные затраты на закупку и установкусоответствующих ЭВМ, а также текущие затраты на их эксплуатацию в теченииразработки ПП.
В нашем случае затраты распределяются только наэксплуатацию ЭВМ в течение разработки ПП. Поэтому общие затраты на ЭВМ будутвыглядеть так:
С4 р = С4р1 = а41*Тр,
где а41 – стоимость машинного времени реализующей ЭВМ.
3.3Составляющие затрат на эксплуатацию программ, влияющих на процесс разработки ПП
Затраты на эксплуатацию программ, влияющих на процессразработки ПП:
*          затраты на производство ивнедрение экземпляра ПП – С1э
*          затраты на реализующую ЭВМ – С2э
*          затраты на эксплуатациюреализующей ЭВМ – С3э
*          затраты на эксплуатациюэкземпляра – С4э
*          потери вследствие задержек ипотерь сообщений – С5э
*          потери вследствие сбоев иотказов ПП – С6э
Затраты на производство и внедрение каждого экземпляра ПП –С1э, при серийном выпуске ПП обычно намного меньше, чем изготовление опытногообразца, но в нашем случае распределения затрат не будет. Тиражированияносителей программ и документации не будет, поэтому С1э1 будет равно нулю.
Вторая составляющая затрат на эксплуатацию – С1э2обусловлена подготовкой каждого образца ПП к конкретным условиям примененияперед использованием. В нашем случае она равна нулю.
Затраты на внедрение – С1э3 можно снижать за счетэффективных средств обучения персонала. И в некоторых случаях обучениеспециалистов и внедрение экземпляра сложных ПС может требовать 2–7% общихзатрат на разработку ПП. Поэтому в нашем случае С1э = С1э3.
Затраты на реализующую ЭВМ прежде всего зависят отэлементной базы и прогресса технологии в области создания компонентвычислительной техники.
Для ПП, работающих в реальном времени, при маломиспользовании периферийных устройств затраты на реализующую ЭВМ определяются восновном следующими факторами:
·          объем оперативной По икомандной Пк памяти ЭВМ – f2э1;
·          быстродействие вычислительнойсистемы f2э2;
·          уровень технологии иавтоматизации проектирования программ U, влияющий на степень использованияресурсов реализующей ЭВМ f2э3.
Как известно, память является одной из самых дорогихкомпонент вычислительной машины. Для размещения сложных программ объемом 104–107команд стоимость ЭВМ практически пропорциональна суммарному объему памяти илиобъему памяти, необходимому для размещения ПП. Поэтому можно принять f2э1 =а2э*.
Вторым фактором, определяющим стоимость вычислительныхсистем, является их быстродействие или производительность. В некоторых пределахзатраты на реализующие ЭВМ практически линейно зависит от логарифма величиныбыстродействия. Поэтому можно принять f2э2 = 2–3.
В нашем случае f2э3 = 1 из-за низкого уровня автоматизации.
В результате суммарные затраты на реализующую ЭВМ сопределенным ПП можно описать следующим приближенным выражением:
С2э = f2э1 *f2э2,
где Б – быстродействие ЭВМ.
Коэффициент а2э учитывает текущее состояние технологииизготовления аппаратуры ЭВМ. Его можно оценить по техническим характеристикам истоимости реальных вычислительных машин.
Затраты на эксплуатацию реализующей ЭВМ – С3э для комплексапрограмм в реальном времени практически постоянны в единицу времени и можнопринять, что:
С3э = а3э*Тэ
Коэффициент а3э соответствует удельной стоимости машинноговремени. Затраты на эксплуатацию экземпляра ПП на реализующей ЭВМ – С4э так же,как и предыдущие, можно считать прямо пропорциональными времени эксплуатации ПП– Тэ:
С4э = а4э*Тэ
Коэффициент а4э в основном зависит от типа памяти,используемой для хранения программ. Наименьшие затраты при эксплуатациипрограмм требуются при использовании постоянных или полупостоянных запоминающихустройств. В этом случае удельные затраты за время жизненного цикла ПП обычносоставляет малую долю от затрат на реализующую ЭВМ. Обычно а4э
Потери эффективности функционирования ПП вследствиезадержек и потерь сообщений, подлежащих обработке, – С5э обусловленыограниченностью ресурсов реализующей ЭВМ. Ограничение ресурсов отражается какнепосредственно на разработке ПП, так и на его эксплуатации. Влияние этогоограничения в процессе разработки и приводит к необходимости тщательного учетаи экономичного использования ресурсов реализующей ЭВМ, что увеличивает С14.Более тщательное проектирование ПП в условиях ограниченных ресурсов ЭВМпозволяет снизить потери С5э, однако увеличивает затраты за счет КИТ – С14. Приединственном экземпляре эти затраты возможно учитывать за счет С14.
Потери эффективности функционирования ПП вследствие сбоев иотказов из-за ошибок в программе – С6э характеризует устойчивость программ кразличного рода внешним возмущениям. Напрашивается предыдущий вывод об учетеодной статьи затрат. Таким образом, общие затраты и потери эффективности приэксплуатации ПП можно представить выражением:
Сэ = С1э + С2э + С3э + С4э + С5э + С6э.
3.4Составляющие затрат на сопровождение программ
Сопровождение сложных ПП состоит в их развитии и модернизации,необходимости корректировки для обнаружения и устранения ошибок, а также втиражировании и конфигурационном контроле распространяемых версий.
Основными факторами, влияющими на процесс разработки ПП,являются:
·          объем программного продукта
·          длительность жизненного циклаПП
·          уровень технологии разработкиПП
·          степень использования ресурсовреализующей ЭВМ
·          надежность ПП
·          число версий ПП
·          мобильность ПП
·          тиражность ПП
Затраты на сопровождение ПП сводятся к трем составляющим:
*          на обнаружение и устранениеошибок в каждой версии ПП – C1с
*          на доработку исовершенствование программ, формирование и испытание новых модернизированныхверсий ПП – C2с
*          на тиражирование каждой новойверсии ПП и ее внедрение в эксплуатируемых и новых системах – C3с.
Затраты на обнаружение и устранение ошибок C1сопределяются двумя факторами: затратами на обнаружение каждой ошибки изатратами на устранение всех выявленных ошибок про формировании очереднойверсии. Линейная структура ПП и отсутствие в ней алгоритмически сложных местсводят C1с к нулю.
Затраты на развитие и модернизацию программы C2сблизки по содержанию к затратам на первичную разработку ПП Ср. Модернизацияпроизводится поэтапно и для каждой новой версии изменяется только некотораячасть от объема всего ПП. Обычно эта часть составляет не более 20% от всегокомплекса. Сложность связей в ПП приводит к тому, что удельные затраты наизменяемые программы при модернизации каждой версии могут быть несколькобольше, чем затраты на создание программ такого же объема при первичномпроектировании. ПО управления автоматизированным комплексом многоканальнойсвязи реализовано в виде машинного кода, специфика ассемблерного текстакоторого применительно к данной задаче исключает его модернизацию. В целом,цели и технические требования к таким ПП оговорены заранее. Подобные продукты разрабатываютсяв каждом случае под конкретную архитектуру. Поэтому, составляющая затрат наразвитие и модернизацию такого ПО C2с также будет равна нулю.
Затраты на тиражирование каждой версии C3свключают совокупные затраты на изготовление копии программ, их установку на ЭВМи освоение для нормальной эксплуатации. В нашем случае скомпилированныйисходный код ПП не нуждается в тиражировании вследствие идентичностиконструкции и условий работы множества контроллеров, в которые он будетзапрограммирован. Откомпилированный один раз код просто заносится вмикроконтроллеры, поэтому и C3с тоже будет равняться нулю.
Уникальный ПП, основная часть жизненного цикла которогоприходится на разработку, может создаваться почти без учета будущих затрат насопровождение.3.5Расчет затрат на программный продукт Исходные данные:
– объем ПП составляет примерно 300 операторов наассемблере;
– надежность функционирования ПП около 20 часовнаработки на отказ;
– ограничение ресурсов производительности иоперативной памяти реализующей ЭВМ не      менее 50%;
– длительность эксплуатации составит не менее 5 лет;
– данная программа будет существовать в единственномэкземпляре;
– после создания ПП предполагается использовать около40% наработок;
– при создании ПП число наработок из других программсоставило не более 20%;
– в процессе проектирования велась пошаговаяразработка компонент ПП с           контролируемыми этапами технологии ипоэтапным контролем результатов работ;
– при разработке ПП, который относится к ПП нижесреднего класса сложности           применялась        только реализующая ЭВМ,которая также использовалась для имитации   внешней среды и тестов;       
– на разработку и отладку произведенного ПП потребовалось всреднем по 0,3 Мбайта;
– уровень квалификации заказчика выше среднего.
Суммарные затраты:Cs = Cp + Cэ + Сс + Сн
Поскольку мы пренебрегли затратами на сопровождениепрограммного продукта, формула принимает следующий вид:
Сs = Ср + Сэ + Сн.
Рассчитаем каждое слагаемое.
Составляющие затрат на разработку программного продукта:
Ср = С1 р + С2 р + С3 р + С4 р.
Факторы, влияющие на затраты при разработке
С1 р = Пк/Р * П Сij
С11 = lg = 1;
С13 = lg = 2.3;С14 = 0.51;
С15 = а15*lg = 0.5*lg = 0.85;
С16 = 2.3;
С17 = 1.4;
С18 = 0.9;
С31 = 0.65;
С32 = 1;
С33 = 0.5;
С34 = 1;
С41 = 0.7;
С42 = 0.75;
С51 = С52 = 0.8;
С53 = 0.95;
С54 = 1.1;
Остальные коэффициенты примем равными единице.
Р – производительность = 60команд на ассемблере в день
Пк = 300 команд
Зарплата составляет 150 руб./день
Рассчитаем С1 р.
С1 р = 3.131 * 150 = 470 рублей.
Затраты на изготовление опытного образца ПП
С2 р = а2 р * Д * Пк* Зарплата_в_день,
где а2 р = 1 день / 10страниц;
Д – 50 страниц / 1000 команд;
С2 р = 6 * 150 = 900 рублей.
Затратами на технологию и программные средства мыпренебрегаем.
Затраты на ЭВМ
С4 р = а41*Тр
где а41 = 24000 / = 480 руб. / месяц
С4 р = 1 * 400 = 480 рублей.
Итак:
Ср = 470 + 900 + 480 = 1850 рублей.Затраты на эксплуатацию программСэ = С1э + С2э + С3э
С1э мы пренебрегаем вследствие единичного изготовленияпрограммного продукта.
С2э = а2э**lg
где
а2э = 0.005*5500*7 рублей
По + Пк = 0,5Мбайта
Б – быстродействие = 10 000000 операций в секунду.
С2э = 190 рублей.Затраты на эксплуатацию реализующей ЭВМ
С3э = 60 месяцев * 480 рублей / месяц = 28 800 рублей.
Итого Сэ = 28 990 рублей.
Учитывая, что Сн составляют 50% от Ср, то
Сн = 0,5*1850 = 925 рублей.
Сs = 1850+28990+925 = 31 765 рублей.
Все результаты сведем в таблицы.
Затраты на разработку ППСоставляющие Затраты % от общих затрат С1 р 470 25 С2 р 900 49 С4 р 480 26 Затраты на эксплуатациюСоставляющие Затраты % от общих затрат С2э 190 4 С3э 28 800 96 Общие затраты на создание программного продуктаСоставляющие Затраты % от общих затрат Ср 1 850 6 Сэ 29 900 91 Сн 925 3
Мы рассчитали суммарные затраты на разработку данного ПП иувидели, что они составили примерно 32 675 рублей. Наибольшие затраты были наэксплуатацию реализующей ЭВМ.
Методом уменьшения затрат является использование одной ЭВМдля наблюдения за работой достаточно большого количества автоматизированныхкомплексов многоканальной связи.