Коллективная разработка систем

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

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

Подготовка начинается с четкого определения целей, однако это не так просто, как кажется на первый взгляд. Роджер Ричардсон (Roger Richardson), президент компании Delta Sigma Corp., которая занимается разработкой производственных систем для аэрокосмической отрасли, отмечает, что "владельцы бизнеса знают свои производственные процессы гораздо лучше нас. Они знают, что сложно и что легко, а также им известны все "подводные камни". То, что они не знают – это как автоматизировать процесс".

"К сожалению, за последние 30 лет во внутренней среде компаний, наших клиентов, произошли изменения", говорит Рэнди Дженнингс (Randy Jennings), вице-президент по развитию бизнеса системного интегратора Transbotics Corp, который специализируется на системах производства, складирования и дистрибуции. "Оказывается, целый слой менеджмента и технических специалистов в американской промышленности сейчас отсутствует. В результате у клиентов есть потребности и желания, но у них нет персонала, необходимого для четкой постановки задачи".

Планирование проекта непременно развивается сверху вниз. Это означает, что всё начинается с определения полной архитектуры – общей картины – затем начинают уточняться детали. Реализация, однако, развивается снизу вверх – вы сначала пишите код модулей и покупаете или создаёте аппаратную часть, а лишь затем интегрируете их в единую систему. Если детали вашего проекта не были определены до начала реализации, то вам придётся переделывать практически всё, тратя в несколько раз больше усилий, чем при наличии четкого представления. Если быть более точным, то в несколько раз больше усилий будет тратить ваш системный интегратор!

Часто обменивайтесь информацией – но не слишком часто

Боб Гамбургер (Bob Hamburger), менеджер по развитию бизнеса системного интегратора Bloomy Controls (системы сбора и управления данными), говорит, что, по их опыту, большинство вещей, которые крадут время – это элементы пользовательского интерфейса в программном обеспечении. "Один из вопросов, который наши опытные специалисты сразу спрашивают – это „Есть ли у вас какие-либо пожелания к виду и работе пользовательского интерфейса?”"

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

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

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

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

Серьёзные системные интеграторы обычно используют специализированное программное обеспечение для планирования работы системы. К примеру, компания Transbotics использует ПО планирования маршрутизации для визуализации маршрутов перемещений максимальной производительности.

Серьёзные системные интеграторы обычно используют специализированное программное обеспечение для планирования работы системы. К примеру, компания Transbotics использует ПО планирования маршрутизации для визуализации маршрутов перемещений максимальной производительности.
Источник: Transbotics

Автоматизировать или не автоматизировать

Автоматизация – это не панацея. Некоторые задачи просто ждут – не дождутся, когда их автоматизируют, но иные лучше продолжать делать вручную. Иногда интеграторы ищут однообразные, грязные или опасные задачи. Однако такие критерии в заводской среде не всегда работают. Дженнингс предпочитает смотреть на повторяемость задачи: "Нужно уметь распознавать повторяющиеся движения. Действия человека – это – лучший показатель возможности автоматизации процесса. Если вы видите человека, делающего какие-либо однообразные движения, то, скорее всего, эту функцию можно автоматизировать".

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

Гари Кэш (Gary Cash), вице-президент по продукции и маркетингу поставщика распределительных систем FKI Logistex, утверждает, что при автоматизации процессов возрастает их точность, однако это не является причиной, по которой компании запускают подобные проекты. "Когда компания мала, все операции на складе производятся вручную. Автоматизация начинается тогда, когда становится понятно, что нельзя нанять больше людей и впихнуть их в одно здание, иначе они начнут сидеть друг у друга на головах. То есть когда не хватает производительности, начитается автоматизация. Некоторые функции автоматизируются раньше других. Перевозки, к примеру, как правило, идут первыми в этом списке".

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

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

Выполните сначала домашнее задание

Перед тем, как даже подумать о создании команды с системным интегратором, выполните сначала домашнее задание по проекту.

"Составьте четкое представление о своих потребностях", говорит Дженнингс. "Вам не нужно находить решения, но вам нужно понять свои потребности – не желания, а именно потребности".

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

Системный интегратор должен понимать, откуда берётся исходный материал, какая у вас производимая продукция, какая ожидаемая максимальная норма выработки, насколько широк список производственных инструментов, каков цикл прохождения заказа до заказчика и жизненный цикл заказа в целом. Естественно, одна из вещей, которую нужно знать – это как продукция перемещается от одного процесса к другому. "Мы стараемся оптимизировать перемещения, чтобы она подавалась вовремя, для уменьшения дополнительных приспособлений", говорит Дженнингс. "Поэтому, один из самых серьёзных вопросов – это как выглядит помещение, и что вы в нём предусмотрели".

