Разработка информационной системы для формирования сменной ведомости в АСУ: методология, проектирование и экономическое обоснование

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

Настоящая работа представляет собой исчерпывающую методологию и проектное решение для создания информационной системы (ИС), интегрируемой в общую Автоматизированную Систему Управления (АСУ) предприятия. В основе исследования лежит строгий системный анализ, использование актуальной нормативной базы Российской Федерации и глубокая проработка вопросов технической реализации, информационной безопасности и экономического обоснования. Цель — предоставить студентам технического профиля детально проработанный, академически корректный и практически применимый материал, способный стать фундаментом для дипломного проектирования.

Теоретические и методологические основы проектирования АСУ

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

Понятийно-терминологический аппарат и классификация систем

Согласно ГОСТ 34.003-90, Автоматизированная система (АС) — это система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Разновидностью АС является Автоматизированная система управления (АСУ), основное предназначение которой — обеспечение эффективного функционирования объекта управления путем автоматизированного выполнения функций управления. В контексте производственного предприятия, к объектам управления могут относиться технологические процессы (АСУТП), оборудование (например, ГПА), или организационные процессы (например, управление персоналом или отчетностью).

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

Ключевые элементы ИС в соответствии с ГОСТ 34.320-96 «Концепции и терминология для концептуальной схемы и информационной базы» включают:

  1. Концептуальная схема: Модель предметной области, полученная в результате системного анализа. Она описывает содержимое базы данных, включая перечень допустимых действий над этими данными, и определяет статические, динамические аспекты и зависимости проблемной области.
  2. Информационная база: Непротиворечивая совокупность предложений, выражающих фактическое состояние сущностей в определенный момент времени. На практике это совокупность данных, хранящихся в СУБД.
  3. Информационный процессор: Средство, которое осуществляет изменения в концептуальной схеме и информационной базе, реагируя на поступающие сообщения (команды или данные).

В производственных АСУТП системы традиционно строятся по трехуровневому принципу (см. Таблицу 1):

Уровень Название Функции Технические средства
Нижний Уровень полевых устройств Измерение параметров, исполнение команд Датчики, исполнительные механизмы
Средний Уровень автоматического регулирования Сбор, первичная обработка данных, реализация логики управления Программируемые логические контроллеры (ПЛК)
Верхний Уровень диспетчеризации (ИС Отчетности) Визуализация, диспетчеризация, архивирование, формирование отчетности SCADA/HMI-системы, Серверы баз данных, Клиентские рабочие станции

ИС формирования сменной ведомости располагается на верхнем уровне, используя данные, собранные SCADA-системой и контроллерами.

Системный анализ как основа разработки ИС

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

Этапы системного анализа:

  1. Постановка задачи: Четкое определение целей и границ проектируемой системы (в нашем случае — автоматизация формирования сменной ведомости).
  2. Анализ предметной области: Изучение существующего процесса, выявление его элементов, связей и функций.
  3. Формализация: Создание концептуальной модели системы, включая разработку концептуальной схемы данных (объекты, атрибуты, связи).
  4. Разработка вариантов: Предложение альтернативных архитектурных и программных решений.
  5. Оценка и выбор: Экономическое и техническое обоснование выбора наилучшего варианта, который должен обеспечить максимальную эффективность (степень достижения целей) при оптимальной степени автоматизации.

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

Анализ предметной области и определение требований к подсистеме

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

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

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

Типичная архитектура существующего процесса:

  1. Сбор данных: Оператор визуально контролирует параметры (давление, температура, наработка часов ГПА, расход газа) по приборам или через HMI-интерфейс SCADA-системы.
  2. Запись: Данные периодически (каждый час, смену) записываются в бумажный журнал или в электронную таблицу (например, Excel).
  3. Обработка и Формирование Ведомости: В конце смены данные из журнала переносятся в унифицированную форму сменной ведомости. Выполняются ручные расчеты (например, суммарная наработка, удельный расход).
  4. Передача: Ведомость подписывается и передается в диспетчерскую или бухгалтерию.

Проблемы и «узкие места»:

  • Низкая достоверность данных: Ручной ввод информации, особенно в условиях высокой нагрузки или ночью, неизбежно ведет к ошибкам, связанным с человеческим фактором (опечатки, округление, пропуск записей).
  • Задержка информации: Данные становятся доступными для анализа только после завершения смены, что исключает возможность оперативного реагирования на отклонения.
  • Трудоемкость: Значительное время оператора тратится на рутинную работу по сбору и переносу данных, отвлекая его от непосредственного контроля за технологическим процессом.
  • Проблемы анализа: Данные хранятся в неструктурированном виде (Excel-файлы, бумажные архивы), что затрудняет построение сквозной аналитики и долгосрочное прогнозирование.

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

