Samara Portal Technology, Computers

Самарский портал "Технологии, компьютеры"

  1. Предлагаемое понятие САПР

Всем известно, что результат разработки САПР - это когда машина делает работу за конструктора. Понятно также, что работа эта заключается не только в том, что машина чертит или пишет (печатает), но к "думает”, т.е. производит какие-то логические операции. Ясно также, что машина делает за конструктора не всю его работу, а лишь часть, так как даже там, где есть САПР, конструкторы всё же остались. Дальше те, кто САПРом непосредственно не занимаются, как правило не задумываются, подсознательно считая что САПР - это что-то очень специальное, связанное только с электроникой и программированием, и требующие только умения работать на машине и самой машины.

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

И ещё в 1948 году отец кибернетики Норберт Винер на вопрос о причинах низкой эффективности использования ЭВМ, ответил «потому что нужен разум, чтобы знать, что давать машине». (рукописная вставка)

  1. Формализация процесса проектирования.

Существуют определения ГОСТ для стадий разработки. Не вступая в противоречие с определениями ГОСТ, укрупнённо работу конструк­тора можно поделить на три категории:

  • Поиск технического решения.

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

  • Разработка узлов и систем изделия.

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

  • Увязка различных узлов и систем изделия.

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

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

  • Ограничения, накладываемые ЕСКД в оформлении документации.
  • Ограничения применяемости.
  • Технологические ограничения.
  • Ограничения скорости внедрения.
  • Экономические ограничения, которые конструктор пока не чувствует, но с переходом на новый порядок хозяйствования обязан будет выполнять.

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

Иными словами, при разработке САПР кроме увязки частой проекта внутри ОГК возникает проблема конкретизации требований служб завода и их непротиворечивости. Это означает, что разработ­чики алгоритмов САПР должны иметь четкие требования служб, т.е. к разработке САПР в какой-то мере должны быть подключены все службы завода, иначе выигрыш в скорости, достигнутый за счет машин­ной обработки данных и авточерчения будет не только сведен на нет дальнейшими согласованиями и изменениями, но и обратится в проигрыш, так как изменения в программах и алгоритмах делать намного сложнее, чем в конкретных конструкторских документах.

----

Комбридж: ИТ по-грузински в Самаре

Комбридж: ИТ по-грузински в Самаре. Статья Владислава Боярова. 03.08.2019 г.

Манго Телеком: команда «Голос!»

Cisco: по главной улице с оркестром

Cisco: по главной улице с оркестром. Статья Владислава Боярова. 21.07.2019 г.