На первой встрече с заказчиком Гамбургер из Bloomy первым делом пытается создать четкое описание проблемы. Что клиент пытается достичь? Что они хотят автоматизировать? Что они пытаются измерить? Их этого основополагающего описания задачи он пробует определить различные аспекты системы. Какие типы датчиков будут использованы? Какие нужны типы силовых приводов? Сколько каналов для каждого типа физического параметра потребуются?

"Поскольку то, что мы делаем, по существу является сбором и управлением данных", говорит он, "то отправной точкой является определение списка каналов. Сколько потребуется аналоговых входов и выходов, и как они будут использоваться при тестировании устройства или при автоматизации процесса?"

"Мы записываем наше понимание проблемы и по крайней мере концептуальное описание решения, в том числе описание рекомендуемой нами аппаратной части, а также то, как система может быть спроектирована", добавляет Гамбургер.

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

Гари Кэш из FKI говорит, что "мы должны понять ваш бизнес для того, чтобы помочь вам. Поэтому вам надо рассказать нам, как он работает, и мы придумаем, как заставить здание работать, как спроектировать его, как всё реализовать, и заставить всё работать как надо".

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

Ещё один серьёзный вопрос при организации сети заключается в том, будет ли разрабатываемое производственное оборудование связанно с корпоративной ИТ сетью или оно будет связано в отдельную сеть. "Существует разделительная линия между сетью в классическом понимании, которое используют ребята из отдела ИТ", говорит Гамбургер, "и сетью внутри производственного помещения".

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

Координация перемещения материалов через обычные транспортёры и роботизированное оборудование требует соединительных сетей на уровне механизмов, производственных участков, цехов завода, а также на уровне всего предприятия.
Источник: Kuka Robot Group

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

"Вероятно 75% веб-интерфейсов, которые мы сделали", отмечает Гамбургер, "находятся в локальных сетях. Они доступны только с компьютеров, находящихся внутри защищенной сети. Остальные 25% потребовали от нас кооперации с ИТ специалистами клиента для того, чтобы они открыли доступ в своём файрволе или поставили выделенный сервер у себя в сети. Это, кстати, довольно просто – установить аппаратный файрвол с недорогим роутером для защиты веб-сервера от атак злоумышленников".

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

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

Соглашение о неразглашении

Каждый раз при заключении контрактов с третьей стороной на какие-либо работы, возникают неприятные вопросы, связанные с интеллектуальной собственностью. "Как правило, при первой необходимости передачи информации, которая представляет ценность для клиента, возникает вопрос о заключении соглашения о неразглашении (non-disclosure agreement, NDA), иногда даже до первой совместной встречи", говорит Гамбургер из Bloomy.

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

Клиенты из аэрокосмической отрасли компании Delta Sigma чрезвычайно чувствительны к вопросам интеллектуальной собственности. Компания имеет необычные отношения со своим крупнейшим клиентом, с которым они так тесно сотрудничают, что иногда идеи по автоматизации поступают не только со стороны клиента, а со стороны Ричардсона. Ричардсон настаивает на том, чтобы в контракте были прописаны вопросы интеллектуальной собственности, в особенности те, которые определяют обладателя дизайна системы по завершению работ.

Работая в аэрокосмической отрасли, Ричардсон накопил богатый опыт в написании и подписании NDA. "Около двух недель назад", вспоминает он, "потенциальный клиент прислал мне их NDA, а я ему ответил в письме, что я такое не подпишу. Я отправил ему свой стандартный вариант NDA, и он в ответе написал, что это лучшее NDA, которое он когда-нибудь видел".

Соглашение о неразглашении Ричардсона такое хорошее благодаря своей полной двусторонности. Вместо выделения покупателя и продавца, его вариант говорит об источнике и получателе данных. В нём нет ничего, что указывало бы на преимущество какой-либо из сторон. Многие адвокаты по интеллектуальной собственности стараются подписать NDA, которое было бы выгодно их клиентам, прижимая при этом другую сторону. Однако это приводит к обратным результатам, поскольку высококомпетентный и опытный партнёр-разработчик – а ведь именно такого вы хотите иметь в своей команде – не подпишет его. Соглашение о неразглашении, как и любой другой контракт, бесполезно, если только обе стороны не согласны с ним и не следуют ему.

Утвердите приёмочные тесты

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

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

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

Если у вас нет собственных возможностей по поддержке системы, вы можете положиться на системного интегратора в задачах по её обслуживанию и ремонту. Убедитесь, что контракт определяет ответственность по поддержке и починке системы. Независимо от того, кто берёт эту ответственность – вы, системный интегратор или третья сторона – укажите это вместе со списком документации, которая будет требоваться для поддержки (руководства, схемы и т.п.).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *