Конфигурирование программного обеспечения. Управление конфигурациями сетевого программного обеспечения

«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра «Измерительно-вычислительные комплексы»

ПО ПРЕДДИПЛОМНОЙ ПРАКТИКЕ В

ТЕХНОЛОГИИ»

УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ СЕТЕВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Выполнил :

студент гр. ИСТд-41

Руководитель от предприятия :

системный архитектор

Романов Антон Алексеевич

Руководитель от кафедры :

доцент каф. ИВК, к. т.н., доцент

Ульяновск, 2013

Список использованных сокращений и обозначений

Agile - гибкая методология разработки.

Введение

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

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

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

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

ЗДЕСЬ НУЖНО НАПИСАТЬ КАКОЙ-ТО ТЕКСТ

ЗДЕСЬ НУЖНО УПОМЯНУТЬ О ПАТТЕРНАХ

ЗДЕСЬ ДОЛЖНЫ БЫТЬ ЦЕЛИ

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

    Идентификация программных конфигураций;

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

    Контроль программных конфигураций;

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

    Учёт статусов программных конфигураций;

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

    Аудит конфигураций;

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

    Управление выпуском и поставкой.

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

Анализ источников

По данной теме наиболее подходящими для изучения могут быть следующие источники:

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

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

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

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

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

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

Состав и порядок функционирования объекта автоматизации (процессы)

Состав и порядок функционирования объекта автоматизации (информация)

Заключение

Список использованных источников

1. Why Order Matters in Automated Systems Administration / Infrastructures. Org: Best Practices in Automated Systems Administration and Infrastructure Architecture. – Philadelphia, PA, 2002. – Mode of access: http://www. infrastructures. org/papers/turing/turing. html

2. Aiello, R., Sachs, L. Configuration Management Best Practices: Practical Methods that Work in the Real World / R. Aiello, L. Sachs. – Boston: Addison-Wesley Professional, 2010. – 272 pp.

3. Moreira, M. Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed / M. Moreira. – West Sussex: Wiley, 2010. – 277 pp.

4. Berczuk, S., Software Configuration Management Patterns: Effective Teamwork, Practical Integration / S. Berczuk, B. Appleton. – Boston: Addison-Wesley Professional, 2003. – 218 pp.

5. CS-Cart Development Documentation / Shopping Cart Software & Ecommerce Software Solutions by CS-Cart. – Russia, 2013. – Mode of access:

6. Knowledge Base / Shopping Cart Software & Ecommerce Software Solutions by CS-Cart. – Russia, 2013. – Mode of access: http://kb. /

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

Состав программного обеспечения (ПО) вычислительной системы называют программ­ной конфигурацией .

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

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

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

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

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

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

    служебные, с помощью которого пользователь может повысить эффективность работы компьютера, оптимизировать функции программного и аппаратного обеспечения;

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

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

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

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

2. Важнейшее служебное ПО, а именно:

    служебные программные средства ОС Windows;

    диспетчеры файлов;

    архиваторы.

3. Из прикладного ПО в данной главе будет рассмотрен только программный пакет MicrosoftOffice– самое распространенная среда для делопроизводства. А на практике расширенные возможностиWord,Excel,PowerPoint,Accessосваиваются в рамках лабораторного практикума.

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

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

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

Что именно стоит настраивать.

Вот типичные примеры данных, которые часто стоит вынести в настройки:

  • Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
  • Сетевые настройки. Имена серверов, IP-адреса, порты, имена и пароли для автоматического доступа.
  • Настройки баз данных. Имена JDBC-драйверов, URL базы данных, SQL-запросы, зависимые от используемой БД.
  • Настройки внешнего вида. Настройки Swing-овского Look & Feel-а, используемые шрифты, размеры, цвета, настройки горячих клавиш.
  • Прочее... Любые другие вещи, которые могут менятся от пользователя к пользователю.

Например, довольно часто встречаемая ситуация - настройка соединения с БД. Начинающие программисты часто пишут нечто подобное:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:MyDatabase",user,password);

Таким образом программа привязывается к конкретному JDBC драйверу. Использовать другой драйвер, например заменить мост на RMI-прокси или, в случае Oracle, OCI на Thin без перекомпиляции уже нельзя.

В объектном программировании всё представляется в виде объектов. Настройки лучше всего при этом рассматривать как свойства определённых объектов, которые хранятся в файлах конфигураций. То, каким образом эти настройки считываются и записываются тесно взаимосвязано с форматом файлов и выбраной стратегией администрирования. Рассмотрим идеальный вариант:

  1. Настраиваемый объект не должен содержать знаний о формате файлов и способе чтения/записи. Это позволило бы, в случае необходимости, заменить один способ другим.
  2. Большинство настроек должны выполняться при помощи программы (подпункт меню или отдельная программа настройки). Это сильно облегчает жизнь человека, который занимается администрированием. У большинства "юниксоидов" это может вызвать непонимание:-), но редактированием текстовых файлов в современном мире во многих случаях не обойтись.
  3. Должно быть установлено разумное умолчание для отсутствующих параметров. Другими словами - необходимо, чтобы большинству пользователей для запуска программы нужно было бы сделать минимум настроек. Как правило это оставляет благоприятное первое впечатление о программе, а часто именно оно - самое важное.

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

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

Разумное же умолчание для параметров часто просто невозможно представить. Например, что поставить в качестве имени SMTP-сервера? В случае Unix-систем можно попробовать поставить localhost, но для Windows-мира это редко кому подойдёт.

Рассмотрим наиболее распространённые варианты:

Ini-файлы.

Ini-файлы - это был самый распространённый вариант в эпоху Windows 3.x. Сейчас в виндовых программах он стал вытесняться хранением настроек в реестре. Тем не менее ini - это один из простейших вариантов хранения настроек. К сожалению довольно часто эта простота заставляет прибегать к различно рода ухищрениям. Пример типичного ini-файла:

InputDir=INPUT OutputDir=OUTPUT ArchDir=ARHIV TransferPath = a:\cour NoReceived=No Numb = 3 MenuName1 = ~N~orton ProgName1 = mousesav c:\command.com /c nc MenuName2 = Win - ~Б~локнот ProgName2 = notepad MenuName3 = Импорт из формата АБ "Инкомбанк" ProgName3 = incom.bat

В Java нет стандартного класса для чтения ini-файлов, но это не проблема. Т.к. формат очень прост, его легко сделать самому:

Файлы Properties.

Этот формат распространён в Unix-мире. Он ещё проще ini-файлов, т.к. в нём отсутствует понятие секций - всё состоит из ключей и значений. Пример типичного файла:

# Database configuration Database.Driver=sun.jdbc.odbc.JdbcOdbcDriver Database.DataURL=jdbc:odbc:MyDatabase Database.Prop.user=user Database.Prop.password=password

В Java есть готовый класс для чтения/записи таких файлов (java.util.Properties), но с ним есть некоторые проблемы. Во первых для чтения невозможно задать кодировку файла, а это означает проблемы с русскими буквами. Во вторых стандартная функция записи сохраняет данные в порядке следования хэш-значений ключей, что значит - как ей больше понравится. Но это тоже легко разрешимо - достаточно написать свою читалку/писалку.

XML-файлы.

Этот формат подходит для многих целей, в том числе и для хранения настроек. XML-формат ориентирован на древовидные структуры, что довольно естественым образом отображается на объекты. Пример типичного файла:

user password

Для чтения и записи таких файлов предназначены специальные библиотеки - так называемые XML-парсеры. Таких парсеров уже сделано довольно много, так что писать его самому нет большого смысла - достаточно лишь подобрать подходящий. Для парсеров было разработано два стандартных программных интерфейса - событийный (SAX) и иерархический (DOM). Есть также и парсеры со своим интерфейсом. Размер jar-а с парсером может варьироваться от нескольких килобайт до мегабайта - в зависимости от поддерживаемых интерфейсов и возможностей.

Для XML также написано несколько библиотек для универсального сохранения (сериализации) объектов в файлах XML. Такие библиотеки позволяют отделить алгоритм сохранения от самого объекта, а это, как уже упоминалось, имеет много плюсов.

Сериализация.

Под термином "сериализация" понимают запись содержимого объекта в поток двоичных данных. Обычно имеется в виду универсальный алгоритм, реализуемый классами java.io.ObjectOutputStream и java.io.ObjectInputStream . Пользоваться ими просто настолько, насколько это вообще возможно - обычно достаточно лишь отметить в классе поддержку при помощи интерфейса Serializable и отметить ключевым словом transient те поля объекта, которые сохранять не нужно. Собсно и всё. :-) Пример:

public class SerialObject implements java.io.Serializable { private String name; private transient int state; public SerialObject() {} public SerialObject(String n) { name = n; } public String getName() { return name; } public void setState(int s) { state = s; } }
Запись объектов:
SerialObject o = ...; OutputStream os = ...; ObjectOutputStream oos = new ObjectOutputStream(os); oos.writeObject(o);
Чтение объектов:
InputStream is = ...; ObjectInputStream ois = new ObjectInputStream(is); SerialObject o = (SerialObject)ois.readObject();
Использование сериализации - это один из самых простых вариантов по реализации, но и у него есть свои недостатки. Получаемые файлы являются двоичными, а значит в текстовом редакторе их уже не подправить - придётся делать редактирование параметров из программы. Кроме того, необходимо следить за изменением сохраняемых объектов, дабы не нарушить совместимость при изменении и развитии программы.

Базы данных.

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

  • Настройки связаны весьма сложным образом и древовидные структуры типа XML подходят плохо.
  • Доступ к настройкам должен быть только у авторизованых пользователей.
  • Доступ к этим данным должен быть и из других программ, например из генератора отчётов типа Crystal Reports.
БД могут применятся объектные или реляционные. Другие типы сейчас широкого распространения не имеют. Использовать хорошую объектную БД часто так же просто, как и сериализацию. Для реляционых баз можно применить объектную надстройку, которая также позволяет сильно упростить жизнь. Ну а можно делать обычные SELECT-ы.

Скрипты.

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

Но часто без скриптов действительно тяжело. Типичные примеры - алгоритмы импорта/экспорта, алгоритмы проверок данных. Вы можете подготовить стандартный набор, а дальше настраивать скриптами под конкретные требования заказчика.

Для программ на Java в качестве скрипт-языка хорошо использовать язык Pyton в его Java-инкарнации под названием JPyton. Там легко организовать двусторонюю связь между программой и скриптом. Если не будет хватать скорости интерпретации, то код на Pyton-е можно скомпилировать в байт-код - получится обычный Java-класс. Про JPyton можно почитать на сайте http://www.jpyton.org/ или в новой книжке Брюса Эккеля Thinking In Patterns with Java (доступна на http://www.bruceeckel.com/).

Пример программы с конфигурацией в XML.

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

Пример содержимого конфигурационного файла:

Просто строчка Вторая строчка

В качестве XML-парсера используется Sun-овский парсер в режиме DOM. На таком простом примере не видно особых преимуществ формата XML над теми же файлами properties. Они становятся заметны только в достаточно сложных программах, где становится необходимо хранить списки однотипных параметров или же содержимое объектов с уровнем вложенности два или более.

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

5. Универсальные и специализированные инструментальные среды. В чем разница между универсальными и специализированными ИС?

(при желании сократить)

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

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

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



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

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

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

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



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

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

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

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

  • интегрированность по пользовательскому интерфейсу,
  • интегрированность по данным,
  • интегрированность по действиям (функциям),

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

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

СО старой шпоры: (Инструментальные средства: -универсальный и не универсальный для программирования определенного класса контроля в целом. Пример: IsaGRAF и ултра логик. Как правило такие среды имеют стройные редакторы нескольких языков стандартов возможность выгр.готовый вход приложения ПЛК. Конфигурировать оборудования управлять целевой задачей. Недостатки: необходимость загрузки на конроллер доп.рпрог.обеспечение в рамках который вып.ся целевая задача. Специолизированный предназна для прог.конкретной конроллеров классоконтр.пример: лого или степ 7. Отличается от универсальной строго привязкой. Возможности таких сред шире или универсальных и могут включать адменистрированной сети.)

6. Что такое модули расширения при аппаратном конфигурировании ПЛК на примере ПЛК фирмы SIEMENS

Соглашения языка ST < boolean_expression > Соглашения языка LD Соглашения языка IL <инструкция><инструкция> <>

Projects : Управление проектомLibraries : Управление библиотекойBook : Справочная система ISaGRAFDiagnosis Read Me Report

Нижний Средний Верхний

7. Варианты порядка создания проекта в инструментальной среде Step 7

Начнем работу со средой, щелкнув на пиктограмму «SIMATIC Manager» на Рабочем столе ПК, либо, выбрав пункты меню ПУСК\SIMATIC\SIMATIC Manager.В среде Step7 существует два способа создания проекта: ---при помощи мастера создания проектов «STEP 7 Wizard»;--в ручном режиме.Первый способ – это создание проекта при помощи мастера. При запуске программы, первое загружаемое окно, называется «STEP 7 Wizard», в нем предлагается создать проект посредством нескольких простых действий. Если же у нас уже имеется готовый проект, то данное окно необходимо закрыть и воспользоваться меню Fail\Open.Создадим новый проект, для этого в окне Wizard нажмем кнопку «Next». Дальнейшим действием программа предлагает выбрать, из списка тип CPU который будет использоваться в проекте. Модуль центрального процессора «Мозг» машины, выполняет все вычислительные процессы, связанные с обработкой событий автоматизируемого технологического процесса или объекта. Из широкого спектра предложенных в списке модулей необходимо выбрать тот, который наиболее экономично и полно соответствует требованиям, предъявляемым к автоматизации ТП. Характеристики модулей приведены в этом же окне. Необходимо помнить, что выбранное оборудование должно строго соответствовать физическим устройствам, для которых разрабатывается ПО.Выберем контроллер SIMATIC 300\CPU-300\CPU-313C\6ES7-313-5BE01-0AB0. Адрес сети MPI, предлагаемый по умолчанию программой – 2. Это обусловлено тем, что первый адрес всегда резервируется для машины, чаще всего ПК, которая выступает в качестве рабочей станции для конфигурирования, настройки, программирования и управления ПЛК подключенных к сети. Каждому новому ПЛК подключаемому к сети, должен быть присвоен уникальный индивидуальный адрес. Оставим адрес без изменения. Щелкнем кнопку «Next».В предложенном окне программа предлагает уточнить метод выполнения программы, путем установки соответствующей галочки напротив обозначения функционального модуля. Оставим галочку на модуле ОВ1, что позволит работать программе по циклу, с опросом входов и перезаписью выходов с каждым исполненным циклом.Ниже выберем язык, используемый для создания логики проекта. Step 7 поддерживает три языка стандарта IEC1131-3 FBD, LD, STL. Для нашего проекта выберем любой из языков, к примеруFBD. Щелкнем кнопку «Next».В соответствующем поле введем имя проекта, к примеру «MineProject». Щелкнем кнопку «Finish», работу мастера по созданию проекта можно считать завершенной.Для создания нового проекта в ручном режиме нужно в меню File выбрать пункт New. На экране появится диалоговое окноВ данном окне указываются имя проекта и его размещение. Далее в меню Insert необходимо выбрать пункт рабочей станции, к примеруStation\SIMATIC 300 Station. Для конфигурации оборудования выберем станцию SIMATIC 300(1) и дважды щелкнем на иконке Hardware. Это позволит войти в окно программного конфигурирования оборудования.