Разработка функциональных и нефункциональных требований

Определение требований — ключевой этап, регламентированный ранее ГОСТ 34.602-89 (хотя и признанный недействующим с 2025 года, его структура остается эталонной для академических работ). Требования делятся на функциональные и нефункциональные.

1. Функциональные требования (ФТ)

ФТ описывают, что именно система должна делать:

  • ФТ-1: Автоматический сбор данных. Система должна подключаться к SCADA-серверу (или базе данных АСУТП) и автоматически получать технологические параметры (Т, P, Q, статус ГПА) с заданной периодичностью (например, каждые 15 минут).
  • ФТ-2: Ведение и манипулирование данными. Система должна обеспечивать функции добавления, изменения и удаления информации, внесенной пользователем (например, комментарии оператора, данные о техническом обслуживании).
  • ФТ-3: Расчетные функции. Автоматическое выполнение сложных расчетов (например, расчет удельных показателей, суммарной наработки, коэффициентов эффективности).
  • ФТ-4: Формирование отчетности. Генерация сменной ведомости в унифицированном формате (согласно утвержденному на предприятии образцу) с возможностью экспорта в стандартные форматы (PDF, XLS).
  • ФТ-5: Поиск и фильтрация. Предоставление пользователю возможности поиска ведомостей по дате, смене, оператору или конкретному агрегату.

2. Нефункциональные требования (НФТ)

НФТ описывают, насколько хорошо система должна работать:

  • НФТ-1: Производительность. Время формирования сменной ведомости не должно превышать 5 секунд. Обработка запроса на поиск — не более 2 секунд.
  • НФТ-2: Надежность и Отказоустойчивость. Доступность системы должна составлять не менее 99.9%. Должен быть предусмотрен механизм резервирования данных.
  • НФТ-3: Безопасность. Реализация ролевой модели доступа (оператор, мастер, администратор) и журнала аудита всех изменений данных.
  • НФТ-4: Масштабируемость. Система должна поддерживать добавление новых технологических объектов (ГПА) без существенного изменения архитектуры.
  • НФТ-5: Удобство использования (Эргономика). Интерфейс должен быть интуитивно понятным, с минимальным количеством кликов для выполнения типовых операций, что является прямой мерой минимизации человеческого фактора.

Проектирование информационной системы формирования сменной ведомости

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

Обоснование выбора методологии и инструментальных средств

Жизненный цикл АСУ, согласно классическому подходу, регламентируется ГОСТ 34-й серии. Он включает стадии анализа требований, проектирования (эскизный и технический проекты), разработки, внедрения, эксплуатации и сопровождения.

Критическое замечание о ГОСТах: Важно отметить, что ключевые стандарты по документации и техническому заданию, такие как ГОСТ 34.602-89 (ТЗ) и ГОСТ 34.201-89 (документация), признаны недействующими с начала 2024/2025 года. Тем не менее, в академической среде их структура и последовательность этапов продолжают служить основой для дипломного проектирования. В реальной разработке, применительно к ИС, все чаще используются гибкие методологии (Agile, Scrum), адаптированные к жизненному циклу, но требования к комплектности и содержанию проектной документации остаются высокими.

Выбор инструментальных средств:

Компонент Выбор Обоснование
СУБД PostgreSQL / MS SQL Server Надежные, масштабируемые реляционные СУБД, поддерживающие сложные транзакции и обеспечивающие высокий уровень информационной безопасности. PostgreSQL предпочтительнее в условиях импортозамещения.
Язык Программирования Python (Backend) / JavaScript (Frontend) Python обеспечивает быстроту разработки, наличие мощных библиотек для работы с данными и интеграции с АСУТП (через OPC UA/Modbus), а также используется для создания интеллектуальных модулей.
Среда Разработки (IDE) PyCharm / Visual Studio Code Стандартные инструменты, обеспечивающие эффективное тестирование и отладку.
Интерфейс (HMI) Web-интерфейс (React/Vue) Обеспечивает кроссплатформенность, удобство развертывания и соответствие современным эргономическим требованиям.

Проектные решения подсистемы (концептуальная, логическая и физическая схемы)

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

1. Концептуальная схема (ГОСТ 34.320-96)

