5. Требования к аису установлены госТом 24.104-85
Ввод в действие АСУ должен приводить к полезным технико-экономическим, социальным или другим результатам, например:
снижению численности управленческого персонала;
повышению качества функционирования объекта управления;
повышению качества управления и др.
АСУ должна быть обеспечена совместимость между ее частями, а также с автоматизированными системами (АС), взаимосвязанными с данной АСУ.
В случаях, когда АСУ или совокупность АСУ (АС) создана на базе вычислительной сети, для обеспечения совместимости между элементами такой сети должны быть применены системы протоколов многоуровневого взаимодействия.
1.1.6. АСУ в целом и все виды ее обеспечения должны быть приспособлены к модернизации, развитию и наращиванию в пределах требований, указанных в ТЗ на АСУ.
1.1.7. Надежность АСУ в целом и каждой ее автоматизированной функции должна быть достаточна для достижения установленных целей функционирования системы при заданных условиях применения.
1.1.8. Адаптивность АСУ должна быть достаточной для достижения установленных целей ее функционирования в заданном диапазоне изменений условий применения.
1.1.9. В АСУ должны быть предусмотрены контроль правильности выполнения автоматизируемых функций и диагностирование, с указанием места, вида и причины возникновения нарушений правильности функционирования АСУ.
1.1.10. В АСУ, имеющих измерительные каналы, должна быть предусмотрена возможность контроля метрологических характеристик измерительных каналов.
1.1.11. В АСУ должны быть предусмотрены меры защиты от неправильных действий персонала, приводящих к аварийному состоянию объекта или системы управления, от случайных изменений и разрушения информации и программ, а также от несанкционированного вмешательства.
1.1.12. Любая поступающая в АСУ информация вводится в систему однократно с помощью одного входного канала, если это не приводит к невыполнению требований, установленных в ТЗ на АСУ (по надежности, достоверности и т. п.).
1.1.13. Выходная информация одного и того же смыслового содержания должна быть сформирована в АСУ однократно, независимо от числа адресатов.
1.1.14. Информация, содержащаяся в базах данных АСУ, должна быть актуализирована в соответствии с периодичностью ее использования при выполнении функций системы.
АСУ в необходимых объемах должна автоматизированно выполнять:
сбор, обработку и анализ информации (сигналов, сообщений, документов и т. п.) о состоянии объекта управления;
выработку управляющих воздействий (программ, планов и т. п.);
передачу управляющих воздействий (сигналов, указаний, документов) на исполнение и ее контроль;
реализацию и контроль выполнения управляющих воздействий;
обмен информацией (документами, сообщениями и т. п.) с взаимосвязанными автоматизированными системами.
6. Метод IDEF0+DFD
SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования и ее подмножество стандарт IDEF0;
DFD (Data Flow Diagrams) – диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь»;
STD (State Transition Diagrams) – диаграммы переходов состояний.
7.
8. Одна из важнейших проблем, возникающих в АСУ ТП, при автоматизации измерений и в других областях, заключается в резком увеличении стоимости системы с ростом ее сложности. Объективная причина этого явления состоит в том, что сложные системы часто изготавливаются в единичных экземплярах, а это не позволяет сделать их дешевыми.
Распространенный метод решения указанной проблемы состоит в делении системы на модули таким образом, чтобы каждый из них становился коммерчески эффективным изделием и мог изготавливаться несколькими конкурирующими производителями в больших количествах. Однако при этом возникает проблема аппаратной и программной совместимости модулей. Для достижения совместимости интерфейс, конструктив и выполняемые функции таких модулей должны быть стандартизованы.
Открытой называется модульная система, которая допускает замену любого модуля на аналогичный модуль другого производителя, имеющийся в свободной продаже по конкурентоспособным ценам, а интеграция системы с другими системами (в том числе с пользователем) выполняется без преодоления чрезмерных проблем. Понятие открытости обсуждается на веб-сайтах OMAC (Open Modular Architecture Controls, www.omac.org), и в работах [Helei, Business - Wang].
Открытость можно рассматривать на разных уровнях иерархии программного и аппаратного обеспечения системы или ее составных частей. Открытыми, например, могут быть:
физические интерфейсы, протоколы обмена, методы контроля ошибок, системы адресации, форматы данных, типы организации сети, интерфейсы между программами, диапазоны изменения аналоговых сигналов;
пользовательские интерфейсы, языки программирования контроллеров, управляющие команды модулей ввода-вывода, языки управления базами данных, операционные системы, средства связи аппаратуры с программным обеспечением;
конструкционные элементы (шкафы, стойки, корпуса, разъемы, крепежные элементы);
системы, включающие в себя перечисленные выше элементы.
Под открытостью системы иногда понимают ее соответствие современным промышленным стандартам, которое обеспечивает возможность интеграции с другими открытыми системами [Lewis,Azevedo]. Однако понятие открытости нужно трактовать шире: оно должно подразумевать, что система не только удовлетворяет стандартам, но стандарт является общепризнанным, а в свободной продаже имеются аналогичные системы других производителей по конкурентоспособным ценам.
Как следует из определения, необходимыми условиями открытости являются:
модульность;
соответствие стандартам [Azevedo] (необязательно официальным, но обязательно общепринятым и легко доступным по цене, компенсирующей только затраты на его разработку, поддержку и распространение);
наличие в свободной продаже аналогичных систем других производителей (подсистем, модулей) по конкурентоспособным ценам.
Требование модульности вытекает из требования возможности замены части системы (т. е. модуля) аналогичными изделиями других производителей. Для этого система должна состоять из модулей.
Соответствие стандартам необходимо для обеспечения совместимости.
Наличие в свободной продаже и конкурентоспособность цен являются требованиями, вытекающими из практического аспекта: без выполнения этого условия открытая система может существовать только "на бумаге".
Понятие открытости достаточно многогранно и не стандартизовано. Поэтому практически можно говорить только о степени открытости системы, указывая, что именно понимается под открытостью в каждом конкретном случае. Степень открытости можно оценить количеством реализованных признаков открытости.
Для SCADA системы признаками открытости являются совместимость со стандартом ОРС [Iwanitz], совместимость с широко доступными компьютерами с различными операционными системами (желательно), совместимость с ActiveX, COM и DLL компонентами других производителей, поддержка языков стандарта МЭК 61131-3, наличие встроенного стандартного алгоритмического языка (например, Visual Basic) для реализации функций, которые невозможно реализовать другими средствами SCADA-пакета, возможность работы как с малым, так и большим количеством тегов без необходимости переобучения обслуживающего персонала, возможность применения веб-браузера в качестве пользовательского интерфейса для увеличения количества подключаемых рабочих станций, наличие пользовательского интерфейса, аналогичного интерфейсам других производителей, совместимость со стандартными базами данных и другими приложениями (например, Microsoft Office), расположенными на любых компьютерах сети.
Для промышленных сетей открытость означает наличие в свободной продаже сетевой аппаратуры от разных производителей по конкурентоспособным ценам, совместимой с открытыми стандартами.
Примером открытых систем являются системы, построенные на модулях и контроллерах RealLab!фирмы НИЛ АП (www.RealLab.ru), которые имеют стандартный протокол Modbus RTU или стандартный де-факто протокол DECON, стандартный интерфейс RS-485, стандартный конструктив (крепление на ДИН-рейку, разъемные клеммники), стандартные диапазоны аналоговых сигналов и стандартные уровни дискретных сигналов, стандартный OPC сервер, позволяющий использовать модули с любой стандартной SCADA. Любой модуль в такой системе может быть заменен на модули других производителей, которых в настоящее время насчитывается около десятка.
Идеальным примером открытой системы является современный офисный компьютер. Огромное число производителей в разных странах изготавливают множество аппаратных и программных компонентов, которые можно собрать в единую систему, заменить один компонент на другой, нарастить функциональные возможности. Любой компонент можно найти по достаточно низкой цене; отсутствуют производители, которые могли бы диктовать монопольные цены.
Понятие открытости не подразумевает открытость программного кода, как, например, в ОС Linux, хотя открытость кода позволяет добавлять в систему модули других производителей, что является признаком открытости. Однако открытость исходного кода существенно снижает надежность системы вследствие потенциальной возможности появления в ней дополнительных ошибок, внесенных во время модификации и компиляции. Поэтому открытость программного кода является спорным признаком открытости системы.
В отличие от открытых, закрытые системы разрабатываются по внутренним стандартам отдельных предприятий. Части (модули) закрытых систем не могут быть заменены аналогичными изделиями других производителей, а заказчик, однажды применив закрытую систему, навсегда оказывается привязанным к ее разработчику.