8. Действия внутри переходов языка SFC ISaGRAF, соглашения, примеры К каждому переходу может присоединяться логическое выражение, кото-рое является условием прохождения этого перехода. Условие обычно записы-вается на языке ST или LD. Это Уровень 2 перехода. Однако могут быть ис-пользованы и другие структуры: --оглашения языка ST; --Соглашения языка LD; --Соглашения языка IL; --Вызовы функций из переходов. Если к переходу не присоединено выражение, то по умолчанию условие - TRUE.Соглашения языка ST Язык ST можно использовать для описания условий, присоединенных к переходам. Выражение должно иметь логический тип и заканчиваться точкой с запятой: < boolean_expression > ; Выражение может быть константой TRUE или FALSE, входом или внут-ренней логической переменной, или комбинацией переменных, которые дают логическое значение. Соглашения языка LD Язык Релейных Диаграмм (LD) можно использовать для описания усло-вий, присоединенных к переходам. Диаграмма состоит из штанги с витком. Значение витка представляет значение переходаСоглашения языка IL Язык Список Инструкций (IL) можно использовать для описания SFC пе-реходов, согласно следующему синтаксису: #info=IL <инструкция><инструкция> .... #endinfo Значение, которое содержит текущий результат (IL регистр) в конце IL последовательности, будет являться условием присоединенным к переходу: result = 0 условие перехода – FALSE; result <> 0 условие перехода – TRUE. Специальные ключевые слова #info=IL и #endinfo должны быть введены именно так, прописными буквами. До или после ключевых слов нельзя вво-дить пробелы и символы табуляции.

9. Действия внутри шагов языка SFC ISaGRAF, соглашения, примеры Уровень 2 шага SFC представляет собой детальное описание действий в период активности шага. Это описание может использовать текстовые допол-нения языка SFC, структурный текст ST, язык инструкций IL. Основные типы действий: булевские действия; импульсные действия; не сохраняемые действия; действия SFC. В одном шаге могут быть описаны несколько действий одинаковых или разных типов (см. АСУ водоотливной установкой шаг номер 2). Использова-ние любого языка возможно посредством вызова подпрограм, функций или функциональных блоков, написанных на любом языке, включая С. Это можно реализовать с помощью языков ST или IL.

10. Из каких рабочих окон состоит среда IsaGRAF? Их назначение и краткое описание. Вот главные пиктограммы ISaGRAF:Projects : Управление проектомLibraries : Управление библиотекойBook : Справочная система ISaGRAFDiagnosis : Система диагностики для пользователяRead Me : Информация о новой версии ISaGRAFReport : Стандартный отчёт об ошибках

11. Из каких технических средств состоит нижний уровень иерархической си­стемы дистанционного контроля и управления? Из каких технических средств состоит нижний уровень иерархической си­стемы дистанционного контроля и управления?Нижний уровень. Здесь выполняются функции по сбору, обработке, приему и передаче информации, функции локального управления технологиче-ским процессом, максимально приближенного к реальному времени. Уровень включает в себя следующие группы устройств:1.1. Датчики – выполняют нормированное преобразование физических ве-личин (как электрических, так и не электрических) в электрические. Выбор параметров и типа датчика определяются требованиями техно-логического процесса, а также возможностями проектируемой системы управления (здесь прежде всего определяют диапазоны измеряемых сигналов, их быстродействие, форматы получаемых электрических сигналов). 1.2. Исполнительные устройства (ИУ) – выполняют управляемое преобра-зование энергии источника питания в энергию необходимую для реа-лизации конкретной технологической операции. Энергия источника питания как правило электрическая, а энергия используемая для пере-мещения регулирующего органа – механическая. В таком случае ИУ – это электромеханический преобразователь. ИУ предусматривает воз-можность управления процессом преобразования энергии, для чего ис-пользуются управляемые преобразователи амплитуды, частоты, фазы электрической энергии источника (чаще всего, релейные или тири-сторные). 1.3. Управляемые преобразователи (УП) – устройства различной сложно-сти, обеспечивающие возможность изменения характеристик переда-ваемой исполнительным элементом энергии, проще говоря, регули-рующие выходной параметр исполнительного элемента (например ско-рость двигателя). Вид энергии зависит от типа ИУ и от места установ-ки УП – до или после ИУ по отношению к потоку энергии. К устройст-вам устанавливаемым до ИУ относятся тиристорные преобразователи, Входными параметрами УП может быть как один сигнал, так и совокуп-ность сигналов. Которые на выходе УП приобретают форму необходимую для регулирования ИУ. 1.4. Нормализаторы сигналов и согласующие устройства – выполняют пре-образование немасштабированного электрического сигнала некоторой формы, в нормированный унифицированный электрический сигнал и наоборот, кроме того могут обеспечивать гальваническую развязку. Как правило, датчик (собственно чувствительный элемент датчика) выдает ненормированный сигнал малой мощности, помехонезащищен-ный, что требует в соответствии с нормами международных стандартов приведения сигнала в некий унифицированный формат. Формат этот зависит от организации сети связи технических систем на соответст-вующем уровне АСУП. 1.5. Контроллеры – обеспечивают заданную последовательность работы, взаимодействие технологического оборудования. Это может выражать-ся в виде инициации процессов пуска и торможения двигателей, стаби-лизации и слежения за технологическими параметрами, простейшего анализа аварийных ситуаций и др. Наличие тех или иных функций мо-жет варьироваться в зависимости от сложности технологического про-цесса, типа контроллера и его места в иерархической АСУП. Контрол-лер может как включать функции связи с верхними уровнями системы автоматизации, так и работать автономно без связи с верхним уровнем АСУП.

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

Нижний уровень. Здесь выполняются функции по сбору, обработке, приему и передаче информации, функции локального управления технологиче-ским процессом, максимально приближенного к реальному времени. Средний уровень (микро-SCADA – Supervisory control and data acquisition – система диспетчерского контроля и сбора данных) . Этот уровень также можно назвать цеховым. Он выполняет функции сбора, обработки сигналов агрегата (цеха), передачу управляющих воздействий общего ха-рактера (переключение режимов работы оборудования, изменение мощ-ности и др.). Кроме традиционных функций, в последнее время наблю-даются тенденции внедрения подсистем прогнозирования аварийных си-туаций технологической линии. Понятно, что этот уровень целесообразно включать при разделении предприятия на цеха, в более простом варианте его внедрение не будет оправдано. Локальная станция цехового уровня обеспечивает интерфейс (взаимодействие) между диспетчером-оператором цеха и технологическим процессом, а также связь с верхним уровнем. Верхний уровень супервизорного контроля и управления (операторские станции SCADA, расчетные станции). Предназначен для отображения и обработки данных, формирования баз данных, посылки управляющих сигналов на нижние уровни системы, конфигурирования системы, проверки данных на достоверность, обеспечения поддержки выполнения ра-бот, связанных с поверкой измерительных каналов и другие работы.

Организационные блоки в инструментальной среде Step 7. Их разновидности, назначение и порядок запуска Организационные блоки образуют интерфейс между операционной системойCPU и программой пользователя. В организационных блоках определяется последовательность обработки программы пользователя. OB используются для исполненияопределенных разделов программы:o при запуске CPUo при циклическом или зависящем от времени исполнении программыo при возникновении ошибокo при возникновении аппаратных прерываний.Организационные блоки исполняются в соответствии с присвоенными им приоритетами. Организационный блок циклического выполнения программы (OB1)Операционная система CPU S7 исполняет OB1 непрерывно. Когда OB1 исполнен, операционная система начинает его обработку вновь. Циклическая обработка OB начинается по окончании стадии запуска. Вы можете вызывать в OB1 функциональные блоки (FB, SFB) или функции (FC, SFC).Принцип действия OB1OB1 имеет самый низкий приоритет среди всех OB, время выполнения которых контролируется, иными словами, все остальные OB, кроме OB90, могут прерывать выполнение OB1. Операционная система вызывает OB1 при следующих событиях:o Завершение запуска.o Конец обработки OB 1 (предыдущего цикла).Организационные блоки прерываний по времени (OB10 ? OB17)STEP 7 предоставляет в распоряжение до восьми прерываний по времени (OB 10 - OB 17), которые могут запускаться однократно или периодически. Вы можете так параметрировать Ваше CPU при помощи SFC или STEP 7, что эти OB будут обрабатываться со следующими интервалами:o Однократноo Ежеминутноo Ежечасноo Ежедневноo Еженедельноo Ежемесячноo В конце каждого месяцаПринцип действия OB прерываний по времениЧтобы запустить прерывание по времени, его необходимо вначале установить, а потом активировать. Существует три следующих способа запуска:Организационные блоки прерываний с задержкой(OB20 ? OB23)S7 предоставляет в распоряжение до четырех OB (OB 20 ? OB 23), которые исполняются после заданной задержки. Каждый OB прерывания с задержкой запускается посредством вызова SFC32 (SRT_DINT). Время задержки является входным параметром SFC.Когда Ваша программа вызывает функцию SFC32 (SRT_DINT), то ей передается номер OB, время задержки и индивидуальный код пользователя.Принцип действия OB прерываний с задержкойПо истечении времени задержки (его значение в миллисекундах передается блоку SFC32 вместе с номером OB) операционная система запускает соответствующий.Организационные блоки циклических прерываний(OB30 ? OB38)S7 представляет в распоряжение до девяти OB циклических прерываний (OB 30 ? OB38), которые прерывают Вашу программу через фиксированные интервалы времени. Следующая таблица показывает установленные по умолчанию интервалы времени и классы приоритета для OB циклических прерываний.Принцип действия OB циклических прерыванийЭквидистантные моменты запуска OB циклических прерываний определяются интервалом и фазовым сдвигом. Как связаны друг с другом момент запуска, периодичность и фазовый сдвиг, описано в /234/.OB ошибок резервирования CPU (OB72)Операционная система H CPU вызывает OB72, когда происходит одно из следующих событий:o Потеря резервирования CPUo Переключение на резервное ведущее устройствоo Ошибка синхронизацииo Ошибка в модуле синхронизацииo Прерывание обновленияo Ошибка сравнения (например, RAM, PIQ)OB72 выполняется всеми CPU, которые находятся в режиме RUN или STARTUP, после соответствующего стартового события.блок ошибок времени (OB80)Операционная система CPU S7-300 вызывает OB80, когда при обработке какого-либо OB возникает одна из следующих ошибок: превышение времени цикла, ошибка квитирования при исполнении OB, перевод часов вперед, так что пропускается время запуска OB. Если, например, стартовое событие для OB циклических прерываний возникает до того, как была закончена обработка предыдущего вызова, то операционная система вызывает OB80.

Если OB 80 не был запрограммирован, то CPU переходит в состояние STOP.

ОВ ошибок времени можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Примечание

Если OB 80 в одном и том же цикле вызывается дважды из-за превышения времени цикла, то CPU переходит в состояние STOP. Вы можете этому воспрепятствовать вызовом SFC43 .RE_TRIGR. в подходящей точке программы.

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

питания (OB81)

Описание

Операционная система CPU S7-300 вызывает OB81, когда происходит событие, вызванное ошибкой или сбоем, связанным с источником питания (только для S7-400) или буферной батареей (при наступающем и при уходящем событии).

В отличие от ОВ для других асинхронных ошибок CPU в данном случае не переходит в режим STOP, если OB 81 не был запрограммирован.

OB неисправностей источника питания можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Организационный блок диагностических прерываний

Описание

Если модуль, обладающий диагностическими свойствами, которому Вы разрешили диагностические прерывания, распознает ошибку, он выдает на CPU запрос на диагностическое прерывание (как при наступающем, так и при уходящем событии). Затем операционная система вызывает OB82.

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

Если OB 82 не был запрограммирован, то CPU переходит в состояние STOP.

OB диагностических прерываний можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Организационный блок снятия/установки модулей

Описание

Установка и снятие модулей контролируется внутри системы каждую секунду.

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

Каждая установка или снятие сконфигурированного модуля в режимах RUN, STOP и STARTUP (не разрешено удаление в этих режимах для блоков питания, CPU, адаптерных модулей и IM) приводит к прерыванию снятия/установки. Это прерывание вызывает у соответствующего CPU запись в диагностический буфер и в список состояний системы. Кроме того, в режиме RUN осуществляется запуск OB снятия/установки. Если этот OB не был запрограммирован, то CPU переходит в состояние STOP.

OB снятия/установки можно запретить или отложить и вновь разрешить с помощью SFC 39 ? 42.

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, разновидности CPU) Simatic S7-300 - семейство контроллеров средней производительности фирмы Siemens AG из семейства устройств автоматизации Simatic S7. В линейке контроллеров этого семейства по своей производительности занимает промежуточное положение между семействами S7-200 и S7-400. Количество поддерживаемых входов и выходов до 65536 дискретных/4096 аналоговых каналов. Конструкция контроллера модульная, модули монтируются на профильной шине (рельсе).

естественное охлаждение;

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, память, ее виды) Simatic S7-300 - семейство контроллеров средней производительности фирмы Siemens AG из семейства устройств автоматизации Simatic S7. В линейке контроллеров этого семейства по своей производительности занимает промежуточное положение между семействами S7-200 и S7-400. Количество поддерживаемых входов и выходов до 65536 дискретных/4096 аналоговых каналов. Конструкция контроллера модульная, модули монтируются на профильной шине (рельсе).

Simatic S7-300 - программируемый контроллер, предназначенный для построения систем автоматизации низкой и средней степени сложности. Основные особенности контроллера:

модульная конструкция, монтаж модулей на профильной шине (рельсе);

естественное охлаждение;

применение локального и распределенного ввода -вывода;

возможности коммуникаций по сетям MPI, Profibus Industrial Ethernet/PROFInet, AS-i, BACnet, MODBUS TCP;

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

поддержка на уровне операционной системы аппаратных прерываний;

поддержка на уровне операционной системы обработки аппаратных и программных ошибок;

Свободное наращивание возможностей при модернизации системы;

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

Основные технические характеристики ПЛК фирмы SIEMENS линейки SIMATIC S7-300 (строение, интерфейсы взаимодействия) o Модульный программируемый контроллер для решения задач автоматизации низкого и среднего уровня сложности.

o Широкий спектр модулей для максимальной адаптации к требованиям решаемой задачи.

o Использование распределенных структур ввода-вывода и простое включение в сетевые конфигурации.

o Удобная конструкция и работа с естественным охлаждением.

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

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

Программируемые контроллеры SIMATIC S7-300 имеют:

o сертификат соответствия и метрологический сертификат Госстандарта России;

o разрешение на применение федеральной службы по экологическому, технологическому и атомному надзору

o свидетельство Главного Управления Государственного Энергетического Надзора о взрывозащите IIC модулей SIMATIC S7 Ex исполнения;

o экспертное заключение о соответствии функциональных показателей интегрированной системы автоматизации SIMATIC S7 отраслевым требованиям и условиям эксплуатации энергопредприятий РАО "ЕЭС России";

o сертификат о типовом одобрении Российского Морского Регистра Судоходства.

o морские сертификаты ABS, BV, DNV, GLS, LRS, PRS, RINA;

o cертификаты DIN, UL, CSA, FM, CE;

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

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

Конструктивные особенности

Программируемые контроллеры S7-300 могут включать в свой состав:

o Модуль центрального процессора (CPU). В зависимости от степени сложности решаемых задач в программируемом контроллере могут использоваться более 20 типов центральных процессоров.

o Блоки питания (PS) для питания контроллера от сети переменного или постоянного тока.

o Сигнальные модули (SM), предназначенные для ввода и вывода дискретных и аналоговых сигналов, в том числе FailSafe и модули со встроенными Ex-барьерами. Поддерживаются отечественные ГОСТ градуировки термометров сопротивления и термопар.

o Коммуникационные процессоры (CP) - интеллектуальные модули, выполняющие автономную обработку коммуникационных задач в промышленных сетях AS-Interface, PROFIBUS, Industrial Ethernet, PROFINET и системах PtP связи. Применение загружаемых драйверов для CP 341 позволяет расширить коммуникационные возможности контроллера поддержкой обмена данными в сетях MODBUS RTU и Data Highway. Для организации модемной связи в составе S7-300 могут использоваться коммуникационные модули семейства SINAUT ST7.

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

o Интерфейсные модули (IM) для подключения стоек расширения к базовому блоку контроллера, что позволяет использовать в системе локального ввода-вывода до 32 модулей различного назначения. Модули IM 365 позволяют создавать 2-, модули IM 360 и IM 361 - 2-, 3- и 4-рядные конфигурации.

3.Типовой набор встроенных технологических функций позволяет решать задачи скоростного счета, измерения частоты или длительности периода, ПИД-регулирования, позиционирования, перевода части дискретных выходов в импульсный режим. Все центральные процессоры S7-300 оснащены встроенным интерфейсом MPI, который используется для программирования, диагностики и построения простейших сетевых структур. В CPU 317 первый встроенный интерфейс имеет двойное назначение и может использоваться для подключения либо к сети MPI, либо к сети PROFIBUS DP.

Целый ряд центральных процессоров имеет второй встроенный интерфейс:

o CPU 31…-2 DP имеют интерфейс ведущего/ ведомого устройства PROFIBUS DP;

o CPU 31…C-2 PtP имеют интерфейс для организации PtP связи;

o CPU 31…-… PN/DP оснащены интерфейсом Industrial Ethernet, обеспечивающим поддержку стандарта PROFInet;

o CPU 31…T-2 DP оснащены интерфейсом PROFIBUS DP/Drive, предназначенным для обмена данными и синхронизации работы преобразователей частоты, выполняющих функции ведомых DP устройств.

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

o Логические операции, операции сдвига, вращения, дополнения, операции сравнения, преобразования типов данных, операции с таймерами и счетчиками.

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

o Операции загрузки, сохранения и перемещения данных, операции переходов, вызова блоков, и другие операции.

Для программирования и конфигурирования S7-300 используется пакет STEP 7.

Кроме того, для программирования контроллеров S7-300 может использоваться также весь набор программного обеспечения Runtime, а также широкий спектр инструментальных средств проектирования.

Основными техническими требованиями при проектировании распределенных АСУ ТП Основными техническими требованиями при проектировании распреде-ленных АСУ ТП являются:

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

беспечение аппаратного и программного аварийного останова техно-логического комплекса при аварийных ситуациях;

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

беспечение высокоэффективного ЧМИ в системе визуализации и мо-ниторинга;

эффективная, с точки зрения скорости обнаружения неисправности, и надежная диагностика программно-аппаратных средств;

распределенная система электропитания;

обеспечение обмена данными по информационным каналом в реальном масштабе времени;

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

обеспечение широкого температурного диапазона работы техниче-ских средств локальных систем автоматического управления (САУ);

выбор оптимального, с точки зрения пылевлагонепроницаемости, а также защиты от электромагнитного излучения, коррозии и др. факто-ров, удовлетворяющего международным стандартам конструктива шкафа цехового контроллера, шкафов автоматики локальных САУ и автоматизированного рабочего места системного инженера (АРМ);

обеспечение надежного контура заземлений на каждой отдельной площадке объекта автоматизации;

защита контрольно-измерительных и информационных каналов от внешних воздействий, а также усиление передаваемых сигналов;

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

Особенности языка FBD. Его достоинства и недостатки. Особенности редактора FBD:

" Графическое представление функционального плана хорошо отражает процесс выполнения программы.

" Редактор FBD можно использовать и с системой команд SIMATIC, и с системой команд МЭК 1131-3.

" Для отображения программы, созданной при помощи редактора SIMATIC FBD, всегда можно использовать редактор STL.

Язык FBD (Functional Block Diagram, Диаграмма Функциональных Блоков) является языком графического программирования, так же, как и LD, использующий аналогию с электрической (электронной) схемой. Программа на языке FBD представляет собой совокупность функциональных блоков (functional flocks, FBs), входа и выхода которых соединены линиями связи (connections). Эти связи, соединяющие выхода одних блоков с входами других, являются по сути дела переменными программы и служат для пересылки данных между блоками. Каждый блок представляет собой математическую операцию (сложение, умножение, триггер, логическое "или" и т.д.) и может иметь, в общем случае, произвольное количество входов и выходов. Начальные значения переменных задаются с помощью специальных блоков - входов или констант, выходные цепи могут быть связаны либо с физическими выходами контроллера, либо с глобальными переменными программы. Пример фрагмента программы на языке FBD приведен на рис. 2.

Практика показывает, что FBD является наиболее распространенным языком стандарта IEC. Графическая форма представления алгоритма, простота в использовании, повторное использование функциональных диаграмм и библиотеки функциональных блоков делают язык FBD незаменимым при разработке программного обеспечения ПЛК. Вместе с тем, нельзя не заметить и некоторые недостатки FBD. Хотя FBD обеспечивает легкое представление функций обработки как "непрерывных" сигналов, в частности, функций регулирования, так и логических функций, в нем неудобным и неочевидным образом реализуются те участки программы, которые было бы удобно представить в виде конечного автомата.

Прикладное программное обеспечение систем управления (6)

7. Особенности языка IL. Его достоинства и недостатки.

Список инструкций или IL - это язык низкого уровня. Инструкции всегда относятся к текущему результату (или IL регистру).

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

IL программа - это список инструкций. Каждая инструкция должна начи-наться с новой строки и должна содержать оператор, с дополнительным моди-фикаторами, если нужно, для специфических операций, один или несколько операндов, разделенных запятой (,). Инструкции может предшествовать метка с двоеточием (:). Если к инструкции присоединен комментарий, то он должен находиться в конце строки. Комментарий всегда начинается с (* и заканчива-ется *). Между инструкциями может быть введена пустая строка.

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

Хорошо, если вы знаете свою конфигурацию назубок. А если нет? Тогда для сбора информации о конфигурации компьютера требуется пара минут и минимум усилий. Ниже я рассакжу о том, как это сделать средствами ОС Windows или сторонними программами, умеющими создавать отчет, который можно опубликовать на форуме.

Сведения о системе (msinfo32)

Как это ни тривиально звучит, но сведения об аппаратной конфигурации компьютера можно собрать, не устанавливая сторонние программы. В состав ОС Windows входит утилита Сведения о системе , которая обладает возможностью экспорта собранных данных в текстовый файл. Запустить программу можно из меню Пуск — Программы — Стандартные — Служебные или из окна Пуск — Выполнить (или поля Поиск в Vista), введя msinfo32 и нажав ОК .

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

В Windows XP и Vista того же результата можно достичь из командной строки, выполнив команду

Msinfo32 /report "<путь к папке>\config.txt"

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

Программы сторонних разработчиков

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

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

Winaudit

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

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

System Information for Windows (SIW)

Программа SIW имеет размер около 2.2 Мб, не требует установки (правда, без установщика предлагается только английская версия), обладает продуманным интерфейсом, да и наглядность выводимой ею информации заслуживает очень высокой оценки. В многоязычной версии русский язык интерфейса при необходимости можно задать в окне Tools -> Options . Нас, однако, интересует создание отчета, эта опция есть в меню Файл , как показано на рисунке ниже.