`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

TRON уже занят...

0 
 

В этом году исполняется 20 лет японскому проекту TRON (The Real time Operating system Nucleus, семейство ядер операционных систем реального времени). Срок, согласитесь, немалый, что только подчеркивает уникальность проекта. Но прежде чем мы кратко его обсудим, давайте для начала обратимся к упомянутому в преамбуле "великому противостоянию".

TRON уже занят...
Серийно выпускаемый TRON-ПК: процессор 333 MHz; 64 MB ОЗУ; USB­хост; разъем CompactFlash с возможностью подключения IDE­накопителей; видеоподсистема рассчитана на использование внешнего монитора с разрешением до 1280x1024; микрофонный вход и аудиовыход. Комплектуется ОС семейства BTRON, броузером, текстовым редактором и минимальным набором прикладного ПО

Сегодня даже людям весьма далеким от IT индустрии благодаря средствам массовой информации известны имена двух "главных бойцов" великого противостояния -- естественно, Windows и Linux. Из за некорректности, неизбежно диктуемой сиюминутностью моды, менее известно название GNU. И уж совсем не на слуху представители "нейтральной" стороны -- системы семейства BSD. В принципе, этим перечнем действующих лиц все и ограничивается. Если не вдаваться в весьма небесспорные нюансы лицензирования и исторически предопределенные тонкости, по большому счету, ничего нового в противостоянии нет -- не случайно в преамбуле использовались понятия, заимствованные из дисциплины "программная инженерия".

"Черные" и "белые ящики" -- это компоненты (термин здесь ни в коем случае не означает обязательность наличия "компонентной среды") программ, отличающиеся только на основании одного критерия: наличия исходных текстов. Для разработчиков, повторно использующих "черные ящики" (в дальнейшем -- BB, Black Box), исходные тексты программ недоступны. Хорошо это или плохо -- сказать трудно (если говорить о "вообще хорошо" и "вообще плохо"). По крайней мере, пока не ликвидировано понятие "интеллектуальная собственность", всегда будут существовать две противоположных и, по большому счету, неоспоримых точки зрения. Если же говорить не "вообще", а конкретно, то без дополнительных ухищрений, при реализации BB "в лоб", подобное ограничение может породить (и неизбежно порождает) массу негативных последствий. Это утверждение тоже не бесспорно -- но оно, по крайней мере, доказано практикой. Дополнительные ухищрения на самом деле не так уж и страшны -- достаточно основать модель на принципе, позволяющем как относительно несложно изменять (расширять, модифицировать, сокращать) поведенческие характеристики BB, так и легко повторно использовать BB для нужд собственных разработок, при этом не модифицируя собственно BB. Такой принцип сегодня принято называть "компонентной средой", а его роль в жизненном цикле масштабного программного проекта настолько высока, что ему присвоен титул "системообразующего". Именно благодаря ему (в идеале, естественно) можно с требуемыми показателями качества создавать способами "крупноблочной сборки" и "частичной модификации" программные системы заданной функциональности за определенное время и в условиях ограниченного бюджета. Из данного краткого описания напрашивается весьма забавный вывод: получается, что достоинства BB модели напрямую предопределены... ее недостатками, точнее, -- разумностью приемов борьбы с этими недостатками.

Модель "белых ящиков" (в дальнейшем -- WB, White Box), напротив, основывается на принципе полной открытости исходных текстов программных компонентов. У поклонников этой модели есть масса аргументов в пользу ее перспективности "всегда, всюду и во всем". У собственно модели (тут важно понимать разницу между моделью и ее сторонниками) есть и доказанные практикой достоинства, есть и вскрытые той же практикой недостатки. Но имеется и еще одна, на первый взгляд незаметная, особенность -- WB не навязывает необходимости создания единой компонентной среды. Что, по сути, означает отсутствие "системообразующей" роли для последней. Естественно, в рамках модели возможно создание множества компонентных сред, но для них правило "жизненной необходимости" не справедливо.

Вот так "с высоты птичьего полета" выглядит "великое противостояние". Не больше и не меньше. Этических и моральных аспектов мы принципиально не касаемся -- с точки зрения потребителя конечного продукта, для которого и создаются программные системы, по большому счету, нет никакой разницы в тонких нюансах между принципами "интеллектуального меценатства" (лежащими в основе, например, BSD лицензированных WB) и "добровольно обязательного вклада в res publica" (что, по сути, является основой GNU лицензирования WB). Потребитель озабочен совсем другими проблемами, главной из которых является соответствие программной системы его требованиям, специфике применения и его возможностям.


О недосказанном

TRON уже занят...
Электронная книга в TRON-исполнении. Этот прототип нашел воплощение в серийной разработке Sony
В предыдущих рассуждениях есть одно умышленно допущенное крайне грубое упрощение. Но оно простительно хотя бы потому, что мы его восполним для логичной связанности изложения. Программный продукт -- это не только собственно код. Зачастую -- это даже не "код как главное". Это еще и спецификации, документация, сопровождающие материалы, короче говоря, -- все то, что дает возможность потребителю (кем бы он ни был -- хотя бы и разработчиком) с минимальными затратами времени и средств приступить к нормальной эксплуатации программной системы. Исключительную важность эти составляющие программного продукта имеют, в первую очередь, для особых потребителей, а именно для разработчиков, повторно использующих программные компоненты (в данном случае компоненты, очевидно, сами становятся "продуктом"). Степень детализации, принятая в статье, позволяет выявить очевидное (с высоты "большое" видно все таки лучше) -- модель BB вынуждает разработчика концентрировать порой беспрецедентные усилия на создание спецификаций и документации. В противном случае закрытость кода главного продукта -- "черных ящиков" -- приведет к тому, что основной потребитель просто не сможет их использовать. А продукт, который нельзя использовать, никому не нужен и вообще теряет смысл как таковой. Соответственно, для модели BB спецификации и документация являются также "системообразующими" (то есть жизненно важными) компонентами. Яркий пример действия этого правила -- разработка .NET корпорации Microsoft. Достаточно бросить беглый взгляд на количество и размеры файлов спецификаций и документации данного проекта, чтобы понять, насколько они важны в рамках модели BB. И достаточно установить стороннюю WB реализацию .NET (dotgnu.org) на свой компьютер, чтобы оценить степень их качества (ведь эта реализация создана именно на основе спецификаций Microsoft).

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


Третий элемент

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

Теперь вполне разумно и своевременно задать логичный вопрос -- "А возможна ли третья модель, объединяющая в большей степени достоинства, чем недостатки BB и WB?". Благодаря двадцатилетней истории проекта TRON мы знаем, что такая модель на самом деле существует. Но... прежде чем мы поговорим о ней, давайте попробуем проанализировать самое главное -- условия, в которых возможны и ее возникновение, и создание реальных программных систем на ее основе, и, наконец, ее доминирование. Это действительно исключительно важно, потому как позволяет сразу оградить нас от опасности принять успех TRON за правило, или, что хуже, за неотъемлемое свойство такой модели, за закон, который есть "...высказывание (утверждение, суждение, предложение), обладающее такими признаками:

1) оно истинно лишь при определенных условиях;
2) при этих условиях оно истинно всегда и везде без каких бы то ни было исключений...;
3) условия, при которых истинно такое высказывание, никогда не реализуются в действительности полностью, но лишь частично и приблизительно"
(А. Зиновьев).

Начнем с того, что TRON -- сугубо японская разработка. А восток, как известно, -- "дело тонкое". Исторически крупная промышленность Японии, организованная в несколько мегахолдингов дзайбацу, успешно "слилась" с государственными (в первую очередь, военными) капиталами и системой управления. После Второй мировой войны дзайбацу были номинально ликвидированы (по крайней мере, в части семейных основ бизнеса) и раз-укрупнены, но впоследствии "восстали из пепла", даже не сменив названий (например, Мицуи, Мицубиси, Сумимото). Соответственно, и "слияние с государством" никуда не делось -- в этой стране ему принадлежит более 33% основных производственных фондов, а 20% ВНП (валового национального продукта) производится по государственным заказам. Ну а о своевременном выборе (в 50 е годы) правильной политики модернизации отстававшей от передовых стран того времени в научно техническом отношении по самым лояльным оценкам на 25--30 лет экономики и говорить не приходится. В то время Япония сделала безошибочную ставку на капиталоемкие отрасли производства и на золотое правило -- "плоды науки выгоднее быстро купить, чем долго их создавать" (знаменитый пример с историей патента на производственный процесс выпуска нейлона -- одно из лучших тому подтверждений: концерн Dupont затратил на его разработку 11 лет и 25 млн. долл., японской корпорацией патент был приобретен за 7,5 млн. долл. на условиях выплаты суммы в течение восьми лет, за которые она заработала на экспорте нейлона... 90 млн. долл.).

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

А теперь перейдем непосредственно к модели TRON. Она уже получила собственное аббревиатурное название -- OSLS (Open Specifications Loose Standardization), которое можно трактовать как "открытые спецификации нестрогой стандартизации". Ради-каль-ное отличие OSLS от BB и WB моделей заключается в том, что OSLS вообще не касается исходных текстов программных компонентов -- в рамках этой модели основные повторно используемые компоненты "виртуализованы" и существуют исключительно на уровнях спецификаций и документации. Овеществление этих спецификаций (то есть превращение их в код) не ограничено никакими запретами или коммерческими правилами. Основное свойство модели OSLS -- ее "глобальность", к которой, по крайней мере в Японии, относятся очень серьезно. Что японцы понимают под "глобальностью", лучше всего пояснить, цитируя спецификацию системы ITRON: "видение будущего проектом TRON -- это видение полностью компьютеризированного общества -- кибер общества (в оригинале -- сyber society). В кибер обществе микрокомпьютеры будут встроены практически во все предметы, оборудование и инструменты, с которыми люди имеют дело в повседневной жизни. Эти компьютеризированные устройства будут соединены сетями и будут работать совместно для поддержания человеческой деятельности в самых разных ситуациях. При-соеди-ненные к сети отдельные -устройства со встроенными микрокомпьютерами мы называем IO -- интеллектуальными объектами (Intelligent Objects), а образованные множеством совместно работающих соединенных IO подсистемы -- HFDS, сверхфункциональными распределенными системами (Highly Functional Distributed Systems). Реализация HFDS -- наиболее важная цель проекта TRON". Вот так -- не больше и не меньше.

А в основе такого амбициозного глобализма главной цели проекта (который, по большому счету, также надо было бы отнести к условиям возможности успеха TRON) лежат разрабатываемые некоммерческой организацией -- лабораторией профессора Кена Сакамуры -- спецификации на ядро операционной системы реального времени, отвечающей жестким требованиям самых разных областей применения. ОС должна великолепно масштабироваться и обеспечивать повторное использование спецификаций как ее самой, так и сторонних программ, при реализациях на вычислителях с разрядностью от 8 до 64 бит, с объемами памяти в десятки килобайт, при этом обеспечивать время переключения между процессами, измеряемое микросекундами. И, что главное, она не имеет права терять "изящество и прозрачность", иначе говоря -- реализация конкретной TRON совместимой ОС должна быть доступна всем желающим, а не исключительно располагающим астрономическими бюджетами и предполагающим жить вечно.

Вероятнее всего, успех такого проекта, как TRON, возможен исключительно в такой стране, как Япония. А в том, что он достигнут, сомневаться не приходится -- лаборатория Сакамуры выдала на гора очередную (четвертую) ревизию спецификаций, количество реализаций TRON-сов-местимых ОС давно превысило количество доступных на рынке микропроцессорных и микроконтроллерных архитектур, а уж о числе потребительских устройств, в которых упрятана TRON, лучше и не думать -- тут счет идет на миллиарды. Короче, она самая массовая несуществующая "в коде" операционная система.

С "диктатурой модели TRON" пришлось смириться всем -- и сторонникам BB модели, и приверженцам WB. Так, корпорация Microsoft заключила соглашение о сотрудничестве с некоммерческой организацией T Engine Forum, занимающейся под председательством Сакамуры поддержкой разработки спецификаций одной из ветвей TRON. Microsoft вместе с T Engine Forum будут добиваться возможности функционирования ОС Windows CE над ядром TRON. Поклонники WB также не остаются в стороне -- известная в мире Linux компания MontaVista Software предприняла такой же шаг, добиваясь работы ОС Linux в TRON-микрокомпьютерах на точно таких же условиях. К "претендентам на TRON" можно причислить и Oracle, которая еще в прошлом году анонсировала оптимизированную для встраиваемых приложений и выполняющуюся под управлением TRON версию СУБД Oracle 9i Lite. Идея "TRON глобализма", похоже, покорила Китай и Южную Корею -- ведущие исследовательские организации этих стран подключились к проекту. Если же судить по числу компаний, принимающих участие в тематических TRON выставках, то можно уверенно говорить о том, что проект TRON из сугубо японского начинает приобретать совсем интернациональный характер. Да и количество инноваций, представленное на TRON выставках как именитыми, так и совсем неизвестными участниками, впечатляет. Не менее впечатляюще выглядят сведения о доле рынка встраиваемого программного обеспечения, отвоеванной "программами, распространяемыми на уровне спецификаций" -- более 40%. Причем благодаря осуществляемому лабораторией Сакамуры мониторингу этого специфического сегмента рынка можно, -например, подтвердить ранее высказанное предположение о требовании "изящества и прозрачности" спецификаций -- 40% производителей, использующих TRON в своих изделиях, предпочитают реализации собственного изготовления, а не доступные коммерческие. Более тонкий анализ данного сегмента позволяет выделить области применения TRON, в которых система уже стала явным лидером -- персональные информационные приборы, тонкие клиенты (графические терминалы), бытовая аппаратура. Справедливости ради следует заметить, что в традиционных областях применения встраиваемых компьютеров (например, в промышленной автоматике, системах управления электроустановками и т. п.) позиции TRON не так сильны, и системе еще предстоит сказать свое слово.
0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT