86236

Программная реализация алгоритмов предотвращения аварийных ситуаций бортовой сети

Курсовая

Коммуникация, связь, радиоэлектроника и цифровые приборы

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

Русский

2015-04-04

370 KB

2 чел.

Реферат

Данный текстовый документ имеет объем _ страницa, количество иллюстраций составляет _, таблиц – _, приложений _. При работе над данным дипломным проектом было использовано _ источника литературы. Имеется графический материал в объеме _ листов.

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

Объектом разработки являются программное средство для управления базовым модулем коммутатора переменного напряжения.

Целью работы является программная реализация алгоритмов предотвращения аварийных ситуаций бортовой сети.

Разработанный программный продукт отлажен, что подтверждается соответствующим актом.

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


Содержание

[1]
Техническое задание

[1.1] Основание для разработки

[1.2] Назначение разработки

[1.3] Рассмотренные альтернативы

[1.4] Стандарты

[1.5] Описания прецедентов

[1.5.1] Перечень прецедентов проекта

[1.5.2] Прецедент «Начальная инициализация»

[1.5.3] Прецедент «ВСК»

[1.5.4] Прецедент «Инициализация параметров»

[1.5.5] Прецедент «Проверка исходного состояния»

[1.5.6] Прецедент «Управление энергораспределением»

[1.5.7] Прецедент «Опрос датчиков тока»

[1.5.8] Прецедент «Опрос N»

[1.5.9] Прецедент «Аварийная ситуация»

[1.5.10] Прецедент «Текущее состояние»

[1.5.11] Прецедент «Получение данных»

[1.5.12] Прецедент «Обработка данных»

[1.5.13] Прецедент «Параметры коммутатора»

[1.5.14] Прецедент «Управление силовыми ключами»

[1.5.15] Прецедент «Сервисная функция»

[1.6] Требования пользователя к программному изделию

[1.6.1] Входные и выходные данные

[1.6.2] Программные ограничения, совместимость

[1.6.3] Результирующие компоненты изделия

[1.6.4] Носители информации

[1.6.5] Требования к надежности

[1.6.6] Рестарт

[1.6.7] Требования к составу и параметрам технических средств

[1.7] Диаграмма вариантов использования

[2]
Технический проект

[2.1] Модель предметной области

[2.1.1] МПО на основе прецедента «Начальная инициализация»

[2.1.2]  МПО на основе прецедента «Управление энергораспределением»

[2.1.3]  МПО на основе прецедента «Получение данных»

[2.2] Реализация прецедентов при помощи диаграмм последовательностей системных операций

[2.2.1]  Диаграмма последовательности системных операций на основе прецедента «Начальная инициализация»

[2.2.2]  Диаграмма последовательности системных операций на основе прецедента «Управление энергораспределением»

[2.2.3]  Диаграмма последовательности системных операций на основе прецедента «Получение данных»

 


Определения

В настоящей дипломной работе использованы следующие определения:

Коммутация – процесс переключения соединений в электрических цепях;

Модуль коммутации – устройство для силовой коммутации каналов бортовой сети;

Напряжение – отношение работы электрического поля при переносе пробного электрического заряда из точки A в точку B к величине пробного заряда;

Переменное напряжение – напряжение, периодически изменяющееся по модулю и знаку;

Интерфейс CAN – интерфейс обмена короткими (не более 8 байт) сообщениями в сети равноправных устройств;

Контроллер – специализированное техническое устройство, предназначенное для управления другими устройствами путем получения информации в виде цифровых данных или аналого-дискретного сигнала от внешнего устройства (ЭВМ, датчики или иное устройство), преобразования этой информации по специальному алгоритму и выдачи управляющих воздействий в виде цифрового или аналого-дискретного сигнала;

Бортовая сеть  – сеть электропитания летательного аппарата (объединяет источники и потребители электроэнергии);

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


Обозначения и сокращения

