Кадырбаев Чингисхан Каликанович¹, Медетов Нурлан Амирович^2
1Костанайский государственный университет имени А. Байтурсынова

Концепция архитектуры контроллеров для

автомобильной промышленности

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

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

Была представлена концепция контроллера с оригинальной открытой модульной архитектурой (Original, Modular Architecture Controller, OMAC) и описаны функции его элементов и программных модулей. Формулируются требования к верхним уровням элементов контроллера, руководствуясь которыми производители, университеты и руководящие технологические организации смогут разрабатывать изделия, удовлетворяющие потребностям автомобильной промышленности США. Концепция одобрена в отделениях автомобильной компании Ford и корпорации Chrysler. Претворение в жизнь этой концепции позволило создавать экономичные, удобные в эксплуатации, открытые, модульные контроллеры, обладающие высокой степенью интеграции и отвечающие нуждам автомобильной промышленности.

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

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

Широкий спектр производственных приложений в автомобильной промышленности предъявляет к функциональным возможностям контроллеров различные требования. Эти приложения, как правило, можно подразделить на две основных категории. Числового Программного Управления (ЧПУ), где требуется перемещение относительно координатных осей и управление небольшим количеством точек дискретного В/В, например станочными операциями, и типа ориентированного на дискретные события Программируемого Логического Управления (ПЛУ) некоторыми некоординированными перемещениями, где в большинстве случаев требуется принятие последовательных логических решений, например передача операций по конвейеру [2]. Внутри каждого класса приложений требования к операциям могут значительно меняться.

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

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

При наличии доступных открытых модульных контроллеров различие между ЧПУ и дискретными приложениями сгладится. Модульность и интегрируемость архитектуры таких контроллеров позволяет легко объединять отдельные функции, ориентированные на конкретные приложения, благодаря чему потребность в контроллерах со специализированными функциями снижается.

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

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

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

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

Описание контроллера и концепция модульности

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

Требования, предъявляемые к архитектуре контроллера

В данном разделе приводятся требования, предъявляемые к контроллеру с открытой, модульной архитектурой.

Инфраструктура

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

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

Структура аппаратной шины контроллера должна быть стандартной де-факто в конкретной области рынка. Предпочтение отдаётся VMEbus или некоторым разновидностям шин ПК, таким, как ISA, EISA или PCI.

Общая стоимость инфраструктуры контроллера должна быть минимальной.

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

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

Управление информационной базой

Информационная база контроллера должна сохраняться простыми способами.

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

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

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

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

Синхронизация задач

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

Средство программирования для синхронизации задач и средство программирования дискретного ввода-вывода должны иметь общий инструмент "просмотра и принятия решений". Функции синхронизации задач должны программироваться с использованием IEC 1131-3 (ISaGRAF) или языка программирования блок-схемного типа [5].

Библиографический список
1. Автомобильный справочник Bosch. Изд. 2-е, перераб. и доп. – М.: За Рулем,2002.

2. Агунов А. В. Схемотехника систем автоматизации: Учебное пособие Издательство: СПбМТУ, 2005

3. Александров В.В. Несколько слов о мехатронике // Мехатроника. 2001. №1. С.4.

4. Андриевский Б.Р., Фрадков A.JI. Элементы математического моделирования в программных средах MATLAB 5 и Scilab (учебное пособие). СПб: Наука, 2001

5. Антонов Б.И., Филимонов Н.Б. Не «обо всем», а о мехатронике (о границах проблематики журнала) // Мехатроника. 2000. № 6. С.43-47.