Концептуальная схема отражает сущности предметной области. Основные сущности для ИС сменной ведомости:

  • Агрегат (ГПА): (Код, Название, Мощность, Дата ввода в эксплуатацию).
  • Смена: (Номер смены, Дата, Время начала, Время окончания).
  • Оператор: (Табельный номер, ФИО, Должность).
  • Ведомость: (ID Ведомости, Дата создания, Оператор_ID, Смена_ID, Статус).
  • ПараметрТехнологический: (ID Параметра, Имя параметра, Единица измерения).
  • ЗаписьСменная: (ID Записи, Ведомость_ID, Агрегат_ID, Время сбора, Значение параметра_1, Значение параметра_N).

2. Логическая структура базы данных

Логическая схема (ER-диаграмма) нормализует концептуальную модель, устраняя избыточность. Например, таблица «Ведомость» будет иметь внешние ключи к таблицам «Оператор» и «Смена», обеспечивая непротиворечивость данных. Этот шаг обеспечивает целостность информационного пространства, что критически важно для дальнейшей аналитики.

3. Архитектура программного обеспечения

Применяется трехуровневая архитектура:

  1. Уровень данных (СУБД): Хранение исторических данных и текущей информации о ведомостях.
  2. Уровень приложений (Backend-сервер): Бизнес-логика, включая алгоритмы:
    • Алгоритм сбора данных: Периодический запрос к базе данных АСУТП или SCADA-системе.
    • Алгоритм расчета: При закрытии смены автоматически запускается процедура расчета удельных показателей.
    • Алгоритм генерации отчета: Формирование PDF-документа на основе шаблона и агрегированных данных.
  3. Уровень представления (Frontend): Пользовательский интерфейс для ввода, просмотра и печати ведомостей.

Обеспечение информационной безопасности и минимизация человеческого фактора

В условиях глобального трансграничного характера информационных технологий, обеспечение безопасности в АСУ, особенно на объектах критической инфраструктуры (КИИ), является приоритетом государственной важности, что отражено в Доктрине информационной безопасности Российской Федерации (2016).

Угрозы информационной безопасности и соответствие Доктрине ИБ РФ

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

Актуальные угрозы и меры защиты:

Категория Угрозы Примеры Угроз Меры Защиты в ИС
Внешние кибератаки Внедрение вредоносного кода, DoS-атаки, несанкционированный доступ Сегментация сети, использование межсетевых экранов, изоляция критических компонентов (базы данных), шифрование каналов связи.
Уязвимости ПО Недостатки сетевых протоколов, ошибки в коде Регулярное обновление ПО, использование проверенных фреймворков, аудит безопасности кода, применение систем контроля целостности.
Человеческий фактор Несанкционированные действия персонала, непреднамеренные ошибки Строгий контроль доступа на основе ролей (RBAC), двухфакторная аутентификация, журнал аудита всех действий пользователей.
Отказы оборудования/ПО Сбой СУБД, потеря данных Резервирование данных (ежедневное, инкрементное), ��орячий резерв сервера, использование отказоустойчивых кластеров.

Оценка эффективности систем защиты информации является обязательным элементом, который должен проводиться по методикам, утвержденным регулятором (ФСТЭК России), для подтверждения соответствия требованиям безопасности.

Методы минимизации влияния человеческого фактора

Человеческий фактор — одна из основных причин сбоев и ошибок в АСУ. Внедрение ИС должно не только автоматизировать процесс, но и минимизировать риски, связанные с персоналом.

  1. Исключение ручного ввода критических данных: Максимально возможный объем информации о технологическом процессе должен поступать в систему автоматически, напрямую из ПЛК или SCADA-системы. Пользователь должен вносить только качественные, описательные данные (комментарии, причины отклонений).
  2. Верификация и валидация данных: Система должна включать механизмы проверки введенных данных:
    • Диапазонная проверка: Если оператор вводит значение параметра, выходящее за физически возможные или нормативные пределы, система должна выдавать предупреждение и требовать подтверждения.
    • Логическая проверка: Сравнение вводимых данных с предыдущими записями или показаниями смежных датчиков для выявления аномалий.
  3. Отказоустойчивые архитектуры (АСУТП): В критически важных системах (хотя ИС отчетности менее критична, чем прямое управление) часто используется принцип «пара и резерв»: параллельная работа двух или более контроллеров, результаты которых подвергаются голосованию для исключения аппаратного сбоя. В контексте ИС отчетности, это реализуется через горячий резерв сервера приложений и базы данных, обеспечивая мгновенное переключение при сбое основного компонента.

Экономическое обоснование и требования охраны труда

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

Методика экономического обоснования проекта

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

1. Расчет сметной стоимости разработки ($C_{разр}$)

Сметная стоимость включает трудоемкость, аппаратное и программное обеспечение. Наиболее значимый компонент — трудоемкость, которая рассчитывается по формуле:

C_разр = Σ(Tᵢ × ЗПᵢ) + C_ПО + C_ОБ

Где:

  • Tᵢ — трудоемкость i-го этапа разработки (чел.-часы);
  • ЗПᵢ — стоимость одного чел.-часа специалиста;
  • C_ПО — стоимость лицензий программного обеспечения (если применимо);
  • C_ОБ — стоимость дополнительного оборудования (сервер, рабочие станции).

Пример расчета трудоемкости (T):

Этап Специалист Норма времени (чел.-ч)
Анализ требований Системный аналитик 160
Проектирование БД и архитектуры Архитектор/Разработчик 240
Кодирование и модульное тестирование Разработчик 600
Интеграция и тестирование Тестировщик 120
Общая трудоемкость 1120

2. Расчет годовых эксплуатационных издержек ($C_{эксп}$)

Эксплуатационные издержки включают амортизацию оборудования, заработную плату персонала сопровождения, расходы на электроэнергию и обслуживание:

C_эксп = C_ам + C_зп_обс + C_эл + C_рем

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

3. Расчет полезного эффекта ($Э$)

Полезный эффект от внедрения ИС сменной ведомости — это не только прямая экономия (сокращение штата), но и косвенные, качественные показатели, такие как:

  • $Э_{опер}$ (Оперативность): Снижение времени на принятие решений за счет мгновенного доступа к актуальной отчетности.
  • $Э_{дост}$ (Достоверность): Уменьшение ошибок, связанных с человеческим фактором. Повышение качества отчетности, что является важным фактором для диссертационных исследований в области бухгалтерских и управленческих ИС.
  • $Э_{труд}$ (Снижение трудоемкости): Освобождение оперативного персонала от рутинных функций.

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

Эргономические требования и охрана труда при эксплуатации ИС

Раздел охраны труда (ОТ) и производственной эргономики является обязательным элементом академической работы и обеспечивает соответствие условий труда персонала АСУ действующим нормативам.

Комфортные условия обитаемости персонала АСУ, работающего с проектируемой ИС, должны соответствовать действующим санитарным нормам и стандартам безопасности труда.

  1. Требования к микроклимату и воздуху рабочей зоны:
    • Регламентируются ГОСТ 12.1.005-88 «Общие санитарно-гигиенические требования к воздуху рабочей зоны». Стандарт устанавливает предельно допустимые условия обитаемости, включая оптимальные и допустимые параметры температуры, влажности и скорости движения воздуха в помещении оператора.
  2. Классификация опасных и вредных производственных факторов:
    • ГОСТ 12.0.003-2015 «Опасные и вредные производственные факторы. Классификация» требует анализа факторов, воздействующих на оператора ИС. К ним относятся:
      • Психофизиологические: нервно-психическое напряжение, монотонность труда, нагрузка на зрение.
      • Физические: электромагнитное излучение от оборудования, шум, недостаточное освещение.
  3. Эргономические требования к рабочему месту:
    • Рабочее кресло: Должно соответствовать ГОСТ 21889-76 «Система «человек-машина». Кресло человека-оператора. Общие эргономические требования». Это включает требования к регулировке высоты сиденья, наклону спинки и подлокотникам, чтобы минимизировать статическую нагрузку на позвоночник.
    • Рабочая зона: Расположение мониторов, клавиатуры и других средств ввода-вывода должно соответствовать антропометрическим данным пользователя и ГОСТ 21958-76 (хотя его статус требует уточнения, принципы взаимного расположения мест остаются актуальными).
    • Освещение: Уровень искусственного и естественного освещения должен соответствовать СанПиНам, чтобы снизить зрительное утомление.

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

Заключение

Разработанная методология создания информационной системы для автоматизированного формирования сменной ведомости демонстрирует комплексный подход, охватывающий все этапы жизненного цикла АСУ — от системного анализа до экономического обоснования и обеспечения безопасности. Внедрение этой системы позволит предприятию перейти от реактивного управления к проактивному, основанному на данных высокой степени достоверности.

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

  1. Систематизация теоретической базы: Четко определены ключевые понятия АСУ и ИС, включая детализацию элементов ИС согласно ГОСТ 34.320-96 (концептуальная схема, информационная база), что соответствует высоким академическим требованиям.
  2. Актуализация нормативной базы: Проект учитывает требования Доктрины информационной безопасности РФ (2016) и специфические нормативы по охране труда (ГОСТ 12.1.005-88, ГОСТ 21889-76), что повышает практическую применимость и уникальность исследования.
  3. Комплексное обоснование: Представлена детальная методика экономического обоснования, включающая расчеты трудоемкости и анализ полезного эффекта, подтверждающая целесообразность автоматизации.

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

