Январь 2008

"... (Мой) принять в целом вопрос открытых стандартов по сравнению с открытым исходным кодом? Я бы сказал это: Если он не имеет реализация открытым исходным кодом ссылки, термин «стандарт» представляет собой злоупотребление языком. Это все еще очень сильные позиции по нынешним меркам. Но это не будет в трех до пяти лет. Если он не имеет реализация открытым исходным кодом, как вы знаете что стандарт означает?»

Эрик Рэймонд, со-основатель инициативы Open Source

В этой статье мы предлагаем некоторые понимание взаимосвязи между non кодом на основе открытых активов, открытые разработки процессов и открытых стандартов. Исследования основаны на тематическое исследование OpenAccess определяют (ОА) проект Силиконовой интеграции инициативы. Уникальные отношения между OA стандартом открытости, эволюции и принятие является пример того, как открытые процессы могут использоваться для разработки инструментов взаимодействия, инноваций и сотрудничества.

Стандарт API открытого доступа

Широко признается, что отсутствие взаимодействия между инструментами разработки автоматизации электронного проектирования (EDA) является основным ограничением для экономичных проектирования и производства кремниевых интегральных схем. OA проекта и OA коалиции (ОАЦ) было предложено Силиконовой интеграции инициативы (Si2) и основана Hewlett-Packard, Intel, IBM, Motorola, Lucent, солнце, ритмичность и наставник графики в конце 1999 года, чтобы обеспечить стандарт данных собирающих API-дизайн.

О. Проект состоит из трех строительных блоков: спецификация стандарта API (Application Program Interface), эталонная реализация базы данных и открытый процесс (называемый OpenEvolution) для управления развитием стандарта. OA API спецификация включает в себя три компонента:

  • Информационная модель определяется коллекцией диаграмм отношений сущностей
  • модели данных, определенной в файлах заголовка C++, указав класс программного обеспечения и детали интерфейса публичной функции
  • Данные заголовка API в удобочитаемом формате

Реализация OA (OARI) является исходный код, или связанных библиотек, реализация API, который публично доступен как часть дистрибутива ОА. OARI не является формальной частью стандарта API ОА, но был разработан чтобы быть публично доступны как принятие и механизм критического развития стандарта.

В центре ОА OpenEvolution структуры управления являются несколько групп заинтересованных сторон, контроля за эволюцией OA с точки зрения финансирования, а также технических руководящих указаний, включая:

  • OpenAccess определяют коалиция (ОАЦ)
  • ChangeTeam: совокупность технических экспертов, представляющих компаний-членов коалиции, которые служат ОАЦ для управления эволюцией OA стандартной спецификации и OARI
  • Интегратор: Ритмичность, который отвечает за поддержание OARI
  • Рабочие группы: группы специалистов из компаний-членов, которые сотрудничают/сотрудничать на требованиях для необходимых улучшений и расширений

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

ОАЦ разработал два слоя структуры проекта OA, включающий спецификации API и OARI следующие три принципа: i) все изменения API должны быть предложены через реализацию в текущем OARI; II) OARI OA должны всегда соответствовать OA API стандарта; и iii) ЭПУ компании, использующие OARI как часть их коммерческих продуктов должны использовать только официально выпущенные версии и в двоичной форме только. Компании, требующие модификации OARI или OA API для улучшения их коммерческих продуктов ЭПУ должны получить изменения, утвержденные ChangeTeam. Эти три принципа, наряду с преимуществами, включаемые открытым исходным кодом развития характеристик OARI, были предназначены для обеспечения эффективной разработки стандартов и принятия механизма.

Хронология проекта стандарта OA

OA стандартный проект был разработан как продолжение CHDStd (чип-иерархическая система проектирования: Технические данные) инициатива под эгидой SEMATECH в середине 1990-х годов. CHDStd был разработан на основе проверенной технологии IBM, чтобы обеспечить общее представление данных дизайн IC (микросхемы) и API для доступа и управления этими данными. Однако CHDStd не удалось получить признание промышленности, главным образом потому, что его конечный результат был Спецификация документа с кодом реализации нет доступных ссылок. OA жизнеспособность фазы

В конце 1999 года, когда Si2 признал право собственности CHDStd программы стало ясно, что успех отрасли стандартной модели данных будет основываться на реализации базы данных, совместимый с API и полезным, как производство автомобиля само по себе. Кроме того существует большой интерес в открытым исходным кодом реализации этой базы данных. Это побудило Si2 искать решение отличается от технологии CHDStd и в конечном счете принять технологии вклад систем проектирования Cadence. Этот вклад включает спецификацию API и исходный код для эталонной реализации, а затем под названием Genesis.