В настоящей дипломной работе использованы следующие обозначения и сокращения:

МК: микроконтроллер;

ПО: программное обеспечение;

ОЗУ: оперативное запоминающее устройство;

АЦП: аналогово-цифровой преобразователь;

ВСК: встроенный стартовый контроль;

НИР: научно-исследовательская работа;

МПО: модель предметной области;

УУ: управляющее устройство.


Введение

Данный программный продукт разработан в рамках НИР по теме «Коммутация» в Курском ОАО «Прибор» «ОХП «ОКБ Авиавтоматика» для управления базовым модулем коммутатора переменного напряжения, разработанным на базе МК 1986ВЕ91 ЗАО «ПКК Миландр».

МК 1986ВЕ91 входит в новейшую серию отечественных 32-разрядных высокопроизводительных микроконтроллеров семейства 1986 на базе процессорного ядра ARM Cortex-M3. Базовый модуль коммутатора переменного напряжения представляет собой устройство, входящее в состав системы распределения электрической энергии бортовой сети и выполняет следующие функции:

  •  включение/выключение силовых полупроводниковых ключей;
  •  предотвращение аварийных ситуаций (перегрузок) ботовой сети путём контроля значений параметров силы тока и напряжения в допустимом диапазоне.

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

В соответствии с технологией и требованиями ГОСТ Р 51904-2002 большое внимание при проектировании уделялось:

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

При реализации поставленных задач были использованы такие средства разработки, как язык моделирования UML, язык описания операций OCL и язык программирования C и C++.

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

Общественно-социальная значимость данной работы заключается в том, что отдельные части разработанного ПО базового модуля коммутатора переменного напряжения можут быть использованы для будущих разработок на базе МК Миландр 1986ВЕ91.

  1.  
    Техническое задание
    1.  Основание для разработки

Основанием для разработки программного продукта служит задание на дипломную работу «Программное обеспечение для управления базовым модулем коммутатора переменного напряжения» на основе «Технических требований на разработку программного обеспечения для макета модулей коммутации переменного и постоянного напряжения», утверждённое на основании приказа по ЮЗГУ от _.

  1.  Назначение разработки

Данное программное изделие предназначено для управления базовым модулем коммутации пременного напряжения.

  1.  Рассмотренные альтернативы

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

  1.  Стандарты

Разработка программной документации и программного продукта должна производиться согласно ГОСТ 19.701-90, ГОСТ 2.304-88. Текстовый материал пояснительной записки должен соответствовать требованиям  стандарта университета СТУ 04.02.030-2008. Все артефакты проектирования должны быть разработаны в соответствии со стандартом UML.

  1.  Описания прецедентов
    1.  Перечень прецедентов проекта

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

  •  «Начальная инициализация»;
  •  «ВСК»;
  •  «Инициализация параметров»;
  •  «Проверка исходного состояния»;
  •  «Управление энергораспределением»;
  •  «Опрос датчиков тока»;
  •  «Опрос N»;
  •  «Аварийная ситуация»;
  •  «Текущее состояние»;
  •  «Получение данных»;
  •  «Обработка данных»;
  •  «Параметры коммутатора»;
  •  «Управление силовыми ключами»;
  •  «Сервисная функция».
    1.  Прецедент «Начальная инициализация»

Сводка.

Стартовый контроль и инициализация значений параметров по умолчанию.

Зависимости.

Включает в себя прецеденты:

- ВСК;

- Инициализация параметров;

- Проверка исходного состояния.

Воздействующие системы.

Главная воздействующая система – управляющее устройство верхнего уровня.

Описание.

1. Главная воздействующая система производит действие «Включение питания».

2. Переход в включаемый прецедент «ВСК».

3. Переход в включаемый прецедент «Инициализация параметров».

4. Переход в включаемый прецедент «Проверка исходного состояния».

  1.  Прецедент «ВСК»

Сводка.

Набор встроенных тестов основных узлов устройства.

Зависимости.

Включается в прецедент «Начальная инициализация».

Описание.

1. Тестирование АЦП.

2. Тестирование контроллера интерфейса CAN.

3. Тестирование ОЗУ.

  1.  Прецедент «Инициализация параметров»

Сводка.

Настройка значений параметров узлов устройства.

Зависимости.

Включается в прецедент «Начальная инициализация».

Описание.

1. Инициализация параметров микроконтроллера.

2. Инициализация датчиков тока и используемых ими портов ввода/вывода.

3. Инициализация каналов АЦП и используемых ими портов ввода/вывода.

4. Инициализация полупроводниковых силовых ключей и используемых ими портов ввода/вывода.

5. Инициализация контроллера интерфейса CAN.

  1.  Прецедент «Проверка исходного состояния»

Сводка.

Проверка исходного состояния полупроводниковых силовых ключей.

Зависимости.

Включается в прецедент «Начальная инициализация».

Описание.

1. Проверка наличия тока в каналах.

2. Проверка наличия напряжения в каналах.

3. Проверка отсутствия частоты.

4. Формирование признака «Норма».

5. Выдача сформированного признака.

Альтернативы.

1а. Фиксация наличия тока в канале.

4а. Формирование признака «Ошибка».

2б. Фиксация наличия напряжения в канале.

4б. Формирование признака «Дефект».

3в. Зафиксировано отсутствие частоты в канале.

4в. Формирование признака «Дефект».

  1.  Прецедент «Управление энергораспределением»

Сводка.

Слежение за состоянием коммутируемых каналов, автоматическое отключение силовых ключей, обработка аварийных ситуаций.

Зависимости.

Включает в себя прецеденты:

- Опрос датчика тока;

- Текущее состояние.

Расширяется прецедентом «Аварийная ситуация».

Воздействующие системы.

Главная воздействующая система – управляющее устройство верхнего уровня.

Описание.

1. Переход в включаемый «Опрос датчиков тока»;

2. Формирование признака «Норма»;

3. Переход в включаемый прецедент «Текущее состояние»;

4. Переход к 1ому шагу.

Альтернативы.

1а. Формирование признака «Авария»;

2а. Переход в расширяющий прецедент «Аварийная ситуация».

  1.  Прецедент «Опрос датчиков тока»

Сводка.

Проверка состояний датчиков тока всех каналов.

Зависимости.

Включается в прецедент «Управление энергораспределением».

Включает в себя прецедент «Опрос N».

Описание.

1. Проверка датчика 1ого канала путём перехода в включаемый прецедент «Опрос N».

2. Проверка датчика 2ого канала путём перехода в включаемый прецедент «Опрос N».

3. Проверка датчика 3ого канала путём перехода в включаемый прецедент «Опрос N».

4. Формирование признака «Норма».

5. Возврат сформированного признака.

Альтернативы.

1а. Формирование признака «Авария 1».

2а. Формирование признака «Авария 2».

3а. Формирование признака «Авария 3».

  1.  Прецедент «Опрос N»

Сводка.

Проверка состояния N-ого канала.

Зависимости.

Включается в прецедент «Опрос датчиков тока».

Описание.

1. Проверка значения силы тока в канале на нахождение в допустимом диапазоне.

3. Проверка значения напряжения в канале на нахождение в допустимом диапазоне.

4. Формирование признака «Норма».

5. Возврат сформированного признака.

Альтернативы.

4а. Формирование признака «Авария N».

  1.  Прецедент «Аварийная ситуация»

Сводка.

Обработка аварийной ситуации.

Зависимости.

Расширяет прецедент «Управление энергораспределением».

Описание.

1. Выключение силовых ключей каналов, в который возник признак «Авария».

Альтернативы.

1а. Если коммутатор в трёхфазном режиме, то выключение всех силовых ключей.

  1.  Прецедент «Текущее состояние»

Сводка.

