Техническое задание на создание программного обеспечения

Профессор кафедры ВС

на разработку «Модуля автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского

Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электротеплоснабжением корпусов Московского института».

• 2. Основание для разработки
• 2.1. Основанием для данной работы служит договор № 1234 от 10 марта 2003 г.
• 2.2. Наименование работы:

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

• 2.3. Исполнители: ОАО «Лаборатория создания программного обеспечения».
• 2.4. Соисполнители: нет.
• 3. Назначение разработки

Создание модуля для контроля и оперативной корректировки состояния основных параметров теплообеспечения корпусов Московского института.

• 4. Технические требования
• 4.1. Требования к функциональным характеристикам.
• 4.1.1. Состав выполняемых функций.

Разрабатываемое ПО должно обеспечивать:

• • сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков 5А-94 на всех тепловых выходах;
• • сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);
• • предварительный анализ информации на предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска;
• • выдачу рекомендаций по дальнейшей работе;
• • отображение текущего состояния по набору параметров — циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров;
• • визуализацию информации по расходу теплоносителя:
• — текущую, аналогично показаниям счетчиков;
• — с накоплением за прошедшие сутки, неделю, месяц — в виде почасового графика для информации за сутки и неделю;
• — суточный расход — для информации за месяц.

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

По отдельному запросу осуществляются внутренние настройки.

В конце отчетного периода система должна архивировать данные.

4.1.2. Организация входных и выходных данных.

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

Основной режим использования системы — ежедневная работа.

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

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

4.3. Условия эксплуатации и требования к составу и параметрам технических средств.

Для работы системы должен быть выделен ответственный оператор.

Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.

4.4. Требования к информационной и программной совместимости.

Программа должна работать на платформах Yindows 98/

• 1ЧТ/2000.
• 4.5. Требования к транспортировке и хранению.

Программа поставляется на лазерном носителе информации.

Программная документация поставляется в электронном и печатном виде.

• 4.6. Специальные требования:

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

5. Требования к программной документации

Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.

6. Технико-экономические показатели

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

7. Порядок контроля и приемки

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

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

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

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

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам

• 1. Интерфейсы пользователя
• 2. Интерфейсы аппаратного обеспечения
• 3. Интерфейсы программного обеспечения
• 4. Интерфейсы взаимодействия

2. Функциональные требования

3. Требования к производительности

4. Проектные ограничения (и ссылки на стандарты)

5. Нефункциональные требования (надежность, доступность, безопасность и пр.)

6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы

• 1. Содержание системы
• 2. Функции системы
• 3. Характеристики пользователей

4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

• 1. Назначение
• 2. Содержание (границы)

• 3. Обзор продукта
• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователей
• 4. Ограничения

4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами:

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

контроллера и панели оператора

АННОТАЦИЯ

Настоящий документ содержит программу и методику испытаний (ПМИ) прикладного

программного обеспечения (ППО) для щитов постоянного тока серии В производства ОАО «Заказчик», установленных на Электростанции.

Техническое задание определяет технические требования, стадии и этапы разработки, состав

эксплуатационной документации, а также порядок контроля и приемки ППО для щитов

постоянного тока В.

СОДЕРЖАНИЕ

1.1. Наименование разработки

1.2. Область применения

2. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ

2.1. Наименование предприятия Исполнителя и его реквизиты

2.2. Наименование предприятия Заказчика и его реквизиты

2.3. Перечень документов, на основании которых создается ППО

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Общие требования к программному обеспечению

4.1.1. Требования к инструментальному программному обеспечению панели предоставления информации

4.1.2. Требования к прикладному программному обеспечению ПЛК

4.1.3. Требования к прикладному программному обеспечению для получения данных по Modbus RTU

4.2. Требования к функциональным характеристикам ППО

4.2.1. Общие требования

4.2.2. Требования к отображению информации и сигнализации

4.2.3. Требования к архивированию информации

4.2.4. Требования к быстродействию

4.2.5. Требования к функциям диагностики

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

4.4. Требования к информационной и программной совместимости

4.5. Требования к сетевому взаимодействию

5. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

5.1. Требования на соответствие нормам и правилам

5.2. Требования к составу документации

6. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ППО

7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

7.1. Проведение предварительных испытаний

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

7.3. Оборудование, которое будет необходимо для проведения ПНР, но которое не входит в состав компонентов системы

Таблица ввода-вывода для системы

ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ

1. ВВЕДЕНИЕ

1.1. Наименование разработки

Полное наименование разработки – разработка прикладного программного

обеспечения для щитов постоянного тока.

Сокращенное наименование разработки – ППО

1.2. Область применения

Область применения – модернизация систем щитов постоянного тока

Щиты постоянного тока предназначены для обеспечения питания постоянным током

систем аварийного электроснабжения (САЭ), дизель-генератора (ДГС), общеблочной

системы (ОБ), систем управления защит (СУЗ), открытого распределенного устройства,

систем обеспечения сохранности основного оборудования (ОС), управляющих

вычислительных систем (УВС).

2. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ

ППО разрабатывается на основании Договора No от

2.1. Наименование предприятия Исполнителя и его реквизиты

Закрытое акционерное общество « Исполнитель» (ЗАО « Исполнитель»)

2.2. Наименование предприятия Заказчика и его реквизиты

Открытое акционерное общество «Заказчик» (ОАО «Заказчик»)

2.3. Перечень документов, на основании которых создается ППО

Для разработки ППО в качестве исходных данных (ИД) используются

– Техническое задание на ППО .

– ПРИЛОЖЕНИЕ 1 Таблица ввода-вывода для системы

– ПРИЛОЖЕНИЕ 2 Перечень событий

– ПРИЛОЖЕНИЕ 3 Структурная схема

Исполнитель вправе запросить у Заказчика иные ИД, не указанные в настоящем

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

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

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

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

оператору о произошедших событиях с меткой времени.

Целью выполняемых работ является обеспечение:

– регистрации произошедших событий на щитах постоянного тока, глубиной не более

500 сообщений, в виде кольцевого буфера;

– формирования предупредительного или аварийного сообщения при нарушении

(тока, напряжения, сопротивления изоляции) регламентных или аварийных границ;

– обработки входных дискретных сигналов, характеризующих работу защитной и

коммутационной аппаратуры щитов постоянного тока;

– диагностики аппаратного обеспечения контроллера, диагностики связи

аппаратного обеспечения по сети CanOpen.

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Общие требования к программному обеспечению

ППО должно быть разработано в инструментальной среде Uniti XL v6.0 и пакет

Vijeo-Designer Lite фирмы Schneider Electric V1.3.

В состав программного обеспечения должны входить:

– базовые системные программные средства, совместимые с аппаратными

– ППО, которое должно быть разработано для реализации функций контроля и

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

ППО должно подразделяться на ППО ПЛК и ППО панели оператора.

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

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

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

4.1.1. Требования к инструментальному программному обеспечению панели

4.1.1.1. Инструментальное программное обеспечение панели должно представлять

собой пакет Vijeo-DesignerLite фирмы Schneider Electric V1.3

4.1.1.2. Интерфейсы ПО ПК должны быть выполнены на русском языке.

4.1.1.3. Программное обеспечение панели должно быть адаптировано и

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

4.1.1.4. Программное обеспечение панели должно быть интуитивно понятным и

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

– Отображение текущего состояния сигналов ввода-вывода на видеокадрах.

4.1.2. Требования к прикладному программному обеспечению ПЛК

4.1.2.1. Программное обеспечение ПЛК должно разрабатываться с использованием

инструментальной системы UNITY PRO XL версии не ниже 6.0, фирмы Schneider Electric на языках по стандарту Международной электротехнической комиссии МЭК 61131-3.

4.1.2.2. Программное обеспечение ПЛК должно быть адаптировано и оптимизировано для работы на конкретном объекте с учетом особенностей технологического процесса. Требования к функциям алгоритмов, реализуемых в прикладных задачах ПЛК, должны быть определены настоящим ТЗ.

4.1.2.3. Программные средства ПЛК должны обеспечивать реализацию следующих

– информационный обмен по коммуникационным каналам;

– ввод/вывод по дискретным и аналоговым каналам;

– сбор данных и управление световыми табло;

– конфигурирование системных программных средств под конкретный объект;

– диагностирование программно-аппаратных средств;

4.1.3. Требования к прикладному программному обеспечению для получения

данных по Modbus RTU

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

контроллера информацию в виде «среза» (буфера обмена) в виде файла XLS до 500 строк сообщений.

4.2.Требования к функциональным характеристикам ППО

4.2.1. Общие требования

4.2.1.1. ППО должно обеспечивать следующие функции:

– контроль технологических параметров (тока, напряжения, сопротивления

изоляции), состояние коммутационных аппаратов;

– преобразование измерений в единицы физической размерности;

– сглаживание (фильтрация) измерений;

– формирование и выдача команд на внешнюю световую индикацию;

– отображения состояния коммутационных аппаратов и значения технологических

параметров в виде мнемосхем (однолинейные схемы);

– регистрация событий: изменения состояния коммутационных аппаратов,

нарушения технологических параметров предупредительных и аварийных значений;

4.2.1.2. Должна быть предусмотрена возможность изменения уставных значений

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

4.2.2. Требования к отображению информации и сигнализации

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

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

Лист вывода сообщений должен нести информацию о точном времени и дате

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

4.2.3. Требования к архивированию информации

4.2.3.1. Должна быть предусмотрена возможность ведения следующих архивов:

– архива зарегистрированных в хронологическом порядке событий по объекту

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

сообщений должна быть сформирована в виде кольцевого буфера.

В архиве должны фиксироваться следующие события:

– нарушения технологических параметров предупредительных и аварийных границ;

– неисправность аппаратов защит и коммутационных аппаратов;

– неисправности и отказы в программных и технических средствах системы

4.2.4. Требования к быстродействию

4.2.4.1. Период обновления информации на панели представления информации

должен составлять не более 1 секунды.

4.2.4.2. Периодичность опроса параметров должен соответствовать циклу опроса

контроллера и быть не более 200 мс.

4.2.5. Требования к функциям диагностики

4.2.5.1. ППО должно выполнять следующие диагностические функции:

– проверку на обрыв или короткое замыкание датчиков для токовых каналов

– проверку достоверности (выход за измерительный диапазон);

– диагностику сетевых соединений на шине CanOpen с проверкой на обрыв связи.

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

Центральные процессоры должны иметь тип BMXP3420302. Состав модулей ввода-

вывода указан в приложении 9 и 10 настоящего Технического Задания (ТЗ).

4.4.Требования к информационной и программной совместимости

ППО ЩПТ должно строиться по модульному принципу, обеспечивающему

автономное создание отдельных программных модулей (ПМ) на базе стандартной

библиотеки функциональных блоков (ФБ) инструментального пакета Unity Pro XL V.6.

Взаимодействие оперативного персонала с программным обеспечением должно осуществляться на внешнем (пользовательском) уровне интерфейса без сопровождения и обслуживания программ.

4.5.Требования к сетевому взаимодействию

4.5.1.1. Взаимодействие на уровне сети Ethernet TCP/IP

Система должна обеспечивать возможность получения текущего состояния сигналов

ввода-вывода в защищенную сеть предприятия. Адреса сетевых устройств и адреса

переменных уточняются при проведении ПНР.

4.5.1.2. Взаимодействие на уровне сети Modbus RTU

Заказчику будет передано приложение, позволяющее получать данные из кольцевого буфера и просматривать сообщения в формате MS OFFICE EXCEL. Заказчику необходимо будет предоставить компьютер с предустановленной системой Windows XP SP3.

5.1. Требования на соответствие нормам и правилам

Разработка и оформление документации ППО должно выполняться в соответствии с требованиями:

Документация должна быть разработана для следующих серий ЩПТ – 4EA, 4EB, 4EC и 4ED в отдельности.

5.2. Требования к составу документации

В состав программной документации на ППО должны входить следующие

– Техническое задание на разработку ППО.

– Программа и методика испытаний на площадке Исполнителя.

– Программа и методика приемочных испытаний на площадке эксплуатации ( ).

6. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ППО

При разработке ППО должны выполняться следующие работы:

-Разработка и согласование Технического задания на создание ППО щитов

-Доработка ППО в соответствии с требованиями настоящего технического задания.

-Разработка технической документации в соответствии с Календарным планом (таблица 6.1).

-Проведение предварительных испытаний ППО на полигоне Исполнителя с

использованием программного имитатора сигналов нижнего уровня.

Календарный план выполнения работ приведен в таблице 6.1.

Таблица 6.1 – Календарный план выполнения работ

No

этапа

Наименование

работ

Сроки выполнения
Начало Окончание Отчетные материалы 1

1. ТЗ на ПО ПЛК и ПО панели.

2. Описание программы.

3. Программа и методика испытаний.

4. Руководство программиста.

5. Руководство оператора.

6. Программное изделие (CD) c

формуляром по акту приёма-

7. Протокол предварительных

8. Акт сдачи-приёмки работ.

*Существует разночтение по п.6.

На момент сдачи программы ввиду

физического отсутствия модулей

памяти ППО будет передана на

другом носителе информации.

7.1. Проведение предварительных испытаний

Целью предварительных испытаний ППО являются испытания на соответствие

настоящему техническому заданию. Испытания проводятся в соответствии с методикой приемочных испытаний.

Предварительные испытания ППО должны производиться по согласованной

программа +и методика приемочных испытаний (ПМИ) на стенде Исполнителя

При получении неудовлетворительных результатов предварительных испытаний

Исполнитель должен провести анализ причин выявленных неисправностей, принять

необходимые меры по их устранению. Повторные предварительные испытания допускается

проводить только по тем требованиям, по которым были получены неудовлетворительные

К предварительным испытаниям должны быть представлены:

– Программа и методика испытаний.

Сдача-приемка осуществляется комиссией, в состав которой входят представители

Заказчика и Исполнителя.

По результатам приемки подписывается Акт предварительных испытаний.

7.2. Последовательность проведения пуско-наладочных мероприятий по каждой

– Загрузка нового системного обеспечения (firmware) для обеспечения

– Проверка и корректировка ППО в части приема полевых сигналов на шине

CanOpen. Настройка шины CanOpen;

– Загрузка ППО в контроллер системы;

– Загрузка ППО в панель визуализации;

– Настройка и устранение выявленных недостатков.

7.3. Оборудование, которое будет необходимо для проведения ПНР, но которое не

входит в состав компонентов системы

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

Windows XP SP3, а также офисным пакетом MS OFFICE 2007(10).

Таблица ввода-вывода для системы 4EA