В декабре 1999 года Si2 сформировали дизайн коалиции API (DAPIC), основателей состав которой входили многие крупные, высокопроизводительные ЭПУ пользователей компании, которые ранее были вовлечены в CHDStd инициативы. Si2 сделал как условие для членства в DAPIC, что члены должны взять на инженерные ресурсы активного проекта с использованием эталонной реализации. Кроме того ритмичность установить условия на DAPIC за его вклад, один из которых был, что будет сформирована Рабочая группа (РГ) для решения некоторых важных недостающих технологических аспектов бытия. DAPIC члены согласились сформировать РГ для определения «Расширения» технология, которая будет играть решающую роль в убеждении других крупных поставщиков ЭПУ рассмотреть вопрос об использовании технологии от основных конкурентов.

В июне 2001 года Si2 переименован DAPIC в ОАЦ и публично объявила о своем запуске. ОАЦ выпустила Бытие API спецификации к публике как «OA API 1.0» в сопровождении двоичного кода базы данных, а позднее исходный код. В ходе этого этапа программы отношение большинства поставщиков EDA был одним из «подождать и посмотреть». По их мнению, это будет конкурентоспособной двигаться в значительной степени обусловлен ритмичность и серьезно сомневается в том, что ОАЦ когда-либо будет успешным. Основная цель этого этапа программы было доказать жизнеспособность OA целей.

На этом этапе жизнеспособности ОАЦ сосредоточены на создании OA технологической базы и бизнес-процессов управления должен использоваться для публикации и поддержки стандарта. ОАЦ сильно взаимодействует с промышленностью, чтобы понять и реагировать на страхи и сомнения «подождать и посмотреть» компаний. Были приняты решения, и поддержки политики и правовые соглашения были разработаны, чтобы использовать модель источника сообщества для OA в отличие от модели полностью открытым исходным кодом. Коалиция согласился дать каденцию управления полностью переписанный API и OARI без подробных изменений обзор для трех первоначальных выпусков путем указания только их охвата и график. После этого управления API и OARI будет передана ОАЦ ChangeTeam.

Конец этой фазы жизнеспособности в январе 2003 года был отмечен публичный релиз Бытие переписать, OA версии 2.0 и введением первого OA совместимый коммерческий инструмент, виртуозные каденции пользовательский дизайн платформы. Виртуоз, в настоящее время также продолжает поддерживать его хорошо организованной базы данных CBDA.

Приверженность целям ОАЦ ЭПУ пользователями была создана путем скорейшего принятия технологии в производство дизайн потоки двух компаний-членов ОАЦ, Hewlett-Packard и LSI Logic. Эти ранние были мотивированы как интерес для продвижения дела ОАЦ путем доказывать жизнеспособность OA в потоках производства дизайн, как они были существенные технические преимущества. LSI Logic также разработала полный набор расширений языка привязок для OA API в язык сценариев Python и способствовали этой технологии, таким образом сделать его доступным для всего сообщества ОА. Это был первый взнос OA от компании за исключением каденцию.

OA уточнения фазы

Следующий важный этап можно рассматривать как этап уточнения OA, который увидел больший вклад требований ОАЦ членами, выпуск версий OA 2.1 и 2.2 и начало принятия дополнительных ЭПУ пользователей компаний и поставщиков. На этом этапе число ОАЦ членов возросло значительно, хотя другие большие ЭПУ продавцы были по-прежнему особенно пропавших без вести. Для удовлетворения новых потребностей для технологии были созданы дополнительные WGs. Ритмичность усердно работали для тонкой настройки надежности и производительности OARI. ОАЦ разработал программы формального обучения, текст книги и программное обеспечение перевода утилиты для помощи миграции OA из существующих стандартов Эда формата.

Как и планировалось, в июле 2004 года каденцию начали делиться контроль с командой изменения ОАЦ, ведущих больше поставщиков полагать, что коалиция не только каденцию управляемый проект. Кроме того была учреждена новая multi-tiered членство Si2, что способствовало более мелких поставщиков присоединиться к коалиции.

Конец этапа уточнения был отмечен сообщества выпуск более зрелой и стабильной версии стандарта ОА в ноябре 2004 года. Эта версия была точка, на которой ритмичность и ОАЦ приверженность очень стабильной, обратно совместимый Стандарт API. В ходе этого этапа было заметное увеличение числа OA продукт объявления, сделанные ЭПУ поставщиками. Ритмичность представил новую версию виртуоза, который поддерживает OARI и провозгласил конец жизни для CBDA. К концу 2004 года насчитывалось 29 коммерческих и внутренний дизайн инструменты поддержки ОА. Самое главное Топ пять поставщиков ЭПУ, ритмичность, Синопсис, наставник графики, магма и Zuken, были членами ОАЦ.

Фаза утверждения о.

2005 года начался этап принятия OA и конец 2006 года был отмечен дальнейший рост в ОА доступности продукта как коммерческих, так и внутренних инструментов EDA. Как проект OA прогрессировала в фазу его принятия, было 43 таких инструментов. Если стандарт OA стать основной отрасли стандартной базы данных технология IC физического проектирования, будет несколько исключений для его использования в поставщиков инструментов и пользовательский дизайн потоков.

Как открыть OA активы?

OA открытые активы имеют гибридный характер. Формально спецификация OA API обеспечивает стандарт. API, однако, не может рассматриваться в отрыве от OARI, который доступен в двух формах: исполняемые файлы и исходный код. Доступ к двоичным файлам OARI дает возможность ознакомления с функциональностью API и, более того, фактическое применение разработки с использованием API, но без возможности предложить улучшения. Доступ к исходному коду содержит инноваций и развития механизма для создания полномасштабной практики источника развития и возможность предложить улучшения.

Открытость OA активов можно описать права, предоставленные пользователям. Non-Si2 члены могут загружать общие релизы OA стандартной спецификации, а также двоичные файлы и исходный код OARI. Академические члены и Si2 члены имеют доступ к член-релизы, которые доступны раньше, чем общие релизы. Si2 члены могут также использовать, воспроизводить и готовить производные работы OA стандартной спецификации и OARI в исходном и двоичном коде для некоммерческого и внутреннего использования. Кроме того члены ОАЦ могут воспроизводить, распространять и сублицензировать OA стандартной спецификации и OARI в исходном и двоичном коде для некоммерческого использования, но может включать только скомпилированный двоичный код в продуктах, которые они продают.

Любые изменения в скомпилированный исходный код, распространяемый в продуктах за пределами границ компании должны в течение 30 дней назад способствовали ОАЦ. Однако если изменения не принимаются в исходный код QE4 OA, изменения по-прежнему может использоваться в распределенных продуктов. Было установлено, что такая гибкость в условия лицензирования иметь важное значение для принятия OA.

Описание прав пользователя актива OA показывает, что OARI не отвечает критериям определения ПСОК, предоставляемых Open Source Initiative. Условия распространения для членов ОАЦ не позволяют никому распространять производные исходный код OARI. Для коммерческих целей членам разрешается только распространять скомпилированный двоичный код. Кроме того права на использование и распространение OARI отличаются Si2 уровней членства.

Компании, желающие распространять неизмененная версия двоичного кода OARI в своих продуктах должны стать членами ОАЦ и платят членский взнос в ОАЦ. И Последнее, но не в последнюю очередь исходный и двоичный код OARI не являются технологически нейтральной поскольку они должны соответствовать стандартным спецификациям OA API. Необходимо отметить, что основные отклонения между характеристиками OA активов и критерии определения ПСОК были намеренно реализованы Si2 и ОАЦ, чтобы помочь развитию, целостность и последовательность стандарта обеспечения приверженности основных промышленных игроков.

Как открыть процессы развития OA?

Для обсуждения открытости процессов развития OA мы будем использовать подход, разработанный фон Хиппель, который применил пользователя инновационной сети теории для изучения развития технологий открытым исходным кодом. Фон Хиппель определил пять аспектов разработки открытого исходного кода:

  1. Бесплатно выявление технологии или активов
  2. Сообщество пользователей инновации
  3. Коллективное изобретение процесса: циклический процесс последующих инноваций, ведущих к серии постепенных улучшений, инициирования новых раундов инновационной деятельности
  4. Производство на базе общин сверстников: новые режим производства, в котором члены сообщества пользователей совместно работают над проектами, ведущих к улучшению или совершенно новые версии выпущенные технологии или активов
  5. Управление сообщества пользователей и поддержка

Все эти измерения можно найти в ОА OpenEvolution процесса: i) основания ОАЦ, процессы управления Si2 и OA ИТ-инфраструктуры включен механизм поддержки и управления сообщества пользователей; ii) освобождение каденцию в OpenAccess определяют характеристики и двоичный и исходный код как OARI 2.0 позволяет свободно выявленные технологии; III) доступ общественности к форум разработчиков OA, расширение запроса Tracker и загрузки спецификаций OA 2.0 API и OARI код включен активных пользователей сообщества инноваций; IV) выпуск OA 2.0 Исходный код для сообщества включен процесс коллективного изобретения, наиболее печально выраженной в деятельности РГ; и v) выпуск OA 2.2 версия была основана на вход члена коалиции и признание ChangeTeam и свидетельствует о присутствии сверстников производственного процесса.

Как открытый стандарт OA?

Нет никакого четкого определения открытых стандартов. Один из последних определений была представлена Майкл Tiemann, который определил четыре уровня стандарта открытости:

Открытый стандарт 0: стандарт документально и может быть полностью реализован, используется и распространяется бесплатно

Открытый стандарт 1: существует указанный OSS продукт, который может взаимодействовать с стандартом

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

Открытый стандарт 3: Эталонная реализация стандарта является реализация открытым исходным кодом

Согласно этой модели классификации уровень 2 характеризуется наличием OSS implementation(s) стандарта но не эталонной реализации. Уровень 3 характеризуется наличием ПСОК эталонная реализация; Эталонная реализация стандарта является открытым исходным кодом. OA Стандартный уровень открытости выше уровня 1. Однако, он имеет характеристики обоих уровней 2 и 3 с: i) существует реализация OA, которая является открытым исходным кодом (особенность 2-го уровня) с каким-то образом ограниченного перераспределения терминов; и ii) существующих ОА «квази»-реализация открытым исходным кодом является реализация (характеристики уровня 3). Сочетание функций OA от обоих уровней 2 и 3 был разработан, чтобы обеспечить средства для: i) продвижение стандарта с течением времени по мере улучшения практики; и ii) обеспечение защиты от фрагментации, когда проприетарная реализация расширяет стандарт но расширения не были преобразованы открытым исходным кодом эталонной реализацией.

Идеи из ОА проекта

На самых ранних этапах разработки открытого стандарта основной спрос на открытых активов обусловлено главным образом крупными компаниями пользователей.

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

Разработка механизмов принятия стандартных OA в код реализации предотвращает совещания полный набор критериев для ПСОК. Процесс стандартного усыновления требует, распространяется код с каких-либо изменений в соответствии с интерфейса, реализованного с конкретной технологией. Эти два требования предотвращения активов от называют открытым исходным кодом актива. Этапы жизненного цикла разработки стандартов можно определить с помощью выпуска продукта вехи. Конец каждого этапа OA стандартного проекта был отмечен выпуском новой версии стандарта ОА, которая качественно отличается от предыдущего. Конец этапа жизнеспособности был отмечен выпуском OA версии 2.0, отправной точкой процесса развития технологии OpenEvolution. Конец этапа уточнения был отмечен введением OA версии 2.2, пожилые, производство благоприятных и обратно совместимых эталонной реализацией. Этап принятия был отмечен значительный рост в коммерческих инструментов дизайна на основе OA ЭПУ.

Достижения этапа принятия стандартного проекта с областью OA занимает много лет, особенно потому, что это технология базы данных для использования в самом центре EDA приложений и систем. Замена модели среды выполнения на основе устаревших ЭПУ программного обеспечения, даже с отличным программным обеспечением стратегии, является серьезной проблемой.

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

Несколько структуры уровня членства может ускорить принятие стандартного проекта. Число членов в Si2 и ОАЦ значительно вырос, когда структура была изменена с одного уровня на три уровня членства структуры. Каждая структура членства целевой определенного типа члена. Это облегчает для компаний, чтобы присоединиться к уровню членства, с которым они чувствовали себя наиболее комфортно.

Выражение признательности

Мы хотели бы выразить нашу признательность г-н Дональд Коттрелл за его неоценимый вклад редакционного характера и роли в качестве ссылки для времени и конкретного характера исторических фактов с самого начала этого исследовательского проекта. Коттрелл начал свою профессиональную карьеру с корпорацией IBM и в течение следующих 28 лет был членом IBM корпоративного ЭПУ развития где он занимал ряд старших технических и управленческих должностях. После его ухода из IBM в 1993 году Дон присоединился к команде управления Si2 где, как вице-президент технологии, он отвечал за все Si2 инженерные и сервисные проекты. В 2003 году Коттрелл была названа как Si2 парень с ответственность за изучение новых технологических областей, в которых должны заниматься Si2. Si2 дизайн для производства коалиции (DFMC) программы, за которую отвечает Коттрелл, является одним из таких примеров. В июне 2007 года в отставке Коттрелл.

Мы также хотели бы выразить нашу признательность г-н Стив Шульц, президент и главный исполнительный директор и г-н Sumit Дасгупта, старший вице-президент по инженерии, Si2 за их поддержку и сотрудничество.

И Последнее, но не в последнюю очередь мы благодарим д-р Тони Bailetti, профессор в программе управления инновационной технологии в Карлтонском университете и директор талант первой сети, открытым исходным кодом технологии коммерциализации инициативы, финансируемой Онтарио Министерство исследований и инноваций, за его сотрудничество в области исследований и финансовой поддержки.

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!