Cтраница 3
Проектирование технологических процессов является частью подготовки производства. В области автоматизации подготовки производства имеются два основных направления ( рис. 1): 1) создание цифровых систем для комплексной автоматизации основных процессов производства, включая конструирование изделия, технологическую подготовку и обработку деталей на станках с цифровым программным управлением; 2) разработка методов и средств технологического проектирования с выдачей документации для обслуживания станков с ручным управлением. [31]
Одним из основных модулей этой системы является модуль АСУ Сессия, основными задачами которого является обеспечить удобными средствами контроля за текущей и итоговой успеваемостью студентов факультеты и другие службы университета. Система наглядно информирует пользователя об успеваемости студентов, как текущей, так и итоговой, по результатам сдачи зачетов, курсовых работ и экзаменов. Система имеет модульное строение, что позволяет быстро настроить выдачу выходной документации согласно требованиям времени. [32]
Создание любого пакета предполагает создание и документации по этому пакету. Естественно, что в БСО должны содержаться компоненты, автоматизирующие накопление, изменение и выдачу нужной документации. Такая документация содержится в информационной части функционального наполнения и включает в себя как оперативную справочную информацию, доступную пользователю в диалоговом режиме, так и полную документацию по пакету, оформленному в соответствии с существующими ГОСТами. [33]
Структурные схемы микроЭВМ приведены на рис. 1.9, а, б и в. Зашитый в ПЗУ интерпретатор языка БЭЙСИК позволяет применять простые модели этой серии для решения инженерных задач без выдачи документации. Наличие интерфейсных разъемов расширяет систему за счет подключения дополнительной периферии или объединения ЭВМ в сеть. [34]
Ведение диалога с пользователем осуществляют блоки БД, УФС, БПД, используя ФС и БП. В системе предусмотрены три формы диалога: канцелярский ( типа вопрос системы - ответ пользователя), предназначенный для идентификации пользователя и его материалов в системе; формальный ( типа приказ пользователя - реакция системы), предназначенный для управления системой; формализующий ( типа гибкий вопрос системы, зависящий от ранее полученных ответов, - ответ пользователя и его формализация системой), предназначенный для получения системой новых знаний о ПАС. Ведение протокола диалога и его хранение в БП требуется для обеспечения возможности перерывов в работе пользователя и возможности выдачи документации после конца работы с системой. [35]
Многостадийноеть разработки конструкторской документации обусловлена сложностью создания новой техники, а также важностью исключения ошибок как при разработке технического решения конструкции, так и при отработке документов. Ошибка, допущенная на любой из стадий разработки изделия и особенно на первоначальной, может привести к значительным непроизводительным затратам еил, времени и средств. Необходимо помнить, что ошибка, сделанная конструктором, многократно дублируется при выпуске изделий. Исправить ошибку до выдачи документации на производство - значит в десятки раз сократить возможные потери. Вот почему важно наладить систему раннего обнаружения ошибок. Именно с этой целью каждая стадия разработки документации предусматривает многоэтапность работ с организацией контроля качества принимаемых технических решений и оформления документации. [36]
Система автоматизированного проектирования высокопроизводительных ЭВМ КОМПАС-82 является развитием более ранней версии - системы КАСПИ. Система базируется на использовании ЭВМ БЭСМ-6 с переходом на МВК ЭЛЬБРУС. Общее программное обеспечение составляют операционная система ДИСПАК и мониторная система МОНИ-ТОР-80. Система КОМПАС-82 состоит из четырех основных подсистем: логического и конструкторского проектирования, выдачи документации и генерации тестов. [37]
Для проектирования модели может быть использован метод заглушек. Однако ее эффективность значительно повышается, когда вместо заглушек используются программные модули. В этом случае модель должна решать какую-либо задачу. При этом в один программный модуль достаточно включить всего лишь одну или, в случае организации цикла, несколько команд специализированной ЭВМ. Такая модель позволяет проверить различные варианты комплексирования программных модулей, передачи управления, выдачи документации и, что наиболее существенно, избежать программирование. В соответствии со спецификой модели КП отладочное задание может быть максимально упрощено и включать одно значение исходных данных, например единицу. [38]