Отправка информации о текущем состоянии по интерфейсу CAN.

Зависимости.

Включается в прецедент «Управление энергораспределением».

Описание.

1. Формирование сообщения в соответствии со специальным протоколом интерфейса CAN.

2. Отправка сформированного сообщения по интерфейсу CAN.

  1.  Прецедент «Получение данных»

Сводка.

Получение и обработка данных, полученных по CAN.

Зависимости.

Включает в себя прецедент «Обработка данных».

Описание.

1. Получение данных из аппаратного в программный буфер CAN.

2. Переход в включаемый прецедент «Обработка данных».

  1.  Прецедент «Обработка данных»

Сводка.

Обработка полученных данных.

Зависимости.

Включается в прецедент «Получение данных».

Расширяется прецедентами:

- «Параметры коммутатора»;

- «Управление силовыми ключами»;

- «Сервисная функция»;

Описание.

1. Анализ данных в программном буфере CAN.

2. Определение команды в соответствии со специальным протоколом.

3. Выполнение команды.

Альтернативы.

1а. Данные некорректны - завершение.

3а. Выполнение команды «Параметры коммутатора» путём перехода в расширяющий прецедент «Параметры коммутатора».

3б. Выполнение команды «Управление силовыми ключами» путём перехода в расширяющий прецедент «Управление силовыми ключами».

3в. Выполнение команды «Сервисная функция» путём перехода в расширяющий прецедент «Сервисная функция».

  1.  Прецедент «Параметры коммутатора»

Сводка.

Выполнение команды «Параметры коммутатора» в соответствии с протоколом.

Зависимости.

Расширяет прецедент «Обработка данных».

Описание.

1. Обработка данных команды «Параметры коммутатора» в соответствии с протоколом.

2. Применение обработанных параметров коммутатора.

  1.  Прецедент «Управление силовыми ключами»

Сводка.

Выполнение команды «Управление силовыми ключами» в соответствии с протоколом.

Зависимости.

Расширяет прецедент «Обработка данных».

Описание.

1. Обработка данных команды «Управление силовыми ключами» в соответствии с протоколом.

2. Однофазный режим. Включение/выключение указанных силовых ключей.

Альтернативы.

2а. Трёхфазный режим. Включение/выключение всех силовых ключей.

  1.  Прецедент «Сервисная функция»

Сводка.

Выполнение команды «Сервисная функция» в соответствии с протоколом.

Зависимости.

Расширяет прецедент «Обработка данных».

Описание.

1. Обработка данных команды «Сервисная функция» в соответствии с протоколом.

2. В соответствии с кодом сервисной функции выполнить её.

Альтернативы.

2а. Измерение частоты в каналах и отправка результатов по CAN в соответствии с протоколом.

2б. Измерение входного напряжения в каналах и отправка результатов по CAN в соответствии с протоколом.

2в. Измерение нагрузки в каналах и отправка результатов по CAN в соответствии с протоколом.

2г. Отправка текущих параметров коммутатора по CAN в соответствии с протоколом.

  1.  Требования пользователя к программному изделию
    1.  Входные и выходные данные

Входными данными должны являться:

  •  Команда «Параметры модуля коммутатора» по интерфейсу CAN. Данные команды определяют режим работы модуля коммутатора переменного тока;
  •  Команда «Включение/выключение каналов модуля коммутатора» по интерфейсу CAN. Данные команды определяют разрешение работы каналов модуля коммутатора переменного тока;
  •  Команда «Сервисная функция» по интерфейсу CAN. Данные команды выполняют сервисные функции модуля коммутатора переменного тока.

Выходными данными должны являться:

  •  Команда «Информация о состоянии модуля комутации» по интерфейсу CAN. Данная команда возращает информацию о текущем состоянии модуля коммутатора переменного тока;
  •  Команда «Информация об исходном состоянии коммутатора» по интерфейсу CAN. Данная команда возращает информацию о изменяемых параметрах модуля коммутатора переменного тока.
    1.  Программные ограничения, совместимость

