При разборе проблем в отечественной промышленной политике обычно обращаются к китайской действительности, где производится большая номенклатура продукции. Да и китайские заводы у всех на слуху. При этом в дискуссиях незаметно происходит фетишизация производства и подмена понятий: создается впечатление, что если завод производит радиоэлектронные изделия, то он знает и понимает как эти изделия создавать. Для многих между этими двумя понятиями стоит знак равенства, но на самом деле между производством и разработкой (R&D, Research and Development) – пропасть.
Приведу небольшой пример. На снимке – небольшое радиоэлектронное устройство. Видно, что оно выполнено по технологии поверхностного монтажа; судя по разъемам и основаниям для крепления экранов, содержит СВЧ компоненты. Завод, производящий эту плату, может демонстрировать ее на выставках и она будет показателем высокого уровня технического развития и соответствия современным технологиям. И это на самом деле так.
Для чего предназначена эта плата и какую роль она выполняет в системе, частью которой она является? Завод об этом не знает (если только не производит всю систему целиком). Собственно, это устройство и было так изготовлено: производителю была передана печать и необходимая документация, перечень элементов, благодаря чему он самостоятельно закупил компоненты, изготовил печатную плату, установил компоненты на плату. При этом производитель не имел ни малейшего понятия, для чего предназначена плата – на все про все ушло 2 недели.
Если плата должна быть проверена на заводе (что совсем не обязательно), это делается по инструкции – включили, увидели, сравнили. И опять-таки без погружения в суть.
Мы, как разработчики, знаем что на снимке – приемник диапазона 60 – 1000 МГц, содержащий синтезатор частот, управляемый по I2C, с возможностью работы от внешнего синтезатора с целью поддержания когерентности системы. Выходной сигнал – квадратурные составляющие I/Q, предназначенные для оцифровки в быстродействующих АЦП. У нас на руках электрическая схема, описание работы и другие документы, которых у завода нет и которые ему не нужны.
Теперь представим, что заказчик, вдохновившись этой платой, которая изготавливается на “передовом производстве”, задает заводчанам вопрос: ребят, а можно нижнюю частоту сделать 50 МГц? Или – у вас внешне подключаемые ФНЧ, какая оптимальная частотная характеристика будет если оцифровку выполнять на скорости 250 млн. выборок в секунду? Или – давайте упростим плату и перенесем синтезатор в другое устройство, какие фазовые шумы нужно обеспечить для того чтобы вы выполнили требования по когерентности? И тут в ответ – тишина… Заводу ответить нечего. И незачем – его задача обеспечивать партию выпуска по той документации, которую ему дал разработчик.
Смешная получается история: солидное предприятие, станки стоят, руководство ходит в галстуках, получает финансирование на развитие и модернизацию… а модернизировать ничего не может. Приходится обращаться к очкарикам, которые сидят в небольшой комнатке со своими приборами, паяльниками и компьютерами 🙂 Смешно потому, что когда рассказываешь о своих проектах, тебя спрашивают: а где у вас производство? Граждане, производство сейчас вообще не проблема! Любую деталь или плату вам сделают за милую душу где угодно – хоть в Рязани хоть в Таиланде. Только платите. Не про производство надо спрашивать, а про IP – интеллектуальную собственность, которая подтверждена реально работающими устройствами.
Посмотрите, как устроены и работают современные европейские компании. Большая часть узлов изготавливается по кооперации, поскольку для таких объемов нет смысла держать свое производство.
Обобщим данный пример и попробуем ответить на вопрос, вынесенный в заголовок: что считать своей разработкой, которая может быть воспроизведена на любой производственной базе? И с другой стороны – когда завод, производящий радиотехнические системы, может утверждать что он является разработчиком и следовательно может модернизировать, изменять и развивать свою продукцию?
Свое и чужое
Поскольку такие вопросы возникают постоянно, я не поленился и нарисовал вот такую схемку. Схема позволяет взглянуть на ситуацию как со стороны разработки (красная зона), так и со стороны производства (зеленая зона). Агрессивным красным цветом я наделил разработку потому, что эта область является чувствительной и всегда защищается от копирования и заимствования. Зеленая зона содержит информацию, которая и так доступна.
Характерно, что разработчик находящийся в красной зоне (R&D) хорошо представляет как его продукт начинает жить в зеленой (производство), поскольку принимает участие в испытаниях и сопровождении во время изготовления. Обратное далеко не всегда встречается: как правило, заводчане полагают, что знают все об изделии и системе (этим же грешат эксплуатанты), а на самом деле даже не представляют, какой пласт информации кроется за этим. Завод знает о том, как сделано, а разработчик – почему сделано именно так. Чувствуете разницу? В первом случае – конечная станция, просим освободить вагоны, а второй открывает множество дорог в будущее.
Но я немного отвлекся ) Итак, как построена наша схемка. Блоки имеют группировку по вертикали и относятся к наиболее типичным компонентам изделия или системы: антенно – фидерный тракт, аппаратура (сюда включается все – СВЧ узлы, устройства формирования и обработки, компьютерные устройства, средства передачи и отображения данных), программное обеспечение как Firmware – прошивки чипов расположенных на своих платах и программное обеспечение как Software – приложения работающие под управлением операционной системы на встраиваемых платформах SBC (Single Board Computer).
Символично то, что Firmware расположено между аппаратурой и ПО высокого уровня, поскольку это низкоуровневый софт, тяготеющий к железу и являющийся его неотъемлемой частью.
Stupid piece of iron
Поскольку я заметил, что заводчане часто без понятия, откуда берется то что они производят, начнем с них, то есть с нижней части схемы. Про плату радиоприемного модуля мы уже сказали, что завод с ней сделать ничего не может (кроме того что изготовить): наличие конструкторской и технологической документации (информация зеленой зоны) не дает абсолютно никакой информации о способах развития и усовершенствования устройства. Возьмем другой пример: антенна радиолокатора. Документация на антенну позволяет изготовить детали и правильно собрать их. Технологическая остнастка обеспечивает достижение точности там, где это критично: например, соблюдение формы рефлектора и расположение излучателя. Антенну красят, устанавливают на пьедестал, запускают двигатели… и – вуаля! Вот тот момент, который обожают заказчики: здоровый кусок железа начал вращаться вокру своей оси. Мы сделали локатор!
Когда я работал в Риме по радиолокационному проекту, итальянцы – разработчики называли этот характерный момент “stupid piece of iron” – тупой кусок железа, который выглядит зрелищно, привлекает внимание, но мало кто понимает что самая соль содержится в небольших узлах обработки сигнала и ПО.
За границей зеленой зоны остается ряд вещей, о которых знает только разработчик. Как достигнут компромисс между уровнем боковых лепестков, шириной основного лепестка и размерами антенны? Как выдержать диаграмму в вертикальной плоскости во всем частотном диапазоне? Как обеспечить ветровую нагрузку? У разработчиков – антенщиков на руках огромное количество вариантов расчетов. Например, таких, которые никто не увидит – ни заводчане, ни даже заказчик:
Забираясь еще глубже, то есть в верхнюю часть красной зоны, мы увидим результаты исследований, которые проводились по анализу построения антенной системы. Завод не знает, что при определенных условиях это могла быть не антенна с рефлектором, а щелевая, или вообще фазированная антенная решетка. И если задать заводу вопрос типа того, что звучал выше: Ребят, а что если… поменять частоту… отжать лепесток от земли… поменять поляризацию… – ответов на эти вопросы в зеленой зоне нет. Нужно идти в маленькую комнату с очкариками, приборами etc.
Эту истину простую очень
Принимай как есть и не сетуй:
Есть дорога из лета в осень,
Нет дороги из осени в лето
(Неизвестный Автор)
Программное обеспечение: эта песня будет вечной
Если с оборудованием все более менее понятно – не имея электрической схемы и логики ее создания, бесполезно модернизировать устройство, то с софтом возникает отдельная песня. Проблема в том, что люди, причастные к принятию решений, не хотят, или не понимают, или то и другое вместе… скажем коротко: нет просто софта, или ПО. Когда вы говорите: программное обеспечение, уточните в каком виде оно у вас есть: исходные тексты или уже откомпилированные бинарные модули. Из первого можно получить второе, но дороги из осени в лето нет: по бинарному модулю практически невозможно получить исходный текст.
Конечно, вы можете занятся дизассемблированием на свой страх и риск, но если исходники вам официально не давали, не советую и начинать.
На самом деле уровней в компетенции ПО еще больше; я не стал рисовать дополнительные блоки на схеме чтобы не загромождать ее. Бинарный модуль – результат компиляции и сборки нескольких программ, каждую из которой разрабатывает кодировщик. В моей терминологии кодировщик – это программист, для которого четко очерчены рамки его программного модуля и что этот модуль должен делать. Кодировщик может себе позволить не знать абсолютно ничего об общей структуре проекта и о других модулях.
Программист имеет представление о задаче, то есть о физике процесса. Если он еще и инженер, это вообще замечательно: программирующий инженер может задать оптимальную границу в реализации между софтом и железом, используя выигрышные стороны того и другого. На вершине пирамиды, между главным конструктором с одной стороны и программистами и кодировщиками с другой, стоит системный архитектор: он определяет, как софт будет нарезан на модули, какая квалификация нужна для каждого модуля, и специфицирует интерфейсы между модулями.
Несмотря на то, что исходные тексты программ снабжаются комментариями, в ПО сложной архитектуры невозможно по одним комментариям и логике текста программы определить общий замысел. Для этого нужна документация, по структуре соответствующая MIL STD 498, что позволяет поддерживать разработку ПО и развивать ее. Эта документация – на вес золота, потому что в современных изделиях софт берет на себя больше функционала – за счет железа, которое реализуется относительно стандартными блоками. Алгоритмы обработки и формирования, математические модели, обеспечение быстродействия, удачные находки – в этой документации. Само собой, она не покидает стен фирмы и тем более не передается на производство.
Чтобы иметь возможность не трогать ПО в зависимости от различных хотелок заказчика, последнему предоставляют, помимо бинарных модулей, инструменты для конфигурирования. Заказчику могут даже отдать сделать собственный пользовательский интерфейс, но не более того. Наличие этого добра, вкупе с бинарными исполняемыми файлами и библиотеками не означает что это софт вашей разработки! И дело тут не в отношениях собственности. С бинарными модулями на руках вы не сможете решить ни одной задачи по устранению ошибок кода, его модификации, не говоря уже о создании следующих версий и расширения функциональности.
Все вышесказанное также относится и к Firmware. Это софт весьма специфичен и напоминает разработку драйверов устройств. Как правило, его пишут уже не программисты а чистые инженеры. Поскольку внешний мир для Firmware – это плата, связи между ними являются очень тесными и для производства не документируются. В этом ПО может содержаться существенная часть ноу-хау по обработке данных в критичных условиях: например, софт в ПЛИС обеспечивающий работу АЦП.
Разработчики, заводчики и заказчики
Эта статья принесет мало пользы разработчикам и заводчикам. Первым – по причине того что они и так все это знают, вторым – по причине что они и так прекрасно все это знают, но не в их интересах показывать, как все обстоит на самом деле. А вот для заказчиков польза может быть немалая. Это актуально с учетом последних трендов. До пресловутого импортозамещения все было просто: знай покупай импортную аппаратуру, перебивай шильдики и продавай под своим брендом (если кто-то думает что такое возможно только в ширпотребе, покажу примеры из области радиотехнического обеспечения полетов). Сейчас это уже не прокатывает и приходится действовать тоньше: например, перерисовывать чертежи под своими децимальными номерами и изготавливать узлы на своей производственной базе. Благо, зарубежные компании заинтересованные в российском рынке охотно передают ограниченную документацию для China Copy. Но свою технологию они передавать никогда не будут. А это – вечная зависимость. Ну и нехорошо вводить в заблуждение покупателей ложным термином “отечественная продукция”.
Отличная статья, спасибо.
No thanks )