Список использованной литературы

  1. Лукас В.А. Теория управления техническими системами. Екатеринбург: УГГГА, 2002. 675 с.
  2. Бессекерский В.А., Попов Е.П. Теория систем автоматического управления. Санкт-Петербург: Профессия, 2003. 752 с.
  3. Федоров Ю.Н. Справочник инженера по АСУТП. Москва, 2008. 928 с.
  4. Харбор Р., Филлипс Ч. Системы управления с обратной связью. Санкт-Петербург: Лаборатория базовых знаний, 2001. 616 с.
  5. Клюев А.С. Проектирование систем автоматизации технологических процессов. Санкт-Петербург: Энергоатомиздат, 2005. 464 с.
  6. Баронов В.В. Автоматизация управления предприятием. Санкт-Петербург: Инфра-М, 2004. 239 с.
  7. Парк Д. Передача данных в системах контроля и управления. Москва, 2005. 432 с.
  8. Мусаев А.А. Алгоритмы аналитического управления производственными процессами. Москва, 2005. 432 с.
  9. Мусаев А.А. Автоматизация диспетчеризации производственных процессов промышленных предприятий. Москва, 2007. 232 с.
  10. Горелик Т.Г. АСУ ТП магистральных подстанций. Новые технические решения и опыт внедрения. Москва, 2008. 122 с.
  11. Нестеров А.Л. Проектирование АСУТП. Методическое пособие Книга 1. Москва, 2009. 212 с.
  12. Васильева Е.В. Оценка эффективности информационных технологий информационных систем: учебное пособие ГОУ ВПО. Москва, 2006.
  13. Кабанов А.Я. Оценка экономической и социальной эффективности проекта совершенствования системы и технологии управления персоналом организации: учебное пособие. Москва: Госуниверситет управления, 2006.
  14. Самогородская М.И. Методические указания по выполнению организационно-экономических расчетов в дипломном проектировании для студентов специальности «Информационные системы». Воронеж: ВГТУ, 2001.
  15. Скрипкин К.Г. Экономическая эффективность информационных систем. Москва: ДМКпресс, 2002.
  16. Стандарты в проектах современных информационных систем: сб. тр. III-й Всерос. практ. конф. Москва, 23–24 апреля 2003 г.
  17. Кадушин А., Михайлова Н. Методика оценки экономической эффективности ИТ // Тезисы доклада на III-й Всерос. конф. «Стандарты в проектах современных систем». Москва, 23–24 апреля 2003 г.
  18. Шумилин В.К. Краткий курс безопасности: Памятка для работников, занятых эксплуатацией ПЭВМ и видеодисплейных терминалов / под ред. В.К. Шумилина. Санкт-Петербург: Соуэло, 2005. 32 с.
  19. Белов С.В. Безопасность жизнедеятельности / под общ. ред. С.В. Белова. Москва: Высшая школа, 1999. 446 с.
  20. Жилов Ю.Д., Куценко Г.И. Справочник по гигиене труда и производственной санитарии. Москва: Высшая школа, 1999. 240 с.
  21. Русак О.Н. Безопасность жизнедеятельности / под ред. О.Н. Русака. Санкт-Петербург: Санкт-Петербургская лесная академия, 2001. 450 с.
  22. Демирчголян Г.Г. Компьютер и здоровье. Москва: Лукоморье, 1997.
  23. СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организация работы. Москва: Госкомсанэпиднадзор России, 1996.
  24. СНиП 23–05–95. Естественное и искусственное освещение. Москва: ГП «Информрекламиздат», 2004. 35 с.
  25. Правила устройства электроустановок. Москва: Энергоатомиздат, 1997. 648 с.
  26. Положение о порядке проведения аттестации рабочих места условиям труда: Приложение к постановлению Министерства Труда и социального развития Российской Федерации от 14.03.97. 108 с.
  27. Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса: Руководство. Москва: Информационно-издательский центр Госкомсанэпиднадзора России, 1994. 44 с.
  28. Кроль Ц.И., Мясоедова Е.И., Терешкевич С.Г. Качество промышленного освещения / под ред. Ц.И. Кроля. Москва: Энергоатомиздат, 1991. 225 с.
  29. ГОСТ 17677–82 (СТ СЭВ 3182—81). Светильники. Общие технические требования. Москва: Издательство стандартов, 1989. 112 с.

Похожие записи