Программа должна быть написана на языке C, C++ и работать на 32х разрядном микропроцессоре 1986ВЕ91.

  1.  Результирующие компоненты изделия

В программное изделие должны входить следующие компоненты:

  •  файл-образ флэш для модуля коммутатора переменного напряжения;
  •  программная документация на изделие.
    1.  Носители информации

Программа должна размещаться в флэш-памяти модуля коммутатора переменного напряжения.

  1.  Требования к надежности

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

  1.  Рестарт

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

  1.  Требования к составу и параметрам технических средств

Программное изделие должно работать на микроконтроллере «Миландр» 1986ВЕ91 со следующими характеристиками:

  •  128 кбайт flash-памяти,
  •  оперативная память 32 кбайт.
    1.  Диаграмма вариантов использования

Перечисленные в 1.5.1 прецеденты, а также операции отношения между ними и воздействующие системы отражены в диаграмме вариантов использования, представленной на рисунке 1.1. Диаграмма была построена в соответствии с правилами и обозначениями языка UML [1, с. 96].

Рисунок 1.1 – Диаграмма вариантов использования

  1.  
    Технический проект

Модель предметной области

  1.  МПО на основе прецедента «Начальная инициализация»

При разработке модели предметной области на основе прецедента «Начальная инициализация» были выполнены следующие действия:

Составлен список кандидатов на роль концептуальных классов на основе текстового описания прецедента: «PortClass», «ADCManager», «CANManager», «ClockClass», «HardwareInit», «VSK_main», «Tools».

Добавлены необходимые ассоциации, отражающие связи информационных сущностей. Разработанные ассоциации представлены в таблице 2.1.

Таблица 2.1 – Ассоциации для прецедента «Начальная инициализация»

Объекты

Ассоциации

HardwareInitVSK_main

Передаёт управление

HardwareInit – ClockClass

Передаёт управление

HardwareInit – ADCManager

Передаёт управление

HardwareInit – CANManager

Передаёт управление

HardwareInit – PortClass

Передаёт управление

HardwareInit – Tools

Передаёт управление

Добавлены атрибуты, необходимые для выполнения информационных требований.

На рисунке 2.1 показана модель предметной области, разработанная на основе текстового описания прецедента «Начальная инициализация».

Рисунок 2.1 – Модель предметной области на основе прецедента «Начальная инициализация»

  1.  
  2.  
    1.  
      1.  
      2.   МПО на основе прецедента «Управление энергораспределением»

При разработке модели предметной области на основе прецедента «Управление энергораспределением» были выполнены следующие действия:

Составлен список кандидатов на роль концептуальных классов на основе текстового описания прецедента: «CANManager», «Tools», «ToolsManCh», «ToolsValCh».

Добавлены необходимые ассоциации, отражающие связи информационных сущностей. Разработанные ассоциации представлены в таблице 2.2.

Таблица 2.2 – Ассоциации для прецедента «Управление энергораспределением»

Объекты

Ассоциации

ToolsToolsValCh

Передаёт управление

ToolsValCh – ToolsManCh

Передаёт управление

ToolsManCh – CANManager

Передаёт управление

Добавлены атрибуты, необходимые для выполнения информационных требований.

На рисунке 2.2 показана модель предметной области, разработанная на основе текстового описания прецедента «Управление энергораспределением».

Рисунок 2.2 – Модель предметной области на основе прецедента «Управление энергораспределением»

  1.   МПО на основе прецедента «Получение данных»

При разработке модели предметной области на основе прецедента «Получение данных» были выполнены следующие действия:

Составлен список кандидатов на роль концептуальных классов на основе текстового описания прецедента: «CANManager», «Tools», «ToolsManCh».

Добавлены необходимые ассоциации, отражающие связи информационных сущностей. Разработанные ассоциации представлены в таблице 2.3.

Таблица 2.3 – Ассоциации для прецедента «Получение данных»

Объекты

Ассоциации

CANManagerTools

Передаёт управление

Tools – ToolsManCh

Передаёт управление

Добавлены атрибуты, необходимые для выполнения информационных требований.

На рисунке 2.3 показана модель предметной области, разработанная на основе текстового описания прецедента «Получение данных».

Рисунок 2.3 – Модель предметной области на основе прецедента «Получение данных»

  1.  Реализация прецедентов при помощи диаграмм последовательностей системных операций

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

  1.   Диаграмма последовательности системных операций на основе прецедента «Начальная инициализация»

На рисунке 2.4 показана диаграмма последовательностей системных операций, разработанная на основе прецедента «Начальная инициализация». Диаграмма была построена в соответствии с правилами и обозначениями языка UML [1, с.191].

Рисунок 2.4 – Диаграмма последовательностей системных операций

(для сценария прецедента «Начальная инициализация»)

  1.   Диаграмма последовательности системных операций на основе прецедента «Управление энергораспределением»

На рисунке 2.5 показана диаграмма последовательностей системных операций, разработанная на основе прецедента «Управление энергораспределением». Диаграмма была построена в соответствии с правилами и обозначениями языка UML [1, с.191].

Рисунок 2.5 – Диаграмма последовательностей системных операций

(для сценария прецедента «Управление энергораспределением»)

  1.   Диаграмма последовательности системных операций на основе прецедента «Получение данных»

На рисунке 2.6 показана диаграмма последовательностей системных операций, разработанная на основе прецедента «Получение данных». Диаграмма была построена в соответствии с правилами и обозначениями языка UML [1, с.191].

Рисунок 2.6 – Диаграмма последовательностей системных операций

(для сценария прецедента «Получение данных»)

  1.  
    1.  Диаграмма классов

На рисунке 2.7 показана разработанная диаграмма классов. Диаграмма была построена в соответствии с правилами и обозначениями языка UML [1 с. 291].


Рисунок 2.7 – Диаграмма классов


PAGE  22


 

А также другие работы, которые могут Вас заинтересовать

70436. Разработка поощрительных программ для гостей на предприятии питания на примере ресторана «Пилзнер» 1.3 MB
  В работе проанализирована ситуация развития рынка пивных ресторанов. Определена актуальность поставленной задачи. Проанализированными методы продвижения в ресторанах, дана оценка поощрительным программам и разработаны поощрительные программы для ресторана Пилзнер.
70438. Программное обеспечение для системы сопровождающего контроля на ускорительном комплексе ВЭПП-2000 852.5 KB
  Требования накладываемые на программное обеспечение Каждая из подсистем сопровождающего контроля предъявляет схожие требования к программному обеспечению а следовательно их можно обобщить: высокая стабильность работы 24 часа в сутки 365 дней в году; легкая перенастройка в соответствии...
70441. Исследование специфики использования современных спутниковых средств для повышения точности привязки опознаков 423.5 KB
  Спутниковые радионавигационные системы GPS ГЛОНАСС позволяют в большинстве случаев по сравнению с традиционными методами достигнуть более высокой точности место определения объекта с меньшими экономическими затратами при привязке опознаков.
70442. Визуализация результатов моделирования выхода автономного необитаемого подводного аппарата на источник экологических аномалий 3.97 MB
  Цель работы - разработка программного обеспечения визуализации результатов моделирования выхода автономного необитаемого аппарата на источник экологической аномалии. В результате выполнения работы сформулированы требования к программному обеспечению визуализации и выбраны средства...
70443. ЭЛЕКТРОННАЯ СИСТЕМА УПРАВЛЕНИЯ ДВИГАТЕЛЕМ 1.7 MB
  Центром построения цифровой интегральной системы управления, в котором производится переработка информации о состоянии объекта и принятие решений, является бортовой цифровой вычислительный комплекс