Проектирование электротехнических изделий. Особенности по сравнению с проектированием электронных узлов. Основные возможности компьютерной поддержки.
Компьютерная поддержка проектирования сильноточных электротехнических изделий (станций управления) в течение долгого времени касалась только разработки принципиальных схем. В современных программных продуктах это, разумеется, есть, но дополнено многими важными функциями. К примеру, при разработке релейно-контактных схем автоматически учитываются задействованные и свободные контакты аппаратов, формировать ссылки на контакты – при разработке сложных схем это очень существенно облегчает жизнь. Кроме того, эффективно решаются многие другие специфические вопросы: ▪ формирование собственных баз данных по номенклатуре электротехнических изделий, используемой на предприятии; ▪ быстрый выбор необходимого элемента из баз данных производителей, доступных через Интернет или отдельно поставляемых (странно то, что базы данных зарубежных производителей предоставляются бесплатно, а полный каталог отечественных электротехнических изделий стоит бешеных денег); ▪ эффективное формирование таблиц соединений, перечней элементов и спецификаций; ▪ существенное облегчение формирования многостраничных схем; ▪ формирование заказов оборудования. В области проектирования электронных устройств все начиналось с компьютерной поддержки создания схем: создания специализированных графических редакторов, средств создания библиотечных элементов и организации библиотек. То же было сделано и в области конструирования печатных узлов. Следующий естественный шаг - обеспечение переноса информации об электрических связях, содержащейся в принципиальной схеме, в конструкцию узла. (Должен заметить, что при выполнении этой совершенно рутинной операции при ручном проектировании возникает основная масса ошибок). Следующий шаг – компьютерная поддержка разработки топологии проводящего рисунка печатных плат – создание программ, которые называются автотрассировщиками. Параллельно решалась задача автоматического размещения компонентов на печатных платах. Два последних момента интересны тем, что результаты автоматической компоновки и трассировки отличаются от окончательных примерно так же, как подстрочник от настоящего литературного перевода, но основную массу черной работы все-таки удалось переложить на компьютер. Обратите внимание, что нет и намека на автоматическую разработку конфигурации детали или автоматическое создание принципиальной схемы. Очевидно, что эти задачи в значительной степени являются творческими, несмотря на огромное количество типовых решений, и алгоритмизация их практически невозможна, или, скажем мягче, нецелесообразна. Один из чрезвычайно важных моментов – это возможность использовать в качестве источника информации при разработке технологических процессов и программ для технологического оборудования с ЧПУ непосредственно первичный конструкторский документ. Последнее, кстати, является уже областью применения CAM-систем, хотя в области проектирования и производства печатных плат эта возможность была встроена во все CAD-системы с самого начала. Представление информации в виде компьютерных файлов позволяет организовать безбумажный документооборот и существенно сужает номенклатуру используемых документов, позволяет практически мгновенно пересылать их не только из одного подразделения в другое, но и вообще на край света. Дошло даже до работы над одним документом в режиме диалога двух разработчиков, находящихся на разных берегах океана. Правда, эти возможности порождают и некоторые проблемы. В частности, проблема ограничения доступа, проблема подписей, проблема контрольного экземпляра и неучтенных копий и т. п., но выигрыш велик, а проблемы не имеют стратегического характера и в конце концов будут решены, поскольку системы автоматизации документооборота существуют и развиваются.
14. Создание систем управления (АСУТП и АСУ): основные вопросы и структурные решения. Возможности компьютерной поддержки. Господствующая сегодня технология создания автоматизированных систем управления такова: ▪ специалист, знающий тонкости реализуемой технологии, разрабатывает алгоритм работы системы (обычно –словесное описание); ▪ по результатам анализа задачи (числа и характера информационных объектов – датчиков и исполнительных устройств, их удаленности, требуемых динамических характеристик, требований к пользовательскому интерфейсу, к протоколированию хода процесса и различного рода тревог и т.п.), а также по экономическим соображениям инженер-системотехник разрабатывает структурную схему системы, оцениваются потребные вычислительные ресурсы; ▪ выбирается или разрабатывается аппаратура: контроллер или промышленный компьютер, устройства связи с объектом; ▪ разрабатывается и отлаживается программное обеспечение С первой, второй и даже третьей задачами вполне может справиться специалист по автоматизации – штатный сотрудник предприятия. Ключевой момент здесь – четвертая задача, разработка ПО. Для этого во-первых, требуется программист. Если задачи подобного рода на предприятии не являются каждодневной работой (а чаще всего так и бывает), то программист – человек со стороны, тонкости технологии ему надо объяснять. Во-вторых, насколько бы хорошо ни было продумано ТЗ, неминуемо всплывут неучтенные нюансы, в особенности если процесс автоматизируется впервые. Нюансы всплывают порой неожиданно, а влезть в программу и внести коррективы практически может только сам разработчик, который в это время может быть занят другой работой или вообще откажется от дальнейшего сотрудничества. Так же обстоит дело и с внесением модификаций. В подобных ситуациях неминуемо возникают напряженность в отношении с клиентом, экономические потери и другие неприятности. В то же время такая ситуация вовсе не является неизбежной. Если системотехнические вопросы можно решить своими силами, то остается дать технологу в руки инструмент, позволяющий изложить свои требования на языке, содержащем описание необходимых логических связок. Кроме того, в его распоряжение очень желательно предоставить средства разработки пользовательского интерфейса – рабочих экранов. Это, по сути, специализированный графический редактор и библиотеки изображений типовых элементов систем. Таким образом, практически отпадает необходимость в создании ПО в традиционном смысле: надо просто изложить исходные требования немного другими средствами. В этом случае привлечение сторонних или содержание своих программистов перестает быть необходимым: исчезает промежуточное звено, скорость разработки существенно повышается, качество – тоже. Программные продукты, реализующие эту идею, называются SCADA-системами (Supervisory Control and Data Acquisition system – система наблюдения, сбора данных и управления). Например, ТрейсМоут, Крус 2000, семейство ИНСАТ, Джинейзис, ИкроЛоджик
|